|Recommended implementation: Main navigation CSS menu||BrainCrumbz||8/30/12 11:40 AM|
We are in the process of implementing (i.e. adding) WAI-ARIA support to the main navigation menu of a web portal. The menu is the one shown in attached screenshot. In particular, requirements are to start with the first-level menu (the one highlighted with green border); then, later on, we'll proceed to the second-level menu as well, i.e. the submenus. Menu is implemented by means of classic <ul> / <li> / <a> DOM tree, styled with CSS to look like horizontal tabs.
I've read many parts of most recent WAI-ARIA specs from w3org for a general understanding, taxonomy, and so on.
Then I've read about several examples of UI widget implementations. I could not find any example specifically targetd at such a CSS navigation menu. The closest widgets I've always found around are the Menu, the MenuBar, and the TabPanel. Of course I also looked in this group.
I'd say that none of those widgets exactly match a (CSS) navigation menu. As an example, TabPanel may control some content in the page (--> aria-controls), maybe MenuBar too; but I'm not at all sure that a navigation menu controls content in the page (it controls the next page to show). Without going further, there are some other differences as well.
References are at the end of the post. If anyone as better (or more fit) examples of navigation menu, we'd be glad to know about them.
From all this info collecting, we are considering to implement WAI-ARIA by means of the following attributes/UI logic:
o role="menubar" for menubar <ul>
o role="menu" for submenu <ul> elements
o role="menuitem" for (sub)menu items *
o role="presentation" for menuitem containers that are not needed in the exposed accessible menubar structure*
o aria-expanded="true/false" for branch menu items
o aria-activedescendant="<id of active menuitem>" to track focus
o aria-labelledby="<id of parent menu item>"
• Right arrow: Next menubar item
• Left arrow: Previous menubar item
• Enter: Select first menu item if opening
• Space: Select first menu item if opening
• Esc: Close menu and return focus to menubar
• Tab: Move focus in/out of the menu
• Shift+Tab: Move focus in/out of the menu
What I'm kindly asking here to all of you is: is there anything wrong in that? Is there anything we are missing? Could we do better?
Thanks for your attention and feedbacks!
|Re: Recommended implementation: Main navigation CSS menu||David Ward||8/31/12 5:27 AM|
Looks like you did your homework... I'd be sure to test it with AT or have somebody test it for you. Even VoiceOver on iOS has changed over time not a lot but some. Not sure about Jaws and SeroTalk Etc.
Here's stuff from my personal notes:
-doesn’t work- (iOS)
aria-live, aria-atomic, & relevant
|Re: Recommended implementation: Main navigation CSS menu||David Ward||8/31/12 5:29 AM|
Correction Not: SeroTalk -> I meant SeroTek's SA (System Access)
|Re: Recommended implementation: Main navigation CSS menu||BrainCrumbz||8/31/12 8:01 AM|
Thanks for your feedback. Yes, we try to do our own work before bothering the whole community :) :) :)
I'm not sure if we will use describedby or not. But I'll take your note into consideration.
Adding to the first post:
what about the landmark role, navigation? Would that be appropriate for such a navigation menu?
If so, then we would have a conflict on the root <ul> node. Should that have menubar role, or navigation role?
|Re: Recommended implementation: Main navigation CSS menu||BrainCrumbz||9/4/12 6:21 PM|
For the records, following IBM article sheds a light to solve this role-Vs-menubar apparent confilct:
(see "Using WAI-ARIA to provide a navigable page structure")
The page seems to be quite up-to-date, when compared to other WAI-ARIA articles, as it points to an exact URL & anchor withing latest W3org documentation.
So, after researching and reasoning, these should be the specs for our nagivation bar implementation:
o Outer wrapper <div>
§ Main <ul> navigation bar container
· First-level <li> item without submenu
o <a> to destination URL
· First-level <li> item with submenu
o <a> to destination URL
o Second-level menu <ul> container
§ Second-level <li> item
· <a> to destination URLRoles
o role=”navigation” for outer wrapper <div>
o role="menubar" for <ul> navigation bar container
o role="menu" for second-level <ul> containers
o role="presentation" for first- and second-level <li> menu items (they are not needed in the exposed accessible menubar structure)
o role="menuitem" for first- and second-level <a> menu items
o aria-haspopup="true" for first-level <a> menu items having a submenu
o aria-labelledby="ID of previous <a> menu item" for second-level <ul> containers
o aria-selected="true" on currently visited first- or second-level <a> item; aria-selected="false" on the other <a> items. That is to enforce the concept “selected <==> current page”
o aria-expanded="true/false" for second-level <ul> containers
o aria-hidden="true/false" for second-level <ul> containers
o aria-activedescendant="<id of active menuitem>" for main <ul> navigation bar container. This is an alternative to working with tabindex
o tabindex=0 on currently visited <a> item; tabindex=-1 on the other <a> items. That is in order to first focus on the current page when tabbing to the navigation bar. It is an alternative to working with aria-activedescendant
o Right arrow: Next menubar item
o Left arrow: Previous menubar item
o Enter: Select first menu item if opening
o Space: Select first menu item if opening
o Tab: Move focus in/out of the menu from any point in the web application.
o Shift+Tab: Move focus in/out of the menu from any point in the web application.