This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Lists (<li> and <ul>) are often used as menus, toolbars or tab sets, and this is generally not considered contrary to their semantics. But HTML5 strictly limits them to the list role. Please consider the following extended sets of roles for list-related elements: li (with a ul or ol parent) -> menuitem, menuitemcheckbox, menuitemradio, option, tab, treeitem, presentation ol -> list, listbox, menu, menubar, tablist, toolbar, tree, directory, presentation ul -> list, listbox, menu, menubar, tablist, toolbar, tree, directory, presentation The current spec allows lists to be used as lists, trees or directories, the other roles seem appropriate as well. Many sites have a tab bar that's made out of a list styled with CSS.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given below Rationale: I didn't add "presentation", but added the others. If there's a use case for presentation that doesn't involve non-conforming use of these elements, please reopen the bug (or file a new one, if the use case applies to other elements also).
Checked in as WHATWG revision r5420. Check-in comment: ARIA for <li>, <ol>, <ul> http://html5.org/tools/web-apps-tracker?from=5419&to=5420
tracker request relates to rejection of role="presentation"
The reason why <li role="presentation"> is required is the following use case: Take a tab navigation, where <ul role="tablist">. The current implementation in some browsers only supports role="tab" on immediate children of the tablist, i.e. <li role="tab">. If the author chooses to apply the role to a deeper element, like <li><a role="tab">Tabitem</a></li> (feel free to add more presentational spans), then the element that has the tab role isn't recognized as a child element of tablist. Thus the "tab" role is not announced in screenreaders. However, <li role="presentation"><a role="tab">Tabitem</a></li> has the desired effect. So it is imperative that role="presentation" is allowed, otherwise it will break screenreader support. See the website of Deutsche Bahn (German railways) with several billion yearly visitors as use case: http://www.bahn.de
Since this was reopened with new information, removing TrackerRequest for now. We can re-add it after the editor's next pass on this.
(In reply to comment #1) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > Status: Partially Accepted > Change Description: see diff given below > Rationale: I didn't add "presentation", but added the others. If there's a use > case for presentation that doesn't involve non-conforming use of these > elements, please reopen the bug (or file a new one, if the use case applies to > other elements also). Here are two use cases for using role="presentation" on list markup. The first case is a tablist, the corresponding HTML markup is shown below. To keep tabs backwards compatible the best approach is to use list markup with a link inside each list item. This way, older technology, or users that do not support javascript will still be able to perceive the structural information provided by the <ul> and <li> elements, and the tabs will still be keyboard accessible and focusable through the <a> elements. Since the links are the interactive parts in this widget, they are the elements that should receive the ARIA tab markup (role="tab", aria-selected, etc.). However, because those elements are individually wrapped in a list item, the resulting accessible structure (e.g. the MSAA hierarchy) would be incorrect: it would appear as if a role="tablist" container has with role="listitem" children, that each have a role="tab" child. This is not correct, because the accessible structure of a tablist requires that the tabs are direct children of the tablist in the accessible tree. A result of this incorrect structure is that screen readers can't properly determine information about a tab's position within the tablist. For example, NVDA will announce each tab as "1 of 1", even though the tablist actually contains three tabs. To solve this, the native role exposed by the html list items needs to be overridden with role="presentation". This will hide them from the accessible tree, make assistive technology perceive the role="tab" elements as the direct children of the role="tablist" element. Working example of using role="presentation" on list items in an ARIA tablist: http://hanshillen.github.com/jquery-ui/demos/tabs/basiccontent.html Tablist Markup: <h1 id="tabsLbl">Samples</h1> <ul role="tablist" aria-labelledby="tabsLbl"> <li role="presentation"> <a role="tab" href="#tabs-1" aria-selected="true" aria-controls="tabs-1" id="tabs-1-tab">sample 1</a> </li> <li role="presentation"> <a role="tab" href="#tabs-2" aria-selected="false" aria-controls="tabs-2" id="tabs-2-tab">Sample 2</a> </li> <li role="presentation"> <a role="tab" href="#tabs-3" aria-selected="false" aria-controls="tabs-3" id="tabs-3-tab">Sample 3</a> </li> </ul> <div id="tabs-1" role="tabpanel" aria-labelledby="tabs-1-tab"> Sample 1 </div> <div id="tabs-2" role="tabpanel" aria-labelledby="tabs-2-tab"> Sample 1 </div> <div id="tabs-3" role="tabpanel" aria-labelledby="tabs-3-tab"> Sample 1 </div> A similar case is a tree, the markup is shown below. Trees should be marked up as nested lists. Because of this, an <li> representing an expandable treeitem (i.e. a branch node) will be the parent of both the treeitem's branch label (the <a> child of the parent <li> element) and the actual branch group (the <ul> child of the parent <li> element). As far is ARIA is concerned, there are twos ways to apply the tree markup The first approach is to add the ARIA attributes (e.g. role="treeitem", aria-expanded, etc.) to the parent <li>, and make the list items focusable. Although this is valid markup, it has some side effects: When calculating the treeitem's accessible name, some user agents (e.g. IE8) will not distinguish between the text in the actual branch label (the <a> element ) and the sublist representing the branch (the <ul>). For example, if the code snippet below had placed the ARIA treeitem markup on the <li> elements, the accessible name for the outer <li> element would have been: "invoicesJanuaryFebruaryMarch" in IE8, rather than "Invoices". Sometimes, a tree item can have additional content that is not necessary part of the tree label. If the list item itself is used as the actual treeitem (i.e. it's focusable and has the actual ARIA treeitem markup), then all this content will be included in the tree item's accessible name. o An twisty image o A "+" or "-" character used as a twisty that support high contrast mode o A checkbox that allows the treeitem to be checked or selected o A grippy that allows the tree item to be dragged Setting ARIA merkup on the <li>'s prevents their <a> children from being used for keyboard navigation and focus When the treeitem receives focus, the entire branch will be highlighted, rather than just the branch label The first two issues could be resolved using aria-labelledby on the treeitem <li> element, but this requires all treeitems to be given an ID value. The second approach works around these issues, by marking up the actual branch labels (the <a> child of the <li> element) as ARIA treeitem (as shown in the code snippet). However, as with the tablist example above, the exposed <li> elements will lead to an incorrect accessible structure of the tree (causing tree items to be announced as "1 of 1"). To solve this, the <li>'s need to be hidden from AT using the "presentation role" Both approaches are valid, but the second approach would not be possible if role="presentation" was not allowed on list markup. Working example of using role="presentation" on list items in an ARIA tree: http://dl.dropbox.com/u/573324/Samples/aria/tree/index.html Tree Markup: <h2 id="documentsTreeLbl">My Documents</h2> <ul role="tree" aria-labelledby="documentsTreeLbl" aria-multiselectable="true"> <li role="presentation"> <a role="treeitem" href="#" aria-expanded="true" tabindex="0" aria-selected="true">Invoices</a> <ul role="group"> <li role="presentation"> <a href="#" role="treeitem" tabindex="-1" aria-selected="false">January</a> </li> <li role="presentation"> <a href="#" role="treeitem" tabindex="-1" aria-selected="false">February</a> </li> <li role="presentation"> <a href="#" role="treeitem" tabindex="-1" aria-selected="false">March</a> </li> </ul> </li> </ul>
Where in the ARIA spec does it say role=presentation works that way? I couldn't find anything to that effect.
(In reply to comment #7) > Where in the ARIA spec does it say role=presentation works that way? I couldn't > find anything to that effect. works what way? please be specific otherwise it is not possible to answer
Works in the way that allows role=tabset to see children of a child that is role=presentation.
(In reply to comment #9) > Works in the way that allows role=tabset to see children of a child that is > role=presentation. "For any element with a role of presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of presentation. Thus, the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessible tree." From <http://www.w3.org/TR/wai-aria/roles#presentation> And this is how WebKit, at least, actually implements it - elements with role=presentation are skipped when generating the accessibility tree, so they are "transparent" in terms of role parent/child relationships.
(In reply to comment #10) > (In reply to comment #9) > > Works in the way that allows role=tabset to see children of a child that is > > role=presentation. > "For any element with a role of presentation and which is not focusable, the > user agent MUST NOT expose the implicit native semantics of the element (the > role and its states and properties) to accessibility APIs. However, the user > agent MUST expose content and descendant elements that do not have an explicit > or inherited role of presentation. Thus, the presentation role causes a given > element to be treated as having no role or to be removed from the accessibility > tree, but does not cause the content contained within the element to be removed > from the accessible tree." > From <http://www.w3.org/TR/wai-aria/roles#presentation> > And this is how WebKit, at least, actually implements it - elements with > role=presentation are skipped when generating the accessibility tree, so they > are "transparent" in terms of role parent/child relationships. This is how it works in firefox and IE as well, the examples I provided (actually by my colleague hans hillen, who has been working on implementing ARIA in Jquery UI and Extjs libraries) were not thought experiments, they are working examples.
The section quoted in section 10 does not say what everyone here says it says. As far as I can tell there's no other mention of "accessibility tree" or "accessible tree" in the entire ARIA spec, so it's not clear to me what that means. The spec does repeatedly make mention of "contained in or owned by" (where "owned by" refers to use of the aria-owns="" attribute). It doesn't say anything about following the relationships of the DOM ignoring elements with role=presentational or anything about following relationships in an accessibility tree. So I would recommend getting the ARIA spec fixed first.
(In reply to comment #12) > As far as I can tell there's no other mention of "accessibility tree" or > "accessible tree" in the entire ARIA spec, so it's not clear to me what that > means. It's common terminology for the tree of objects exposed in an accessibility API. Usage examples include: https://developer.mozilla.org/en/NsIAccessible http://doc.trolltech.com/qq/qq24-accessibility.html#qtaccessibilityarchitecture http://dev.chromium.org/developers/design-documents/accessibility https://developer.mozilla.org/En/Accessibility/AT-APIs/Web_Specifications#Accessible_tree_vs._DOM_tree_-_what's_the_relation.3f http://msdn.microsoft.com/en-us/library/dd318521(VS.85).aspx http://www.code-magazine.com/articleprint.aspx?quickid=0810062&printmode=true http://msdn.microsoft.com/en-us/library/ms788733.aspx And ARIA does define it in the implementation guide: "The accessible tree and the DOM tree are parallel structures. Roughly speaking the accessible tree is a subset of the DOM tree. It includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessible tree for every DOM element that should be exposed to an assistive technology, either because it may fire an accessible event or because it has a property, relationship or feature which needs to be exposed. Generally if something can be trimmed out it will be, for reasons of performance and simplicity. For example, a <span> with just a style change and no semantics may not get its own accessible object, but the style change will be exposed by other means." Sure, the spec could include a definition in a glossary in the ARIA spec proper, and that might even be a good thing for those unfamiliar with the phrase, but what exactly would that definition clarify? What two or more visions of the accessible tree do you have in mind that such a definition could discriminate between? > The spec does repeatedly make mention of "contained in or owned by" > (where "owned by" refers to use of the aria-owns="" attribute). It doesn't say > anything about following the relationships of the DOM ignoring elements with > role=presentational or anything about following relationships in an > accessibility tree. What do "following the relationships of the DOM" and "following relationships in an accessibility tree" mean? I don't understand what these phrases have to do with the rest of the bug. > So I would recommend getting the ARIA spec fixed first. What would you have it say to have it "say what everyone here says it says"?
(In reply to comment #13) > And ARIA does define it in the implementation guide: Meant to supply a citation: http://www.w3.org/WAI/PF/aria-implementation/#intro_treetypes
added to HTML WG Issue http://www.w3.org/html/wg/tracker/issues/129
The ARIA is a cross cutting technology specification. We provided an example applying role="presentation" to tables but we are not going to modify the ARIA specification for every element in a host language that comes into question. The ARIA specification would be enormous. The ARIA specification is clear enough and does not require us to enumerate every HTML element it applies to. Clearly, there are more than enough use cases for it. But to answer Ian's point it does apply to lists.
Nobody is asking the ARIA spec to list every case. All I'm saying is that it should describe the processing of roles in the specification. Right now, ARIA does not say that role=presentational means that you skip the element in the DOM when determining what the child of an element is, all it does is remove the element from the accessible tree which is presumably what is exposed to ATs (note that this is _not_ the same as the tree that has the ARIA annotations it's what the tree with ARIA annotations is turned into). I respect everyone's opinion that this is what they want ARIA to say, but as editor I have to make sure that the HTML spec is actually compatible with what ARIA actually says, otherwise we are back to the world where the specs have to have "priests" to "interpret" them like holy texts, and there's no chance of getting interoperability by just following the specs.
(In reply to comment #17) > Nobody is asking the ARIA spec to list every case. All I'm saying is that it > should describe the processing of roles in the specification. Right now, ARIA > does not say that role=presentational means that you skip the element in the > DOM when determining what the child of an element is, all it does is remove the > element from the accessible tree which is presumably what is exposed to ATs > (note that this is _not_ the same as the tree that has the ARIA annotations > it's what the tree with ARIA annotations is turned into). > > I respect everyone's opinion that this is what they want ARIA to say, but as > editor I have to make sure that the HTML spec is actually compatible with what > ARIA actually says, otherwise we are back to the world where the specs have to > have "priests" to "interpret" them like holy texts, and there's no chance of > getting interoperability by just following the specs. nobody else (authors or implementors) appears to have a problem understanding how it works, if you have a problem, please file a bug against the ARIA spec. Note: this bug has been escalated as part of issue 129 http://www.w3.org/html/wg/tracker/issues/129, so you can argue your case to the HTML WG, as to why role="presentaion" should not be conforming on list elements, in the form of a null change proposal.
Maciej did some digging in the ARIA specs and found the following: 1. It seems like the relationship between tab and tablist is mediated by the "owned element" concept, which applies to any DOM descendant: http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_owned_element Thus, role=presentational isn't needed according to the ARIA spec to achieve the effect described above. However: 2. It is required to prevent the role of the list item itself being present. This is a different use case than described above, but a relevant one nonetheless. That is, the role=presentation is not in theory required to get the ownership relation right, but it is required to avoid redundant content in the accessibility tree. However: 3. This means that any list will contain _all_ of its descendant list items, even those owned by nested lists, which is clearly a bug in ARIA. Futhermore: 4. The implementation guide: http://www.w3.org/WAI/PF/aria-implementation/> ...says that the role mappings are such that random DOM descendants (with non-presentation-role intermediate elements) will not get hooked up correctly (as according to the ARIA spec). Therefore, the use case described previously here _does_ apply according to the implementation guide (but not the ARIA spec). The remaining issue in this bug therefore seems to be handled by bug 10919. I'll fix it there and am returning this bug to the FIXED state as per comment 1.
The bug-triage sub-team agrees this bug is fixed per bug #10919, Maciej please verify and close the bug.
This is part of HTML-ISSUE-129. There is some debate taking place actively. Therefore bug triage sub-team thinks this is a HTML A11Y TF priority. Adding a11ytf keyword and assigning to Steve Faulkner for ARIA mapping sub-team.