Bug 165842 – AX: Consider implementing @aria-details.

• Component: Accessibility
• Status: RESOLVED FIXED

[James Craig]

Consider implementing @aria-details.
https://www.w3.org/TR/wai-aria-1.1/#aria-details

I'm not fully convinced of the utility, b/c it's more or less an on-page versus of @longdesc, and the examples included seem pretty trivial (image followed by a section describing the image). 

If someone were to present a more compelling use case, or if it starts getting wider adoption, we should pick it up. Implementation would likely just be a navigation or link action from the current element to the related details element.

[Radar WebKit Bug Importer]

<rdar://problem/30725491>

[James Craig]

@aaronlev has posted the most compelling use case so far, for annotations in document suites like Google Docs. IMO, this is worth implementing now.

[James Craig]

Related to http://trac.webkit.org/changeset/218809/webkit

[Aaron Leventhal]

Note that as part of work on ARIA Annotations, the ARIA spec is being updated to allow aria-details to support multiple ids. See w3c/aria#1136

[Aaron Leventhal]

Note the importance of aria-details has increased quite a lot with the ARIA annotations work. Supporting aria-details will be necessary in order to support comments in Google Docs, among other things.

W3C ARIA spec issue: https://github.com/w3c/aria/issues/749
Explainer: https://github.com/aleventhal/aria-annotations

Also, multiple ids are now supported. See https://github.com/w3c/aria/pull/1136

[Aaron Leventhal]

Luckily, the changeset pointed to in comment 3 already supports multiple ids.

But, I think it's only supporting ATK and not AX APIs?

[Andres Gonzalez]

Created attachment 424269 [details]
Patch

[chris fleizach]

Comment on attachment 424269 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=424269&action=review

> Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:1873
> +        if (object) {

are we ever going to have a case where we have a nil pointer in the vector? won't adding a nil pointer to a vector crash anyway?

[Andres Gonzalez]

(In reply to chris fleizach from comment #8)
> Comment on attachment 424269 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=424269&action=review
> 
> > Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:1873
> > +        if (object) {
> 
> are we ever going to have a case where we have a nil pointer in the vector?
> won't adding a nil pointer to a vector crash anyway?

It is a Vector<RefPtr<>> and it can have null pointers on it. In the current use, it shouldn't have null pointers, but caller can pass null pointers, so I think it is appropriate to check before dereferencing here.

[chris fleizach]

Comment on attachment 424269 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=424269&action=review

>>> Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:1873
>>> +        if (object) {
>> 
>> are we ever going to have a case where we have a nil pointer in the vector? won't adding a nil pointer to a vector crash anyway?
> 
> It is a Vector<RefPtr<>> and it can have null pointers on it. In the current use, it shouldn't have null pointers, but caller can pass null pointers, so I think it is appropriate to check before dereferencing here.

I think we can save some lines of code if we do

if (!object)
   continue;

[Andres Gonzalez]

Created attachment 424276 [details]
Patch

[Andres Gonzalez]

(In reply to chris fleizach from comment #10)
> Comment on attachment 424269 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=424269&action=review
> 
> >>> Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:1873
> >>> +        if (object) {
> >> 
> >> are we ever going to have a case where we have a nil pointer in the vector? won't adding a nil pointer to a vector crash anyway?
> > 
> > It is a Vector<RefPtr<>> and it can have null pointers on it. In the current use, it shouldn't have null pointers, but caller can pass null pointers, so I think it is appropriate to check before dereferencing here.
> 
> I think we can save some lines of code if we do
> 
> if (!object)
>    continue;

Done, agree that is more legible.

[EWS]

Committed r275066: <https://commits.webkit.org/r275066>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 424276 [details].