-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft site navigation guidance section that addresses choosing among structures, disclosures, menus, grids, toolbars, trees, etc. #89
Comments
In issue #45, @DavidMacDonald provided the following feedback. The site navigator is overly complicated... It recommends nesting sub widgets such as a tree (for a leftnav) or a role=menu (top nav) in the main navigation dropdown, with aria-owns. "Navigation container widget: the navigation items need to be contained in an appropriate widget, such as a tree, menubar, toolbar, or listbox. " Here are my concerns:
Note regarding keyboard interaction: I think trapping the right/left arrow keys for navigation inside the widget is probably the way to go, but we need to understand that some users will become confused for the next few years. Radio buttons have been around for 20 years and still 20% of screen reader users don't know that they should use the arrow keys once they tab into a radio group. I doubt aria widgets will be much different. I wish I had a solution for that... I don't, but I'm afraid we're headed for the same type of problems if we get too many sub widgets inside |
In issue #47, @DavidMacDonald provided the following feedback. http://w3c.github.io/aria/practices/aria-practices.html#Site_Navigator_General For the name of this section, at least put the word (menu) somewhere in brackets... it is hard to find in the table of contents... no developers are looking for a "site navigator", they are looking for a main menu, mobile menu, mega menu, etc. This document is supposed to be for "real" web developers, not just accessibility insiders, please give the standard language somewhere so they can find the section. How about "Site Navigation Menu" or simply "Navigation menu", I think that is sufficiently distinct from the "menu" item which also has a confusing name. How about this? |
In addition to the below, This commit also moves the landmark section after the example section. Moved each of the following sections from aria-practices.html to aria-practices-DeletedSectionsArchive.html and created associated issues for drafting new versions. 1. Section "General Steps for Building an Accessible Widget with WAI-ARIA" and created issue #73. 2. Section "Other Widget Authoring Practices"., primarily about aria-valuenow, there is no specific need to raise an issue for this section. 3. Section "Relationships" and raised issues #74, #75, #76, and #77. 4. Section "Managing Dynamic Changes" and created issue #78. 5. Section "Presentation Role" and created issue #79. 6. Section "Form Properties" and created issue #80. 7. Section "Drag-and-Drop Support" and created issue #81 8. Section "Math" and created issue #82. 9. Section "Reusable Component Libraries" and created issue #83. 10. The following 4 Appendix sections related to background on ARIA and created issue #84 A. Background on WAI-ARIA B. Filling the Gaps for Content Delivered to Desktop Browsers c. Building Accessible Applications with WAI-ARIA D. Reasons for Adopting WAI-ARIA 11. The following design patterns: A. Accordion and updated issue #53. B. Autocomplete and updated issue #31. C. Combobox and updated issue #31. D. Datepicker and updated issue #57 E. Dialog (Non-Modal) and updated issue 59. F. Dialog (Tooltip) and added issue #85. G. Landmarks and added issue #86. H. Popup Help (aka Bubble Help) and added issue #87. I. Rich Text Editor and added issue #88. j. Site Navigator - General and added issue #89. K. Site Navigator - Tree and added it to issue #89. L. Site Navigator - Tabbed Style and added it to issue #89. M. Tree Grid and added issue #91. N. Wizard and added issue #92.
In addition to the below, This commit also moves the landmark section after the example section. Moved each of the following sections from aria-practices.html to aria-practices-DeletedSectionsArchive.html and created associated issues for drafting new versions. 1. Section "General Steps for Building an Accessible Widget with WAI-ARIA" and created issue w3c#73. 2. Section "Other Widget Authoring Practices"., primarily about aria-valuenow, there is no specific need to raise an issue for this section. 3. Section "Relationships" and raised issues w3c#74, w3c#75, w3c#76, and w3c#77. 4. Section "Managing Dynamic Changes" and created issue w3c#78. 5. Section "Presentation Role" and created issue w3c#79. 6. Section "Form Properties" and created issue w3c#80. 7. Section "Drag-and-Drop Support" and created issue w3c#81 8. Section "Math" and created issue w3c#82. 9. Section "Reusable Component Libraries" and created issue w3c#83. 10. The following 4 Appendix sections related to background on ARIA and created issue w3c#84 A. Background on WAI-ARIA B. Filling the Gaps for Content Delivered to Desktop Browsers c. Building Accessible Applications with WAI-ARIA D. Reasons for Adopting WAI-ARIA 11. The following design patterns: A. Accordion and updated issue w3c#53. B. Autocomplete and updated issue w3c#31. C. Combobox and updated issue w3c#31. D. Datepicker and updated issue w3c#57 E. Dialog (Non-Modal) and updated issue 59. F. Dialog (Tooltip) and added issue w3c#85. G. Landmarks and added issue w3c#86. H. Popup Help (aka Bubble Help) and added issue w3c#87. I. Rich Text Editor and added issue w3c#88. j. Site Navigator - General and added issue w3c#89. K. Site Navigator - Tree and added it to issue w3c#89. L. Site Navigator - Tabbed Style and added it to issue w3c#89. M. Tree Grid and added issue w3c#91. N. Wizard and added issue w3c#92.
Please note that whatever the pattern ends up as, it should probably include In case it's helpful, I've pasted the basic html structure of our sidebar nav below (of course, the real code has styling and icons, etc). We just went really simple, without even implementing arrow-key navigation (there's usually only 3 to 5 links in our sidebar). The screen reader user who tried it said it worked ok and there was nothing unexpected about it. Note that we use
|
Yes, if everything is visible on page load, no need for |
But everything is not visible on page load. The point is that these are completely separate pages. They just have the same sidebar nav, which contains links to the other pages. It does look like a tabfolder, I confess, and it even sort of feels like one, but the behavior is to take you to another page in the site. The sidebar nav ties all of the pages together by being in the same place and having the same content except for which link has the Edit:
Right. Sorry I misunderstood earlier. Yes, the sidebar nav and all of its links are visible on page load. |
Let me just add one more thought... If we can convince the browser devs to add landmark navigation to the browsers, then the site navigator pattern (and perhaps some others as well) could be greatly simplified. Users want to use the tab key to traverse through links - that's just the way the web has been since the beginning. Doesn't matter if they're in a nav, users will still try to tab. If there was a native way to skip to the next landmark, then page authors wouldn't need to try to implement arrow key navigation in these site navigator menus. Here are the browser feature requests for landmark navigation. |
See also #353 |
I revised the plan in the first comment in this issue to include links for clarity and reflect discussion in today's meeting. |
…on of APG coding practices (pull #1741) Completes a to-do item in issue #89 with the following changes: * Added cautionary note at top alerting users to complexity of menubar pattern and directing readers to consider disclosure pattern as an alternative. * Activating a link now changes content on current page instead of loading a separate page; works like single-page app. * Added landmark regions to mimic a website look and feel. * Updated code to align with latest version of APG code guidelines. Co-authored-by: Matt King <[email protected]>
…1614) * Adds another version of the mythical university navigation that includes links for the top-level pages. * Satisfies one of the steps in the plan for improving navigation patterns described in issue #89. Co-authored-by: Matt King <[email protected]>
…3c#1614) * Adds another version of the mythical university navigation that includes links for the top-level pages. * Satisfies one of the steps in the plan for improving navigation patterns described in issue w3c#89. Co-authored-by: Matt King <[email protected]>
…3c#1614) * Adds another version of the mythical university navigation that includes links for the top-level pages. * Satisfies one of the steps in the plan for improving navigation patterns described in issue w3c#89. Co-authored-by: Matt King <[email protected]>
Plan to resolve this issue:
The text was updated successfully, but these errors were encountered: