GNOME Bugzilla – Bug 719571
Do not assign ARIA role "button" to elements whose children you expect to be accessible
Last modified: 2013-12-02 13:59:35 UTC
Because of this line [1], when an Orca user arrows to or within a heading that can be expanded or collapsed, Orca is completely silent. The reason is the complete lack of caret-moved events. And the reason there are no events is because children of buttons are not exposed to ATs, and thus they also fail to emit accessible events. I filed a webkit bug [2] for this issue, because the decision to expose the parent element as a button is not unreasonable and likely is occurring elsewhere in the wild. If we can get them to address this in WebKit, that's one less problem. :) Having said that.... Just because something is clickable doesn't mean it is a button. I think things that look and act like buttons via CSS and javascript goodness should be given the ARIA role "button"; other stuff should not. In the particular case of these headings in Mallard, I think it is sufficient to expose state expandable and expanded (as is already being done in that same method). [1] https://git.gnome.org/browse/yelp-xsl/tree/xslt/common/html.xsl#n1794 [2] https://bugs.webkit.org/show_bug.cgi?id=125015
Follow-up: According to this W3C ARIA (draft) Implementation Guide [1] ==================================== If not already excluded from the accessibility tree per the above rules, user agents SHOULD NOT include the following elements in the accessibility tree: [...] Children of objects which have the characteristic "Children Presentational: True": * button <-- * img * math * progressbar * separator * scrollbar * slider ==================================== So one could argue that WebKit is doing the officially correct thing and that this issue is an authoring issue.... [1] http://www.w3.org/TR/2013/WD-wai-aria-implementation-20131105/#exclude_elements2
Thanks Joanie. Fixed in master.