Draft site navigation guidance section that addresses choosing among structures, disclosures, menus, grids, toolbars, trees, etc.

[mcking65]

Plan to resolve this issue:

1. Revise the Navigation Treeview Example to represent mythical university, emulating behavior of Example of Disclosure for Navigation Menus.
2. Remove or modify the Navigation Menu Button Example: If we keep it, should it be a single button that opens a menu containing the top-level links of Mythical University?
3. Merge initial version of the navigation systems pattern proposed in pull request (WIP) Add navigation systems design pattern #1492.
4. Modify introduction of examples referenced by the newly merged navigation systems pattern, including cautionary notes where appropriate:
   1. Revise the introduction of the Example of Disclosure for Navigation Menus to include a link to the newly merged navigation system pattern and add some prose that emphasizes why it is often the most appropriate choice.
   2. Revise the introduction of the Navigation Menubar Example to add a link to the newly merged navigation systems pattern and caution against inappropriate use.
   3. Revise the introduction of the Navigation Treeview Example to add a link to the newly merged navigation systems pattern and caution against inappropriate use.
5. Revise description of link to Navigation Disclosure Example in the Disclosure Pattern to include a link to the navigation systems pattern.
6. Revise description of link to Navigation Menubar Example in the Menubar Pattern to include a link to the navigation systems pattern.
7. Modify the Navigation Menubar Example to replicate behavior of Example of Disclosure for Navigation Menus:
   1. Eliminate loading of separate pages
   2. Implement aria-current
8. Consider additional examples and issues to address:
   1. Is there other guidance that should be included in or linked to from the navigation systems pattern?
   2. Should we remove any examples or build more examples, e.g., tabbed navigation, megamenu?
   3. Should we change the content of the navigation system examples, does mythical university best illustrate the points that need to be made?

[mcking65]

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.
http://w3c.github.io/aria/practices/aria-practices.html#Site_Navigator_General

"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:

• I'm nervous about this level of complexity. It requires a lot of Assistive technology computing power ... especially aria-owns.
• The WAI ARIA Authoring Best Practices 1.0 Site Navigator, did not receive high uptake... neither did the 1.0 ARIA tree widget and 1.0 menu items outside of academic discussion and experimentation, in the 6 years they have existed. The navigator requires considerable learning for developers and a lot of expertise from a screen reader user who is inevitably going to become confused...
• Consider simplifying the requirements. Consider straight forward lists (and sublists) of links wrapped in a <nav> with aria-expanded. Let's not drown the menu in roles that override the <ul><li> semantics, which have been an understood convention for groups of links for 20 years and which natively gives hierarchy, eliminating the need for aria-owns, which saves AT computing power. Consider a realistic construct that is achievable and which can gain community momentum, consensus and uptake ...

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 <nav> elements.

[mcking65]

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?
Distinguish the "Menu" and "Site Navigator" as two types menus:
-"Application Menu"
-"Navigation Menu"
Both of which are easily understood. Currently both "Menu" and "Site Navigator" are confusing.

[carmacleod]

Please note that whatever the pattern ends up as, it should probably include aria-current="page" on the current item.

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 aria-current ="page" (which seems fairly well supported now) and note also that we do not need to use aria-expanded, because the "current page" takes care of informing the user that there are pages and that this is the current one.

<nav aria-label="Sidebar">
	<ul class="sideMenuList" style="list-style-type: none;">
		<li>
			<a href="https://orion.eclipse.org/edit/edit.html" aria-current="page">Editor</a>
		</li>
		<li>
			<a href="https://orion.eclipse.org/git/git-repository.html">Git</a>
		</li>
		<li>
			<a href="https://orion.eclipse.org/shell/shellPage.html">Shell</a>
		</li>
		<li>
			<a href="https://orion.eclipse.org/sites/sites.html">Sites</a>
		</li>
		<li>
			<a href="https://orion.eclipse.org/settings/settings.html">Settings</a>
		</li>
	</ul>
</nav>

[DavidMacDonald]

we do not need to use aria-expanded, because the "current page" takes care of informing the user that there are pages and that this is the current one.

Yes, if everything is visible on page load, no need for aria-expanded

[carmacleod]

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 aria-current="page" attribute set. I suspect that putting aria-expanded on our sidebar nav would just be confusing.

Edit:

Yes, if everything is visible on page load, no need for aria-expanded

Right. Sorry I misunderstood earlier. Yes, the sidebar nav and all of its links are visible on page load.

[carmacleod]

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.
I could use some support in trying to convince the browser devs that this would be a really cool and useful feature. :)

• Edge
• Chrome
• Firefox
• Safari

[DavidMacDonald]

See also #353

[mcking65]

I revised the plan in the first comment in this issue to include links for clarity and reflect discussion in today's meeting.