This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I received a github issue [https://github.com/Heydon/REVENGE.CSS/issues/12] for my revenge.css project which informs me that the spec precludes the use of role="separator" on list items [http://www.w3.org/TR/html5/dom.html#sec-implicit-aria-semantics]. The spec reads that <li>s MUST only have one role of *listitem *menuitem *menuitemcheckbox *menuitemradio *option *radio *tab *treeitem *presentation However, the separator role (http://www.w3.org/TR/wai-aria/roles#separator) is stated to have the purpose of "distinguishing sections of content or groups of menuitems". Since <li>s can take a role of menuitem and the only legitimate siblings of <li>s within <ul>s and <ol>s are other <li>s, these two pieces of advice appear to be mutually contradictory. The related concept for role="separator" is stated as the <hr> element. This implies that an <hr> would be a legitimate sibling of a menuitem, but not a listitem (which is an explicit <li>). If this is correct, why? And if it is not correct, can we please allow the role of separator on <li> as author advice.
Just because something is a related "concept" does not mean it is functionally equivalent in a host language. HR is indeed a separator but it has other restrictions as you see here. The solution is simple. Apply the role of "separator" to the <li>. This is fact why we have WAI-ARIA. We have to also be careful on the degree in which we restrict WAI-ARIA. 1. We can't predict all the ways authors will create UIS. 2. Authors cannot keep all the exceptions in their heads and they seldom go back to the spec. to look at the restrictions.
(In reply to Rich Schwerdtfeger from comment #1) > Just because something is a related "concept" does not mean it is > functionally equivalent in a host language. HR is indeed a separator but it > has other restrictions as you see here. > > The solution is simple. Apply the role of "separator" to the <li>. This is > fact why we have WAI-ARIA. > > We have to also be careful on the degree in which we restrict WAI-ARIA. > > 1. We can't predict all the ways authors will create UIS. > 2. Authors cannot keep all the exceptions in their heads and they seldom go > back to the spec. to look at the restrictions. Then the bug stands because the implication is that there _is_ an important restriction when there isn't one. Or at least, that can (and was) inferred. You see, I wasn't asking for advice on how to use ARIA, I was questioning the transparency of the guidance for authors in general.
See also: https://twitter.com/heydonworks/status/524493190389596160
Fixed in bleeding-edge version of spec?: https://github.com/webspecs/html-aria/commit/47b0112a2a4ad2a0fc5a0e16565e7a3d4ee048bc
(In reply to Chris Rebert from comment #4) > Fixed in bleeding-edge version of spec?: > https://github.com/webspecs/html-aria/commit/ > 47b0112a2a4ad2a0fc5a0e16565e7a3d4ee048bc yes, note this is an author conformance requirement only, makes no difference to any software except conformance checkers.
HTML5.1 Bugzilla Bug Triage: won't fix. this is handled in the aria document and is clarified there. If you think there is further need to add information to the HTML 5.1 document please add an issue to github. If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!