Menu icon Foundation
ARIA Implicit Roles (accessibility)

So, first off, I'm thrilled you guys are starting to put a spotlight on accessibility, which has kind of fallen by the wayside in the last 6-7 years as everyone's jumped on the javascript-driven application bandwagon.

One thing I've been learning recently is oddly ... where not to use ARIA roles. My understanding now is that when an element has a certain "implicit" semantic meaning, you'd only add an ARIA role when that meaning has been changed because of styling or widget-related concerns. See, for example, this table http://www.w3.org/TR/html5/dom.html#sec-implicit-aria-semantics

So, I looked at the sidebar docs page and the suggested accessible markup.

You actually don't require role="navigation" in the ul.side-nav and, in fact, the validator will mark it as invalid. UL's implicit semantic of "list" is sufficient in context. If you still want to assign aria roles, wrap the UL in a NAV and give the NAV the role of "navigation".

This is a pattern I myself was using a couple of days ago until I decided to track down why it was failing in a validator. Weird, but that's the story.

accessibility

So, first off, I'm thrilled you guys are starting to put a spotlight on accessibility, which has kind of fallen by the wayside in the last 6-7 years as everyone's jumped on the javascript-driven application bandwagon.

One thing I've been learning recently is oddly ... where not to use ARIA roles. My understanding now is that when an element has a certain "implicit" semantic meaning, you'd only add an ARIA role when that meaning has been changed because of styling or widget-related concerns. See, for example, this table http://www.w3.org/TR/html5/dom.html#sec-implicit-aria-semantics

So, I looked at the sidebar docs page and the suggested accessible markup.

You actually don't require role="navigation" in the ul.side-nav and, in fact, the validator will mark it as invalid. UL's implicit semantic of "list" is sufficient in context. If you still want to assign aria roles, wrap the UL in a NAV and give the NAV the role of "navigation".

This is a pattern I myself was using a couple of days ago until I decided to track down why it was failing in a validator. Weird, but that's the story.

Rafi Benkual over 5 years ago

Nick - thanks for the support. So this is our first push into accessibility with the mindset of making the framework itself more accessible. In the coming weeks we want to add more functionality like keyboard arrowing and general knowledge into the docs.

The next step will also involve making our own site accessible. Right now we worked on the components themselves as a starting place.

Joel Kinzel over 5 years ago

Nick,

Using the role="navigation" in this instance is actually correct. In this case, "navigation" is considered a landmark role. These markers make it easier for people with assistive technologies to jump around the page more easily.

Landmark roles are different from document structure roles, which as you said indicate that the actual role is different from the implicit role.

More info here:

http://www.w3.org/TR/wai-aria/terms#def_landmark
and
http://www.w3.org/TR/wai-aria/roles#landmark_roles_header

Nick Caldwell over 5 years ago

Hi Joel,

Landmark roles should be attached to items without an inherent semantic, though. Evidence:

http://stackoverflow.com/questions/14180785/html5-nav-element-vs-role-navigation

http://accessibility.oit.ncsu.edu/training/accessibility-handbook/aria-landmarks.html

The recommended pattern is to use as a wrapper around a - adding the landmark role to the isn't, on further reading, required, but it's generally used as a backstop against screen readers that don't understand HTML5 semantic sections.