The question of whether HTML elements need the addition of ARIA role
attibutes to expose their semantics, is one that surfaces on a regular basis. The answer is maybe for a subset of elements, but increasingly no.
ARIA roles add nothing to default semantics of most elements
In some cases the semantics of a HTML element can be expressed by an ARIA role, state or property. This is fiendishly known as the element’s ‘Default Implicit ARIA semantics‘
None of the elements defined in HTML4 need ARIA roles added to expose their default semantics. Adding an ARIA role is extra work for no gain and could lead to pain for you or somebody else. The new features defined in HTML5 , where implemented, now have their default semantics exposed by most browsers.
The HTML5 Specification includes this note:
In the majority of cases setting an ARIA
role
and/oraria-*
attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser.
Some examples of redundant ARIA
Adding default implicit roles to interactive elements listed in the HTML5 Recommendation is a waste of time:
<button role=”button”>press me</button>
Adding ARIA state or property attributes in addition to their native HTML counterparts is a waste of time:
<input type=”text” required aria-required=”true”>
<div hidden aria-hidden=”true”>
Adding ARIA roles and states or properties to long-implemented structural elements is a waste of time:
<h1 role=”heading” aria-level=”1″>heading text</h1>
What about the newish HTML5 structural elements?
HTML5 defined a new set of structural and sectioning elements with default implicit semantics that match ARIA roles (for some, only under certain conditions):
- article maps to role=article
- aside maps to role=complementary
- footer maps to role=contentinfo (if not within an article or section element)
- header maps to role=banner (if not within an article or section element)
- main maps to role=main
- nav maps to role=navigation
- section maps to role=region
What this means is that, where implemented, the browser will expose the default implicit semantics of the element so you don’t have to.
Although the main
element is the newest kid
on the block, it no longer needs a role added as its accessibility
semantics were implemented at the same time as the other aspects of it’s
implementation in browsers (except in IE).
The default implicit semantics implementation story
For the the structural elements newly minted in HTML5, the story is overall a good one. We are at a stage where all modern browsers (that support accessibility) implement the default semantics (except IE and though late to the party, they are finally implementing).
Bottom Line
In general, if it’s defined in the HTML5 Recommendation the feature does not need ARIA role, state and property attributes. So don’t do it, it’s just another point of code complexity and potential failure for no gain.
For the newish structural elements
Given the more robust support for structural element semantics (sans the outline algorithm aspect, but that’s another orthogonal story) I consider web developers should think about dropping the legacy HTML belt and ARIA braces approach. To that end HTML 5.1 is moving towards making all use of default implicit semantics as a SHOULD NOT normative requirement:
Default Implicit ARIA semantics – SHOULD NOT be used
This does not mean you can’t continue to, but is meant as a discouragement (think deprecation rather than obsolescence). So in the near future, if you check your HTML using a conformance checker, a warning will be flagged where it finds ARIA roles matching the default implict semantics of HTML elements.
For features defined in HTML 5.1, but not yet interoperably implemented
In some cases there are features absent from HTML5, but re-appear in HTML 5.1 (they were removed from HTML5 due to lack of implementations); details and summary or dialog elements are examples. For these elements it’s both fine and useful to add default semantics via ARIA as appropriate when using polyfils.