This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
see advice here: http://terrillthompson.com/blog/474 in summary should advise against marking up web site navigation links lists as menus.
I Added a section of information discouraging menubar on navigation menus... then i found this and am not sure if i should undo the changes... http://www.w3.org/TR/wai-aria-practices/#menu
It will be good to get clarification from PF on the intended scope of usage for menubar. I'm not sure I agree that links don't represent "actions or functions" and that therefore website navigation menus "aren't really menus". I agree that the keyboard interaction pattern for ARIA menus is likely unfamiliar to many users in the context of websites as opposed to desktop applications, but presumably this is temporary, and can be mitigated in the meantime by providing helpful prompts, either through some visual presentation for sighted keyboard users, or help text for screen reader users. That the links in the menu are set with role=menuitem and thus don't appear in the screen reader's links list dialog is a potential concern. It would be good to get some feedback from screen reader users as to how much of an issue this is. The Government of Canada's Web Experience Toolkit (WET) implements menubar for its site navigation menu [1]. There's quite a bit of discussion around it on their github repository [2]. From what I understand of the WET, they've done a good amount of usability testing with a variety of users, including sighted keyboard and screen reader users, and still appear committed to this implementation. [1] http://canada.ca/en/index.html [2] https://github.com/wet-boew/wet-boew/issues/2680
strong disagreement from canadian government rep. email below. ====== It's just been brought to my attention the bug and discussion regarding discouraging using role="menubar" for navigation sections: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23970 http://lists.w3.org/Archives/Public/public-html-a11y/2014Jan/0030.html I've read them and I can't figure out why the W3C (saw you as part of the discussion as well) is talking out pulling out the rug from beneath people who have invested a lot of research and testing into this. The old "top-level links are links" paradigm doesn't work across input methods. We're now in a world where there is extensive touchscreen usage and a lot of small and medium size screens so a lot of these old conventions don't work any more. For instance all this talk about top-level links in the menu bar. needing to remain top-level links ignores the fact that is detrimental to touchscreen users in such a menu system as it would prevent them from accessing the sub menus (or create a scenario where some users can follow the links while others can't which isn't good either). Where is the hard evidence that the approach WET took is problematic and should be discouraged? We're getting very positive testing results but it looks like this is about Terrill having a change of heart so everyone should follow what Terrill says because he knows better than the countless hours of research and user testing the various groups have invested in menus for navigation. Is there something I'm missing here? I don't see any valid justification in any of the threads for such a ground shifting change (especially considering the large number of implementations of WAI-ARIA menus for navigation) short of a bunch of opining and ivory tower arguments (and argument over what an action is). Just wanted to get a better idea of what is going on before deciding to wade into this. Currently I'm not pleased with what I'm seeing and am rather discouraged that such ground shifting decisions could be made with so little consultation, so little evidence and seemingly so little user testing. This seems to be so contrary to the open and extensive consultations that was done for WCAG 2.0 ensuring there was community consensus (rather than doing effectively a table drop on people that this affects most). =========== so I've reversed the changes I made and would like further consultation with other editors, and wai aria pf committee regarding next steps.
Further comments from Paul Jackson after I deleted the changes citing need for further investigation... =======+ Thanks David for clearing that up. Thank you also for leaning towards deleting the edits and bringing this back to the authoring committee. Even if your document is non-normative, it still should reflect best practices, including respecting existing implementations, and should not be discouraging people from doing things that improve accessibility and usability for users, especially when there was nothing before that discouraged such things (i.e., WAI-ARIA and it's supporting documents never even hinted that it shouldn't be used that way). A lot has changed since the spec was first put out, so I'd argue that what the authors originally intended is not really relevant any more. People have found WAI-ARIA menus to be a good way to improve accessibility and usability of navigation menus, especially in a world where touchscreens are quickly becoming the dominant interface. A lot has also been learned through user testing and live implementations so this coaching document should reflect how the usage of WAI-ARIA has evolved for the better rather than what the authors originally intended. We strive to follow the best practices from the W3C but they have to make sense and put users first. It can be quite frustrating when you do something that users have repeatedly requested and works well for them yet could be discouraged by an upcoming best practice put out by the W3C, especially when there is no credible evidence that supports discouraging such practices. Thanks again for clarifying and I hope that the authoring committee not only chooses to not discourage the use of WAI-ARIA menus for navigation but also chooses to provide guidance to help people to improve WAI-ARIA menus for navigation (but I would be happy if we at least get the first one). Paul ======
(In reply to dmacdona from comment #1) > I Added a section of information discouraging menubar on navigation menus... > > then i found this and am not sure if i should undo the changes... > > http://www.w3.org/TR/wai-aria-practices/#menu its difficult to know or review the edits you made (and then presumably reverted) can you provide a pointer to them?, also not that changes made are to an editors draft, pulling them before a reasonable review period is counter productive. suggest in future that when edits are made against a bug that a link to the commit be included.
Ok, will do Steve Here are the original changes to address the bug. https://github.com/w3c/aria-in-html/commit/dd1f2b6ec09459cebb78a069193ea6eed837f61a ========== with small adjustments via the following entries: https://github.com/w3c/aria-in-html/commit/28846e14e0c10a0161f9c844ff4a40cbea74b3db https://github.com/w3c/aria-in-html/commit/1d6a5cbee7b7aa5c6c6a5f1fcf47c51ca6d433cc https://github.com/w3c/aria-in-html/commit/786a9633205aa77f3d16481a08e4456018be6668 ============= Here is the reverse of the above: https://github.com/w3c/aria-in-html/commit/8fd316ddec1083ca81014f9e91e45f0c05c9d9e3 Last week I participated in the W3c PF Committee Face to Face in Toronto on wai-aria. They are the group that is responsible for wai-aria and who wrote the spec. They were unanimous that menubar and related attributes can apply to dynamic Navigation menus as well as application type menus. James Craig summed it up that they are essentially the same. I think this bug is ready to close.
(In reply to dmacdona from comment #6) > I think this bug is ready to close. OK fine with me
The text, "It is NOT really intended to mark up site navigation list items" added regarding role="menubar" [1] seems at odds with David's anecdotal evidence from the PF group in Comment 6 that menubar is fine for website navigation menus. Does "site navigation list items" refer to a typical horizontal site navigation menu with dropdowns, or does it mean a sidebar list of links, or something else? It's also not clear what "NOT really intended" means. My understanding based on the ARIA spec and authoring practices doc is that the use of menubar has more to do with the visual and interaction design pattern applied to the menu, regardless of whether it is a website or other application, and regardless of whether the "actions or functions" in the menu are things like "open a document" or "take me to webpage x". In other words, role="menubar" and related attributes are perfectly valid for horizontal main navigation menus in a website as per the example at http://canada.ca/en/index.html Seeking clarification, please... [1] http://w3c.github.io/aria-in-html/#indexmenubar