Updated: 3rd August 2020
The question of whether HTML elements need the addition of ARIA role attributes to expose their semantics, is one that surfaces on a regular basis. The answer is maybe for a subset of elements, but increasingly no.
Patrick Lauke modelling last seasons must have; HTML5 casual Polo neck with lumbar support [button] belt and [role] braces combo.
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 ARIA in HTML Specification includes this note:
Web developers MUST NOT use the ARIA
roleandaria-*attributes in a manner that conflicts with the semantics described in the § 2. Document conformance requirements for use of ARIA attributes in HTML table. Web developers SHOULD NOT set the ARIAroleandaria-*attributes to values that match the implicit ARIA semantics defined in the table.
Some examples of redundant ARIA
Adding default implicit roles to interactive elements listed in the HTML5 Recommendation is a waste of time:
Adding ARIA state or property attributes in addition to their native HTML counterparts is a waste of time:
aria-required=”true”>
Adding ARIA roles and states or properties to long-implemented structural elements is a waste of time:
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):
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 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.
Bottom Line
In general, if it’s defined in the HTML Specification 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 makes 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). If you check your HTML using a conformance checker, a warning will be flagged where it finds ARIA roles matching the default implicit semantics of HTML elements.
For features defined in HTML, but not yet interoperably implemented
The dialog element is an example. For such elements it’s both fine and useful to add default semantics via ARIA as appropriate when using polyfills.
