The latest WebAIM Million has come out. For those who are unaware, it is an automated accessibility evaluation of the top 1 Million home pages. While it is an automated test which only finds a subset of accessibility barriers, its results can at least show us trends:

• Average errors per home page went slightly down to 50 errors.
• 96.3% of home pages still have easily detectable WCAG failures. That is only a decrease of 1.5% in four years.
• 96.1% of errors fall in six categories:
  • Low contrast text
  • Missing alternative text for images
  • Empty links
  • Missing form input labels
  • Empty buttons
  • Missing document language
• The use of ARIA (Accessible Rich Internet Applications) has increased a lot. And home pages that use ARIA are more likely to be inaccessible.

The shocking truth is, that we cannot make the web accessible at a rate of 5000 websites per year. There are gigantic Diversity, Equity, and Inclusion programs, and they barely make a dent in the actual accessibility of websites. Where are the commitments, where are the action plans? It’s just the home page, we should have shamed — sorry, encouraged — people to at least get their home pages in order.

Also, the 96% of issues that are found on websites? These are not new requirements. They all have been around since WCAG 1.0¹ which was released in 1999 and will celebrate its 24th birthday in May. The same principles have been carried over in the 2.0 and 2.1 standards released in 2008 and 2018.

A quarter of a century and basic accessibility is not met by 96% of home pages. I find this fact embarrassing. Mostly as a web developer because fixing those six issues can be learned in a day. If you are a web developer who does not know how to fix them, read these two excellent articles from Hidde now: Post 1, Post 2.

But I also find it embarrassing for web accessibility. We should have better strategies to educate people about the issues, provide them with actionable feedback and make sure that issues are effectively addressed.

For other issues, we should explore how to minimize the impact on disabled people by using browsers to mitigate issues. A ramp built into a train will generally be more available than a situation where every stop needs to provide its own ramp.²

Mitigation for low contrast text could be done by the browser directly: Fixa11y is a browser plugin that detects low contrast text and adjusts it to meet minimum or even high contrast scenarios. If this was built into browsers, it would take the burden from implementors, and allow users to customize their experience.

But the browser cannot do everything. Alternative texts need to be customized and fit into the page and context where they are. Automated image recognition is getting better, but it is far from context-aware enough to rely on it daily. That said, it is technically possible to add a default, maybe very detailed description to image files, especially if they are package files. Those detailed image descriptions would travel with the file and be available as a fallback option in case no context alternative text is provided.

Empty links and buttons, as well as unlabeled form elements, should be part of the browser’s console error messages. There is no reason why JavaScript programming errors trigger messages, and accessibility issues do not. Tooling is bizarrely oblivious to accessibility.

Essential ARIA functionality must be transferred into HTML. ARIA needs to be a specialist tool that you only get out if you don’t have any other options. Many of the ARIA techniques are very intricate and for 90% of developers they should never be exposed to that kind of complexity and power.

In the end, we must guarantee an accessible web that everyone can use and adjust to their needs. This is the basic promise of the web, a promise that is broken every day.

Some people think it’s the standard, and if we quickly work on a version 3 of WCAG, all will fall into place. I don’t buy that. We have standards for almost a quarter of a century and people are unable or unwilling to follow them. Rephrasing the basic principles – that content must be perceivable, understandable, operable, and robust – will not move the needle towards an inclusive web. In the best case, web accessibility will drag on. In the worst case, we will have multiple standards to follow that have entirely unique ideas of how to test and measure accessibility.

And we have a good standard. WCAG 2 has its weaknesses, but meaningful evolution is possible if the Working Group wants it.

After many, many, years of trying to make the web accessible doing the same things, maybe it is time to re-evaluate. Take a look at the list of issues and develop a strategy on how to address each of them. Look holistically where these issues are introduced and how we can start to prevent them. The current strategy of “here are rules, deal with them, goodbye” has not worked, and the rules don’t go away while we remove the systematic issues plaguing accessibility.

I wrote about this topic before in Fix web accessibility systematically and spoke about it in my talk Web Accessibility is broken. It’s time to fix it!