First rule of ARIA – do not use ARIA – and why it is so important

(Read 554 times)

Why are we not encouraged to use ARIA everywhere? Because it is a last option – if we are not able to find a native semantic element, or if we want to create something special, then we can use ARIA. But it should be used wisely!

OK, the title may be a bit strange but please let me explain;

Developers can all too often skip HTML semantics – especially in single page (SPA) app’s – and potentially making their products less accessible or sometimes even over-engineering the non-semantic elements with a lot of ARIA that could actually not work well or not work at all for assistive technology users.

What can potentially prevent developers to use semantic elements

I’ve seen some examples where ARIA drastically degrades usability and accessibility for Screen-reader users. We can only guess of the motives that make developers not wanting to use semantic elements that can bring so much better usability and at the same time good technical Search Engine Optimization (SEO) – but I have been in some situations in the past where it could make sense to not use semantic elements. So I can maybe try to guess one of possible motives;

If a developer thinks of an component for a single page application (SPA) that has to actually work in all possible contexts, then it is easy to just drop the semantic elements and use plain div’s and span’s so that our end-product – a small component does not cause potential invalidation of the HTML when seen in different positions. So that the continuous delivery (CD) or continuous integration (CI) with all it’s checks will not be failing due to possible HTML validator rules or maybe even when we get to local integrated development environment (IDE) and some lint-ing that can be helpful but easily thought as annoying to the developer.

Why can use of ARIA be a problem if not using it correctly

Well – there are a lot of rules to take into account and if we are ignoring them then we can create illusions of valid code that we are sure is working well but not testing it with real assistive technology users can make the code being sent to production and actually disabling the assistive technology users in their tasks. There are user experience (UX) rules that we must respect, hierarchies that need to be implemented correctly, user interactions that have to be made correctly and so on.

Not to get into too much of details as it requires a lot of different posts:

  1. always use semantic element if your task can be done with native – but be cautious with more recent elements as their support may not be “good enough”.
  2. if/when you use ARIA you should also check for cross-platform support. It may work on your MAC but not on someone’s PC with NVDA and Firefox – please check links in resources at the end of this post
  3. if/when you use ARIA – please do check established patterns for it (tab, space, enter, arrow keys etc. can be quickly left out and if it does not work with keyboard only, then it is not accessible),
  4. if you are creating something really custom then it should really be tested with “real” assistive technology users or you could do more harm than good for the accessibility.

ARIA is not a silver bullet that solves all our “unsemantic” problems

Sometimes we are used of using some special HTML attributes that make our planned interactions easier. And it can quickly be the case when we want to enrich our non-semantic custom element with ARIA. But again – there are rules and patterns and best practices and compatibility issues, so it takes experience and real user testing to be adequate in writing complex rich internet applications.

ARIA tag here and there will not be the correct solution. It has to be done correctly and it must also be tested correctly.

First rule of ARIA – do not use ARIA!

A bit funny title maybe – but I am really trying to get your attention here.

So where did I get this do not use ARIA? I’m referring to the official documentation – practical guide for developers on how to add accessibility information to HTML (opens in new window).

If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

First Rule of ARIA Use, from the practical guide for developers

What are possible problems with ARIA

Well – in short – it does not work for everybody.

If you are a developer – you have probably been on to check support of any given web technology. If you search for ARIA then be ready for a surprise; (opens in new window)

And again – if you came so long in this post, then I have another surprise for you – there are a lot of combinations that has to be taken in account when discussing the cross assistive technology support of Accessible Rich Internet Applications and this page really summons it good: tests for plethora of screen-readers and browsers combinations and their ARIA support (opens in new window).

So – again – please be careful. As the cliche goes:

With great power there must also come great responsibility

Peter Parker principle from Spider-Man comic by Stan Lee that can actually be applied in real life too.

Use ARIA only when you are really sure to know what you are doing and please do test it properly!

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Agency co-owner web developer and accessibility lead at day.
Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) by night.

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).
Tweets @CerovacBogdan

Nurturing the web from 1999, this blog from 2019.