Opened 10 years ago
Closed 10 years ago
#29475 closed enhancement (invalid)
Adding ARIA roles in wp_nav_menu
Reported by: | Chrisdc1 | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.9.2 |
Component: | Menus | Keywords: | |
Focuses: | accessibility | Cc: |
Description
In most cases ARIA roles are probably best handled on a theme level, however in a few cases it might be worth adding them into the HTML output by wp_nav_menu()
- role="menuitem" (added to .menuitem li tags) should be applicable in all cases and is currently relatively difficult to add by other methods.
- role="menubar" ( added to top-level ul ) can easily be added in themes using the item_wrap parameter of wp_nav_menu(), however it could be added to the default value for this parameter.
Aria states and properties are often subject to change and are probably best handled on the front end, but aria-haspopup="true" (added to .menuitem li tags with child menus) could be added as an option for themes with dropdown menus.
Change History (5)
#2
@
10 years ago
Fair point. Purely as a point of interest some accessible navigation examples (like http://codepen.io/grayghostvisuals/pen/d7d131e58a33665d24ea0881c01a02b8) seem to like putting a role="menubar" ul within a role="navigation" nav element, but that does seem to be against the specs.
#3
@
10 years ago
The CodePen example you've linked to my account above is actually a snippet by Simply Accessible. Original demo can be found here (http://staff.washington.edu/tft/tests/menus/simplyaccessible/index.html) which I also linked in the info for my Pen. The reality is that pen is out of date but I definitely agree that nav menus for WordPress should always allow flexibility for any and all transitioned states otherwise non-native attributes must be added with JS and isn't always the best solution.
#4
@
10 years ago
Looking into things more (and doing some testing in ChromeVox) I can certainly understand why people use these roles in their nav menus, but joedolson is right, it is outside the specifications. I think that some ARIA states and properties (aria-hidden, aria-haspopup) are worth including in some types of nav menus on a theme level, (and I'm working on something for _s), but on reflection I would be inclined to close this unless anyone feels strongly otherwise.
I don't think that this is a good idea; most of the time, wp_nav_menu is not a menu in the ARIA sense. When ARIA describes an item as being a menu, it's drawing an equivalency to a menu of functions that effect the current page, such as a contrast changer, font size selector, etc. Anything with a role of menubar should be a set of options that effect the current page, not options that navigate to other pages.
A list of links, like wp_nav_menu most often is, is best represented by the "navigation" role, rather than the menu role.
Info about ARIA menus:
http://www.w3.org/WAI/GL/wiki/Using_ARIA_menus
http://www.w3.org/TR/wai-aria/roles#menubar