Web accessibility is incredibly important. The web is the prime medium for information, education, entertainment, and social interaction. And it still is incredibly inaccessible to many people. According to WebAIM’s assessment of one million home pages, 97.4% of them had easily detectable failures.

Today starts W3C’s TPAC Conference. It’s where all W3C groups have an opportunity to meet and make sure that they work to bring the web forward. There is usually a lot of accessibility going on, but it is far from embedded across the organization. That has structural reasons (W3C’s Web Accessibility Initiative — WAI — is a dedicated section inside W3C) and while WAI checks all specifications for accessibility, most are not developed with accessibility in mind from the beginning.

And even the specifications that are developed for accessibility, have significant adoption problems. The only accessibility standard that got real traction is the Web Content Accessibility Guidelines (WCAG) 2. There is also ATAG 2.0, the standard for authoring tools, which is basically everything that creates web content (blog engines, social media sites, video sharing), but few tools adapt parts from it, let alone everything.

UAAG 2.0, the standard with the goal to make browsers and other user agents accessible, did not even get published as a standard, but as a working group note. There was not enough consensus to make it a requirement for browsers.

Another standard that W3C/WAI develops is ARIA (Accessible Rich Internet Applications)¹ , which provides roles, states, and properties to make rich user interfaces accessible. It is a whole different set of semantics that you can add on top of HTML to make your website more accessible. It can also be used in other technologies, like ePub or PDF.

While developers would have used ARIA initially to adapt their HTML to the API for screen readers in complex situations, these days ARIA is almost a must-have even on the simplest website. If you have two navigation areas on the page, let’s say a visually horizontal main navigation and a vertical sub-navigation, it’s common to give them names. There is no mechanism to do that in HTML, so you have to go back to ARIA for that.

Accessibility got complicated and unpredictable

To build an accessible product, you need to know how all of these technologies interact and how you can combine them to create an accessible experience. You have to know what an accessible name is and if the aria-label attribute overwrites the aria-labelledby attribute. (It does not.)²

W3C provides a host of additional specifications for that, like the ARIA Authoring Practices³ , which demonstrates how ARIA works. But its examples do not reflect HTML best practices, as it is technologically neutral.⁴ There is also HTML Accessibility API Mappings, which explains the relationship of how HTML maps to accessibility APIs, especially when using ARIA. And the ARIA in HTML specification, that gives advice on how to use ARIA in the first place when using HTML.

On top, you need to understand the capabilities of assistive technology and how it can actually use some of these technologies. Due to the vast market of assistive technologies, there is always uncertainty. And that HTML elements, like <input type="date">, which are standardized for over a decade now, lack accessibility support in modern browsers does not make it easy for developers.

“Don’t use ARIA unless you have to” is a common phrase uttered by accessibility experts, but how are ordinary developers supposed to know when they have to? The education around accessibility is abysmal and instead of making sure that it is really clear what to use in what situations, we just leave it to designers and developers to make these critical decisions.

WCAG 3 will not fix that issue

A lot of people have high hopes for WCAG 3 (the then likely renamed W3C Accessibility Guidelines⁵ ). But accessibility testing is the least of our problems. Nothing will magically let developers understand how to achieve a certain outcome⁶ when WCAG 3 gets to recommendation status. It won’t make any of the interplay of the technologies easier. (And the jury is out if it will actually improve accessibility testing.)

We need a combined effort

There already is some wiggle room in accessibility: What alternative text is correct in what situation? Is something a button or a link? It is good that we can make decisions depending on the context, as the web is such a complex medium.

But if something is in ARIA, it should have the defined result in the DOM and AOM⁷ and thus a predictable outcome in assistive technologies.

For example, if you currently specify aria-haspopup="dialog", most screen readers will announce that a menu will pop up. That's not super useful.

This lack of predictability and interoperability hurts users. Developers cannot rely on the technology to work, which takes up resources that could be better spent elsewhere.

Initially, when we talked about ARIA, the plan was that most aspects of it would be converted into native HTML quickly. Combo boxes, dialogs, tab panels⁸ . The promised land of a world with natively accessible features right out of the box, it did not come to pass.

Instead, ARIA is now a meta language that sits between technologies, defining an accessibility vocabulary for them. This led to the interesting development that ARIA takes on features of HTML instead of the other way around. ARIA now even has a paragraph role.

Who can blame developers when they skip over searching HTML and go directly to ARIA — it has accessible in the name, after all. But ARIA is a much less forgiving and can be much more damaging than a bad HTML element somewhere usually is. And it also is more complicated. Some roles must be inside other roles. Using certain roles demands implementing predictable keyboard navigation (and no, you do not get that for free).

What to do?

I think we need to make sure that accessibility implementation is predictable, easy to understand and error tolerant. With the heavy reliance on ARIA, and barely any movement of getting accessibility into the core technologies⁹ , we made accessibility hard to understand for most developers and added more and more variables. And that is all before actual support for assistive technologies.

To make it easier to use, we have to bring accessibility back and modernize existing basic standards. It will simplify documentation, improve reliability, make errors easier to detect. And it will help to make accessibility easier to teach.

And browsers must do their fair share of it, too. Why is there no console warning, when a form field is missing a label? Why can I pollute my HTML with nonsensical ARIA attributes without the browser even raising an eyebrow? Every role="link" should yield a “Didn’t you want to use an a element instead?” message.

If we want the web to be “for everyone”, its tools must be for everyone, too. And that begins with accessible core ingredients like HTML.

Did you like this article? Support my independent work with just €5/month.

Update 2021-10-20: Added footnote regarding Open UI tab panel explorations.
Update: 2021-10-23: Corrected aria-labelledby overwriting aria-label.