Accessibility training can sometimes harm accessibility

Number of words: 858.

(Loaded 2299 times)

A little knowledge is a dangerous thing proverb goes also for accessibility. When we are motivated to implement newly acquired knowledge after a training we can quickly start overusing techniques and can even make our product less accessible.

Just re-evaluated fixes done for a public sector website that I audited almost a year ago and noticed some things that now seem to be worse that when I did the first audit. Generally speaking the website was better, but there were some patterns in code that made me wonder.

It was obvious that site was tested with automatic accessibility testing tools as scores on almost all pages were superb, majority of pages with zero automatically detectable accessibility issues. But when I opened the developer tools in the browser and checked the interesting parts it was obvious that some parts of the code were even less accessible than before.

I talked to stakeholders and they said that all developers went through multiple accessibility trainings. All of them were self-paced online courses from famous online learning providers where they covered whole of Web Content Accessibility Guidelines (WCAG) from the perspective of a developer.

This means that they invested two working days to cover all of WCAG from code perspective. I checked the courses and they were OK, some parts were selling best practices as WCAG requirements, but generally speaking a lot of the content were OK.

I didn’t get the opportunity to talk to the developers, but checking the code of the website updates and fixes based on my audit revealed some concerns.

First symptom – overusing ARIA

Overusing Accessible Rich Internet Applications (ARIA) is a typical indication of over-engineering and it seems that it’s also a typical reaction to accessibility trainings. It seems that the first rule of ARIA – don’t use ARIA if you can use HTML is ignored and I suspect forgotten way too often.

Typical problems when ARIA is obviously overused:

  • Using aria-label on a div element with no other semantics.
  • Using aria-label on a link or a button that uses text.
  • Adding role=”menu” to normal website navigation.
  • Adding aria-hidden to already hidden elements.
  • Using role=”application” for a simple widget.
  • Using role=”button” on a link with href=”#”.

Use ARIA when you absolutely must. Unfortunately there are a lot of cases when pure HTML elements won’t do, so we need to use ARIA to complement missing semantics. That’s a fact. But we need to use the HTML before we reach out to ARIA.

It can maybe also explain why WebAIM’s Million found that increased use of ARIA is associated with more detected accessibility issues (opens in new window).

We need to consider before using ARIA!

Second symptom – overusing tabindex

Testing with keyboard is a brilliant simple accessibility test that all developers need to do. But adding tabindex with positive values is an indication of a big problem that somebody wanted to fix with low effort and understanding. Automatic accessibility testing tools help us here as they often mark such elements and we need to react.

But what about all the tabindex=”0″ on non-interactive elements. I think that this is another potential symptom of accessibility training that may be misunderstood.

Adding tabindex=”0″ to non-interactive elements is perhaps done in good faith that people will be able to use the keyboard on them, but in reality it just adds tab stops to the page for people that want their tab stops to be limited to interactive elements.

Third symptom – too many skip links

I’ve never seen 5 different skip links on a normal website. I understand using them on a large website like for example a giant e-commerce with hundreds of products in different categories, but on a simple website with header, main and footer, a couple of components and some basic navigation it’s an overkill.

Again, I believe somebody remembered how useful skip links are, but adding a skip link to footer navigation and a skip link to header and a skip link to image gallery is actually doing the opposite of having a skip link in the first place and only adding tab stops to users.

Conclusion – learn more and don’t overcomplicate

Before learning about accessibility we should have a proper understanding of possibilities in the HTML. Only then we should reach for ARIA to complement missing states and other properties. This is actually what the first rule of ARIA is about – use HTML before reaching to ARIA.

As software developers we are kind of used to reach out for code based solutions, and that’s a good thing. But sometimes copy pasting without thinking about end results and all of the implications can be dangerous. Especially if we don’t also understand side effects, like for example that aria-label overrides the visual text and can be therefore extremely dangerous for screen-reader users.

Training is the right thing to do, please don’t get me wrong, but it also needs revisiting the basics before reaching out to advanced parts. We should start learning of accessibility with HTML before even hearing about ARIA and then extending HTML with ARIA.

Author: Bogdan Cerovac

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

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

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

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: