You Don't Need ARIA For That

by Dennis E. Lembrée published on Dec 02, 2022

In web development, writing semantic HTML is important for accessibility, and also provides some nice side effects such as supporting browser "reader" modes, SEO, graceful degradation, and exporting.

Implementing semantic HTML will also greatly reduce the need for ARIA (Accessible Rich Internet Applications). ARIA is a large set of HTML attributes to help accessibility for users of assistive technology, namely screen readers, by better supporting semantics not provided or not supported well via HTML.

ARIA usage certainly has its place. But overall, reduced usage of ARIA will, ironically, greatly increase accessibility. This is due to several reasons including:

1. ARIA is very often implemented incorrectly. This is well known in the industry, but for data, reference the WebAIM Million report which states “Home pages with ARIA present averaged 70% more detected errors than those without ARIA”.
2. ARIA may not be supported well (even when implemented correctly) by the browser and/or screen reader, which unfortunately is often the case. Reference a11ySupport.io and PowerMapper for related information.
3. ARIA isn't magic (as some web professionals seem to think!). Designs must still be accessible, inclusive, and usable.
4. ARIA only provides semantics. It doesn't provide any functionality. It doesn't provide any keyboard interaction that's often expected from certain ARIA patterns (the tab panel for example). It doesn't solve accessibility issues outside semantics for assistive technology (such as alternative text, color contrast, reading order, clear label text, captions, etc.)

The folllowing cases will illustrate how to use HTML properly so that ARIA is not required. In doing so, the techniques demonstrated will help developers follow the first rule of ARIA (to use HTML first if possible), as well as providing more robust code, and most likely, a more accessible experience for the user.

Use cases

The cases below are just a sampling of issues and include form labels, buttons, links, and images. I find them to be prevalent issues, and in fact I came across all of them “in the wild” (in live websites) over the last couple weeks. There is a bad version followed by a good one and then a note. For demonstration purposes, the code snippets are greatly simplified from the webpages in which they were found.

Remember that correcting the ARIA redundancies may seem trivial on the surface, but can go a long way in:

• reducing code complexity — less code!
• reducing maintenance issues — for example, use of one text node rather than duplicated (also, less code!)
• reducing accessibility errors due to value calculations by the browser — for example, the developer may not understand the accessible name calculation which can get a bit tricky.

Now let's get to the use cases!

Form labels

Example 1

Bad: redundant aria-label

<label class="...">
    <input aria-label="Pickup" name="Pickup" type="checkbox" class="... checked="">
    <svg...>...</svg> 
    Pickup
</label>

Good: use the inline text within the label (implicit association)

<label class="...">
    <input name="Pickup" type="checkbox" class="... checked="">
    <svg...>...</svg> 
    Pickup
</label>

Note: Remove aria-label for the win! The label wrapped around the input sufficiently provides an accessible name for the input.

Warning: this example implements implicit input labeling which may have issues with some assistive technology such as Dragon NaturallySpeaking. It's recommended to use explicit association as in Example 2.

Example 2

Bad: unwarranted use of aria-labelledby

<label class="..." id="sortBy">Sort By:</label>
<select aria-labelledby="sortBy" class="...">
	<option>Relevance</option>
	<option>Most Recent</option>
	<option>Value</option>
</select>

Good: use the for and id attributes for explicit association

<label class="..." for="sortBy">Sort By:</label>
<select id="sortBy" class="...">
	<option>Relevance</option>
	<option>Most Recent</option>
	<option>Value</option>
</select>

Note: Use fundamental HTML (and not ARIA) for the win! The for and id attributes provide an accessible name for the input.

Image in Button

Bad: redundant aria-label and unnecessary role

<button aria-label="Save $1 on Halloween candy and decor" class="...">
	<img role="presentation" src="1507288.jpg" alt="Save $1 on Halloween candy and decor">
</button>

Good

<button class="...">
	<img src="1507288.jpg" alt="Save $1 on Halloween candy and decor">
</button>

Note: Remove two ARIA attributes (and duplicate text) for the win! The alt attribute provides the accessible name for the button.

Linked text

Bad: overwriting pertinent content

<a aria-label="view location" href="/foobar..." class="...">
	<span data-qa="order-address-one" class="...">100 W Main St</span>
	<span data-qa="order-address-city" class="...">Strangeville, OH 48000</span>
</a>

Good: use the existing inline text

<a href="/foobar..." class="...">
	<span data-qa="order-address-one" class="...">100 W Main St</span>
	<span data-qa="order-address-city" class="...">Strangeville, OH 48000</span>
</a>

Note: There's no need to be overzealous here; the aria-label overwrites the address text as the link name, therefore the address text is not accessible to screen reader users. Linking the address text is sufficient.

Linked images

Bad: redundant aria-label

<a class="..." aria-label="Earn Cash Back" href="/foo">
    <img class="..." alt="Earn Cash Back" src="foo.png" width="100" height="100">
</a>

Good: use the alt text only

<a class="..." href="/foo">
    <img class="..." alt="Earn Cash Back" src="foo.png" width="100" height="100">
</a>

Note: Remove aria-label and use fundamental HTML for the win! The alt attribute provides the link content.

Decorative images

Bad: role attribute used to denote decorative image

<img role="presentation" src="foo.jpg" alt="a star, a twirl shape, a balloon">

Good: use an empty alt value

<img src="foo.jpg" alt="">

Note: Remove the role attribute (and remove the alt value) for the win! The empty alt attribute denotes that this is a decorative image.

Script

Bad: aria-hidden on script tag

<script aria-hidden="true">

Good: nothing extra needed for accessibility

<script>

Note: Remove aria-hidden for the win! Script content (inline JavaScript) isn't output by assistive tech.

Summary

Removing ARIA redundancy can reduce code complexity, maintenance issues, and the chance of accessibility errors. Reducing reliance on ARIA makes code more simple and will most likely increase accessibility.

Writing semantic HTML is important for accessibility and also has other benefits. Semantic HTML will greatly reduce the need for ARIA, which is often implemented incorrectly and may not be fully supported. Be sure to use HTML first before using ARIA, such as when coding form labels, buttons and links, and decorative images.

Further reading

• ARIA and HTML on web.dev
• What Is ARIA Even For Webbed Briefs by Heydon Pickering
• Myth: ARIA has perfect support
• ARIA Serious‽ presentation October 2019 by Eric Eggert
• Web Accessibility Gone Wild by WebAIM

About Dennis E. Lembrée

Dennis is a Senior Accessibility Consultant at Deque Systems. He previously led accessibility at eBay and Diamond Web Services. He has many years experience in writing and presenting on digital accessibility. Dennis is also the proud creator of Web Axe and Easy Chirp.

Home Page: dennislembree.com
LinkedIn: lembree
Mastodon: @dennisl@mastodon.social
Twitter: @dennisl
Instagram: dlembree