WAI-ARIA & HTML5 - Why should I favor the latter?

Question

I want to learn more about how to make webpages more accessible, so I've spend the last few hours reading about WAI-ARIA. Still, the whole concept isn't quite clear to me - HTML5 is part of that confusion.

I apologize if this question is maybe a bit long, but I think it needs a bit of explanation where I'm coming from.

When I learned HTML, it was HTML 4. That meant, e.g. a header looked like this:

<div id='nav'>
    <!-- HTML content -->
</div>

I understand that this does nothing for accessibility as it just informs the browser that there is a generic div element, identified by the id 'nav', whereas 'nav' could also be 'parrot' or 'raspberry-jam'. So while 'nav' maybe seem semantic for humans, a machine can't treat it right, no screen reader can inform the user that the content he/she wants to access is located inside the page navigation.

Thats where the ARIA roles come into place, right? Because using role=nav passes important information to assistive technology (the id is optional of course):

<div id='nav' role='navigation'>
    <!-- HTML content -->
</div>

That way a screen reader can inform the user that the element is used as navigation.

Now HTML5 comes into place, introducing the nav element. Using HTML5, the whole example could look like this (id is optional again):

<nav id='nav'>
    <!-- HTML content -->
</nav>

One of the great benefits of HTML5 is alleged to improve semantics, because now, screen readers/assistive technology don't need the ARIA role anymore, they can interpret the element by itself. Is this true? I've also read that one should use <nav role="navigation"> to make sure also older versions can also interpret the element.

This leads me to the question: What do the new HTML5 elements do to semantics after all - why should I favor e.g. <nav> or <nav role="navigation"> over <div role="navigation">? Apparently the WAI-ARIA specification is much more complete than the HTML5 specification regarding accessibility - are there any best-practice guides or something like that?

Answer 1

I think this article gives a nice overview of WAI-ARIA vs. HTML5 and how to use them in practice.

http://zufelt.ca/blog/are-you-confused-html5-and-wai-aria-yet

The conclusion:

From the above examples what can we conclude. Firstly, the primary, if not sole, purpose of WAI-ARIA is to provide information about elements in an document to assistive technology, through an accessibility API. Secondly, HTML5 on its own, without the use of WAI-ARIA is not sufficient for ensuring a fully accessible experience to users. Finally, There are situations where the line is blurred between HTML5 and WAI-ARIA, where the functionality of attributes are almost the same, but differ enough to be confusing, and to have an impact on how the two technologies must be implemented by user agents, including assistive technology.

Answer 2

They're not necessarily mutually exclusive. You are correct that HTML5 has provided a few more semantic containers, but that is just a small part of the scop that ARIA covers, so you still want to be in the habit of using ARIA.

In theory, you are correct, that eventually the nav container should be recognized by screen readers and you wouldn't necessarily need/want the role attribute there. But screen readers, like any browser, tends to be behind the standards so you still need to accommodate as many as you can by still leveraging all tools at your disposal--including ARIA.

Answer 3

While it is true that role=navigation gives essential information that could be used by user agents, they don’t generally use it. Realistically speaking, much of ARIA is still write-only code. We should use it, though, since some programs make some use of it, and others may follow if ARIA becomes more widely used.

Similar considerations apply to the nav element. Calling it “semantic” is more or less misleading, since it indicates the structural role of its content, not its meaning. In theory, it lets you dispense with role=navigation, leading to more compact code. But in fact, the document (WD) Using WAI-ARIA in HTML recommends that authors declare the default ARIA “semantics” for it, i.e. use role=navigation on nav. The reason is simple: there are programs that recognize the role attribute but not the HTML5 definition for nav.

The usefulness of the new HTML5 structural elements like nav is debatable, and the arguments in favor of them vary from vague slogans about “semantic” markup to mere conciseness of coding.

Answer 4

It may be appropriate to use HTML 5 where there is an element that does the job, then add WAI-ARIA elements where required, I believe this is what W3C suggest. But at the current time I'm not sure how fully assistive technologies support HTML5 elements (see link below), so it could be good to double up.

For further information see: http://www.w3.org/TR/2013/WD-aria-in-html-20131003/

http://blog.paciellogroup.com/2010/04/html5-and-the-myth-of-wai-aria-redundance/

http://alastairc.ac/2010/04/accessibility-and-html5/

Regarding screen readers and HTML 5 support: http://tink.co.uk/2013/02/screen-reader-support-for-html5-sections/

Answer 5

Think of role=navigation as a landmark.

The use of element is very broad. Pagination, off-site links, social buttons, local on-page scroll, tabs, related content, tag lists. Nearly all implementations of contain multiple sets of navigation.

The navigation role is distinct. "A collection of navigational elements (usually links) for navigating the document or related documents".

Basically - your primary nav should have the navigation role placed on it.

Like this:

.. links to your stupid social networks .. .. other links ..

There are sectioning elements and there are landmark roles. Sometimes, their meanings align - header(role=banner), footer(role=contentinfo), nav#primary_nav(role=nav). Most often; however, they do not align.

It's very simple - using role=navigation to mark the primary navigation links gives us free reign over use of the element.

Roles are for assistive-tech. It's necessary to use them for accessibility when a site takes full advantage of html5 sectioning elements & document structure.

You should not just by default apply the roles. It's better not to touch any roles than apply them incorrectly. It's not about backwards compatibility with the ancient browsers - they can't interpret HTML5 elements, let alone ARIA landmark roles. To them, it's all just a bunch of DIVs. The purpose of the roles are accessibility. They are for assistive-technology and assistive-tech only.

Answer 6

It looks as if there are certain HTML5 elements that already have implicit ARIA roles and should not have these roles added in conjunction with these elements. W3C has a list of them here: https://www.w3.org/TR/html-aria/#docconformance.

Another really helpful article as well: https://www.sitepoint.com/how-to-use-aria-effectively-with-html5/