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.
<rdar://problem/30725491>
@aaronlev has posted the most compelling use case so far, for annotations in document suites like Google Docs. IMO, this is worth implementing now.
Related to http://trac.webkit.org/changeset/218809/webkit
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
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
Luckily, the changeset pointed to in comment 3 already supports multiple ids. But, I think it's only supporting ATK and not AX APIs?
Created attachment 424269 [details] Patch
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?
(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.
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;
Created attachment 424276 [details] Patch
(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.
Committed r275066: <https://commits.webkit.org/r275066> All reviewed patches have been landed. Closing bug and clearing flags on attachment 424276 [details].