On HTML belts and ARIA braces (The Default Implicit ARIA semantics they didn’t want you to know about)

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.

male torso with belt and braces.

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 role and 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 role and 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:

<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):

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.

Source link

Skip to content