Role-playing game

Many misunderstandings prevail on the web around the topic of WAI-ARIA. Some folks are aware that only a responsible use of ARIA attributes is the way to go. The others consider the toolset ARIA provides to be a quick way to create accessibility by attribute, and according to the credo: the more the better.

The latter attitude, in particular, is a dangerous one. I would like to explain why this is so in this short article. In order to better explain the danger posed by the wrong approach to ARIA, here are two short but important basics:

What ARIA is

WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is a technical specification, similar to HTML and CSS, that gives us a toolbox for a dynamic web. It gives us the ability to extend HTML to communicate webapp-specific states, relationships, and properties to assistive technologies (e.g., "expanded", "invalid", or "labeled by this one element"). The role attribute can further be used to override the semantic role of an element. Sounds innocent, but it has extreme accessibility implications: for example, a <ul role="heading"> is no longer an unordered list (this is the role <ul> elements have "by nature"), but a heading.

What ARIA is not

While ARIA roles themselves do not implement any functions - they only announce them to assistive technologies! Accordingly, the saying "a role is a promise" is central. Many people do not realize exactly this crucial point. If one - for whatever reason - converts a <div> to a button, the first step is usually <div role="button">, i.e. an assignment of a so-called explicit role.

The central misunderstanding

The tragedy here is that for many, this "role conversion" is also already the final step. In doing so, it announces to screen readers, for example, that this former <div> is now a button (a promise is made). But now some crucial points are missing to keep the promise. Let's stay with the button example:

• Since I am now a button, you can also reach me via keyboard. This is a promise that is not fulfilled by <div role="button"> alone. To make the example div keyboard-accessible, an explicit inclusion in the tab index, e.g. via tabindex="0" is necessary.
• Since I am a button, I can be activated by keyboard. It is common for buttons to respond to the spacebar and enter key. Also this is a promise that is not fulfilled by <div role="button"> alone. So you have to register a keyboard event listener in JavaScript here that responds to space and enter keys when the "button" is in keyboard focus.

And this only applies to a seemingly simple role like button. If you want to get an overview of exactly which usage promises you make with which semantic role, the ARIA Authoring Practices Patterns should be recommended, and there especially the respective section "Keyboard Interaction".

By the way, it is much easier to use a native HTML element than to have all this in mind. This means that you should prefer the <button> element to an ARIA role change wherever possible. This is because native elements not only inherently bring promises (I am a button), but also deliver on them at the same time (I pass spacebar and enter key events to my click event handler without further ado).

So when accessibility experts give you advice over and over again to use classic HTML elements instead of their ARIA "counterparts", it has mostly to do with this central issue. It's something known as the first ARIA rule. Rebuilding a native element using only ARIA means is possible, but complicated, because you have to think of everything the element is able and promises to do (and implement exactly that manually yourself). So if you have a choice and can rely on native HTML elements. The famous "developer experience" and accessibility go hand in hand here, because in the end, why reinventing the wheel when a shop is nearby?