[Question] Potentially Missing ARIA roles in the Navbar

[kkirsche]

Hey guys,

I had a question regarding the navbar example in the docs after doing some more reading this evening about accessibility.

First, I was curious what the reason was for not using role="navigation" on the navbar at the <nav class="navbar navbar-default"> line.

Second, I see we are using role="menu" within the navbar, and I saw on the W3C standard that it shows list items with role="menuitem" and I was wondering if there was a reason we aren't using those roles.

Thanks for the explanations and if any of this should end up requiring a pull request to add these I'll be happy to put that together. Thanks for your time and help

[zacechola]

Am I correct to assume you're talking about the kitchen sink navbar example?

For navigation, that's covered by the use of the <nav> element which has a semantic meaning. There is an a11y note in the docs to use role="navigation" "if using a more generic element such as a <div>."

That's pretty much what's covered in the wiki: http://www.w3.org/WAI/GL/wiki/Using_HTML5_nav_element

For the menuitem role, that's probably an oversight, I think. It's used in the dropdown examples. But, I defer to @patrickhlauke's expertise here.

[kkirsche]

The difference as I understand it is in the definitions. E.g. the navigation role:

A collection of navigational elements (usually links) for navigating the document or related documents.

and the nav element:

The `nav` element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

These definitions combined with the W3C recommendation that "adding the ARIA role="navigation" is advised" from here makes me question that not having it is best practice with just a nav element

The following example is shown:

<nav role="navigation">
  <ul>
    <li>About us</li>
    <li>Services</li>
    <li>Contact</li>
    <li>Location</li>
    <li>Why Groovy?</li>
  </ul>
</nav>

[zacechola]

There's no difference. The purpose is noted in the working draft you linked, however, it's in a note:

User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip or provide on request (or both).

The point of the landmark and the element is the same when used properly. WAI's wiki authors err on the side of broadly targeting user agents. IE8 is the only browser in Bootstrap support that doesn't also natively support the <nav> element. It's noted in the Bootstrap docs that some HTML5 elements are not fully supported by these browsers. Thus, the a11y note in the docs:

Be sure to use a <nav> element or, if using a more generic element such as a <div>, add a role="navigation" to every navbar to explicitly identify it as a landmark region for users of assistive technologies.

[cvrebert]

Regarding role="navigation", see #15109

[patrickhlauke]

The subject of role="menu is a tricky one (and I know that we're currently inconsistent with when and how it's used in some of our examples). The short version of the conundrum is: having a "proper" (in the sense of WAI-ARIA) role="menu" (with the suggested keyboard handling, roving tabindex, etc) should mostly be reserved for application-like menus - when a web app is trying to appear/function like a desktop application (see http://www.w3.org/WAI/tutorials/menus/application/); for more generic navigation-type menus/dropdowns, the pattern is overkill and can in fact have adverse effects (for instance, links may not show up in a screenreader's overview of links, and non-AT keyboard users may be confused that they can't simply use TAB to navigate to things) - so usually, it's best to actually not use role="menu", role="menuitem" etc and instead opt for something far more lightweight (see http://www.w3.org/WAI/tutorials/menus/flyout/ and http://heydonworks.com/practical_aria_examples/#submenus)

I'll have to set some time aside to double-check what the best advice here would be. It will likely require some explanation in the docs about the above distinction (navigation menu versus application menu), and then consistently applying the right roles in the examples. I'll pop this on my to-do :)

[rs459]

If we follow http://www.w3.org/TR/wai-aria/roles#menu

A type of widget that offers a list of choices to the user.

A menu is often a list of common actions or functions that the user can invoke. The menu role is appropriate when a list of menu items is presented in a manner similar to a menu on a desktop application.

Role="menu" require children like
menuitem
menuitemcheckbox
menuitemradio

[patrickhlauke]

yes, a raw role="menu" without children that have role="menuitem" is indeed invalid (and that's something that needs to be removed from our code). but the larger issue is when to use and when not to use an actual role="menu" construct (for desktop-like web applications, rather than navigation menus)

[kkirsche]

I really appreciate the time to explain some of this @patrickhlauke and for the link @cvrebert. Seems much more complex in implementation it seems in the specs/recommendations.

I'm assuming #15109 comes under the "Note: When support for HTML5 improves there may be no need to continue to add the ARIA role="navigation"." statement at the end of the role="navigation" in the aforementioned link. Just confusing that W3C also says, "in order to make the structure more accessible to user agents that support ARIA as well as ensuring that user agents that don't support HTML5 can also understand the structure, adding the ARIA role="navigation" is advised."

[kkirsche]

@patrickhlauke would you be interested in having any help (e.g. pull request) for the docs regarding clarifying navigation menu vs application menu or would you prefer to handle that based on your experience?