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.
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
aria-*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 ARIA
aria-*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:
<input type=”text” required
Adding ARIA roles and states or properties to long-implemented structural elements is a waste of time:
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 (scoped to the
- header maps to role=banner (scoped to the
- main maps to role=main
- nav maps to role=navigation
- section maps to role=region (if the
sectionelement has an accessible name).
What this means is that, where implemented, the browser will expose the default implicit semantics of the element so you don’t have to.
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.
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.
30 Responses on the article “On HTML belts and ARIA braces (The Default Implicit ARIA semantics they didn’t want you to know about)”
As someone that has been building a lot of ARIA features into an existing application (and adding HTML5 where appropriate) I appreciate the clarity of this post. I think I have been guilty of adding the role=”navigation” to the nav element and know I have been guilty of contentinfo for footer.
Was that shirt a real thing? I’ve gotta start going to conferences if that’s the case. :)
Hi Brian, no guilt needed as support for native HTML features improves, the advice for using ARIA changes. Note, I wrote in regards to structural elements:
I am viewing this from the perspective of a spec editor, thinking about where HTML conformance requirements should be steering developers, so may be considered slightly ahead of the curve in regards to structural elements, though the other advice on default implicit semantics of established features is overdue.
In ARIA 1.1 if the native host language semantic means the same as an ARIA role you don’t need to add the role attribute. ARIA 1.0 was designed for HTML4 and above and HTML4 defined no native host language semantics.
What is happening, however is that web apps are moving away from the DOM and using web components whereby they won’t be using the HTML DOM and instead will have an object tree. Here they want to reproduce all the HTML semantics in ARIA – even “blockquote” as there are no native host language semantics. So, there are two camps evolving.
What about the
hiddenattribute? Are browsers supporting it well, or do we still need to use
Hi Tiffany, in browsers that support the
hiddenattribute there is no need to use
aria-hidden=true. Similarly there is no need to use
If we’re supporting older versions of IE (<= 10), is there a case for including role attributes for those older browsers that don't honour the default implicit semantics?
Hi Matt, for established features, there is no case. For features that require a polyfil in older browsers (due to lack of support) there is. This is why the conformance requirement is a SHOULD NOT, rather than MUST NOT.
Fun fact: in the stale WHATWG version of the ARIA conformance requirements it has been a MUST NOT to set default implicit semantics for years, but as this has not been implemented in a HTML conformance checker, no one has noticed.
Thanks for the clarity. :)
Does it mean that ARIA itself is going to “die” or something ?
On the contrary, the need for ARIA increases with the use of technologies such as web components.
Thanks for this Steve. We have been teaching students the ‘belt and braces’ approach for a few years now. It’s good to see that we can now pull back from this. That said, we start them off with non-semantic structures such as
< div class="nav">. I guess we can still add the relevant roles as a way of introducing the concept, and then remove them as we move on to the semantic tags for structure [just thinking out aloud].
Anyway, thanks for the update. :)
Good article as usual. What’s the best way to handle instances where some browsers (like IE) haven’t adopted HTML5 elements and you have to code for a variety of browsers?
Hi Mike, does this comment not provide enough clarity?
Hi Steve–Guess I’m not familiar with the term polyfil. Are you talking about browser-sniffing?
Mike: What is a Polyfill?
Steve said “On the contrary, the need for ARIA increases with the use of technologies such as web components”.
How well the screen readers support ARIA + Web Components ?
Pretty much the same as how well they support any custom UI built from
<span>s + ARIA
These maybe helfpul:
So, is there a polyfill (preferably hosted by on a CDN and one that does NOT require jQuery) that actually takes care of adding all of the ARIA related features for older browsers?
Thanks Steve for the clarification about screen readers support.
Your two links with examples are very useful to see the use of ARIA in web components, especially using the Firefox inspector to see the structure. For exampke, the web component paper-button:
Only one thing. This link in your punch list web page does not work:
Perhaps ir could be change with this:
Hi Steve, It makes sense to use less attributes where possible and that HTML5 native tags implement the roles by default.
However I have been told by several accessibility experts that many of the most common screen readers out there (eg. JAWS) still do not do a good job of understanding native elements and that you should always add the role to be safe. was one specific example.
Which elements? In combination with which browsers?
For example the native landmarks on this structural elements test page are reported correctly by JAWS 14 and NVDA 2015 in Chrome and Firefox.
I was told NAV without role=’navigation’ would not be picked up by JAWS. Perhaps it was an older version of JAWS or they were mistaken.
What do you recommend as a reference guide as to which elements work with which accessibility aides (ie. screen readers)?
Steve, can you explain a bit how does the default implicit ARIA semantics work for nested structural elements? E.g. if the
<main>content area of the page contains a couple of
<article>s and one
<article>has a pull quote inside it marked with
<aside>. Won’t the element with implicit
role="complementary"inside an element with implicit
role="main"mess up anything since these roles are not expected to be each other’s descendants?
There is no prohibition of use for
<main>as it is not prohibited or even discouraged to use
role="complementary"inside an element with implicit
The definition of role=complementary
So complemntary content can be part of the main flow of content, but it’s seperation will not result in either the main content or complementary content losing meaning.
@Davide it could be current/new versions of JAWS support while older ones didn’t. I remember when NVDA was newly implementing landmark roles and having a nav role=”navigation” caused it to announce navigation twice (once from the element, and once from the author-added manual role). This was a particular bug in a particular version, later patched.
Since users of non-free AT like JAWS or Dragon are more likely to have non-bleeding-edge/newest versions, I would think that if you thought you were supporting many of those folks that you would maybe still add in those roles… Steve? Especially if older AT is also holding you back to older browsers, as ZoomText kept me at IE9 for a long time (would not make legible text on higher versions of IE).
We’re still using divs with roles at our company simply because we know for certain many/most of our clients are sticking with ancient versions of IE, and so are *their* clients. When we know they’ve simply been forced to upgrade (WinXP upgrading to Win7 for example), we’ll be able to update our code with the new native elements, and there we have no plans to also add default roles.
Steve, thank you for the reply, but the definition I see by the link in your answer is a bit different than you quoted:
What makes me worry about is the “at a similar level in the DOM hierarchy” part. Doesn’t it mean that elements with these roles are supposed to be more like kind of siblings than like ancestor/descendant of each other? Or maybe the spec has changed and this part is not relevant any more?
And in general, doesn’t the deep nesting of HTML5 structural elements affect their implicit semantic for the accessibility tree (except differences for
footermentioned in the article)?
ARIA Host languages (in this case HTML) define what is premissable and what is not. There is no normative requirment (or informative advice) in regards to restricting the use of role=complementary or <aside> as children of <article> etc. elements in HTML. The text you quoted from ARIA is not normative and is vague. I would not sweat on this issue.
Absolutely love this article. Telling the truth like it is! So much of modern web industry discussion is like reading the unwavering dogma from a cult manifesto.
The truth about a11y is that most of it is a nightmare for developers. A nightmare produced by incredibly vague, unfinished or immature standards and a huge user agent mess.
What exactly is the point of having tags with more semantic meaning if browser devs don’t pass on that meaning to whichever tools benefit from it? Developers and site authors get zero benefit from a element compared to a element. Adding role or aria-* attributes with duplicate naming to the elements they’re within is just ludicrous.
So much of a11y on the web is way behind the mainstream web because of poor interaction between the browser and host OS. This is embodied by the mentality to not develop for standards (which admittedly are vague and slow to develop) but to develop for a particular application like JAWS. That’s like developing for one browser alone. As much as the poor disabled out there may love and rely on X screen reader application, it’s up to those applications to conform to standards set by the appropriate bodies just like it’s up to developers to try and conform to presenting content in a manner that supports those standards.
Centralize around standards! Content editors and developers, browser developers, screen reader develepers … everyone needs to centre their efforts around a (better, sensible) standard. Otherwise it’s just chaos. The sort of chaos that forces governments to step in and regulate with section 508 and so forth.
Just wondered on events like ‘aria-pressed’ and ‘aria-expanded’ – I currently use these on <summary> elements within <details>, but guessing this is not needed in likes of Chrome (which supports <details> natively) – only useful for unsupported browsers, like Firefox?
right, chrome has now implemnted the semantics for summary/details
Steve you didn’t get round to saying if there is s polyfils for older browsers. Obviously that is only part of the problem, for example older browser will have shortcomings in what they expose to AT via the APIs so a polyfil may not be that usefull.
However I won’t to follow progressive enhancement were possible and not make too many assumptions about the kit users have and how they use it.
Leave a Reply to Brian LePore