Common ARIA problems found in accessibility audits

We need to use ARIA when HTML is not enough (and in rare cases when we don’t want to). That adds another layer of opportunities and complexity to a website / web application and in my experience people don’t think (enough) about it when using ARIA.

We need to consider a lot of things already, but when adding ARIA we need to consider how supported it is, what are the internal rules for specific elements and so on. It’s not enough to just use it and trust that everything will work for all ARIA attributes. There are things that are not supported in assistive technology, sometimes work differently with different combinations, sometimes implementations have bugs and so on.

To make the experience more accessible we need to be aware of this, otherwise we cause potentially even worse experiences, although believing that we have done our part.

So – what can go wrong when using ARIA?

These are only some common ARIA issues I’ve experienced and absolutely not all possible. I hope that writing about them can help people avoiding them in the first place.

1. aria-label used to overwrite visible text and not(!) including the visible text in the aria-label – failing WCAG 2.5.3 Label in Name. Also forgetting the best practice to have the visible text at the start of the name.
2. aria-errormessage – using aria-errormessage to connect error texts with form fields is not very supported in practice. I hope it will be soon, but at the moment it is not. That means that some screen-reader and browser combinations don’t work and may cause huge issues for people. Still best to use aria-description at the moment.
3. Wrong or missing IDs referenced in ARIA – sometimes page has duplicate ID values due to re-usage of components when somebody hard-coded it. And if those texts differ, then only the first value is used (as there can only be one ID). Often also missing or wrong ID values that break the experience.
4. Wrong ARIA attributes – sometimes people don’t remember ARIA attributes correctly and if they don’t test (or use linting or other automatic tools to check the code) it can break accessibility. Common problem with aria-labeledby (which should be aria-labelledby). Please use lint in your IDE and prevent it in the first place.
5. Missing required ARIA structure – if you use ARIA attributes that require proper hierarchy (for example role="list" needs to have immediate child elements with role="listitem", and there are more ARIA attributes that require following rules). Know the standard, use linting.
6. Misunderstanding attribute priority (aria-labelledby has higher priority than aria-label). Often there can be confusion if people don’t understand that. It’s also common for people mix ARIA attributes, often I see aria-describedby used instead of aria-labelledby which can be a huge problem in some scenarios.
7. Injecting aria-live regions dynamically into the page makes us think we have done our job if we don’t test it properly. Some screen-readers don’t actually use such live regions and need to have them in the DOM when loading the page. Dynamically injecting them may be totally ineffective.
8. Overwriting HTML semantics (basically ignoring second ARIA rule (“Do not change native semantics, unless you really have to”)) is sometimes a big problem and should be avoided. There are also exceptions to this rule, but that is out of the scope of this post…
9. Overusing ARIA (for example adding aria-label on non-interactive elements that are not landmarks). Too much ARIA is a real problem sometimes. I wrote about this in Accessibility training can sometimes harm accessibility.
10. JavaScript errors that cause ARIA logic to fail – you know – those global JavaScript errors that stops the whole code to execute and with it also stop all of our accessibility efforts made with ARIA.
11. Adding ARIA attributes after interactions – often I see aria-expanded added to elements only after the user has clicked them. Sometimes this is dangerous as users need to know that button will expand something beforehand…

Mind that these are just some of issues with ARIA that I stumbled upon and the list is probably just scratching the surface.

You can find even more examples on HTMHell.dev (opens in new window) where you will also be able to read on HTML issues and how to fix them.

The more ARIA you use the larger are chances that you will introduce additional accessibility problems. WebAIM’s project Million on ARIA (opens in new window) is also an important source where we can observe a pattern that using more ARIA is often causing more problems. Even if it is a bit biased – when we know that automatic accessibility tools are really good in revealing code based accessibility issues and that means that we will find more issues when ARIA is present. (“This does not necessarily mean that ARIA introduced these errors (these pages are more complex), but pages typically had more errors when ARIA was present.”)