Two Approaches to Accessibility on the Web

Published on May 10, 2022 (updated Feb 5, 2024), filed under development, accessibility (feed). (Share this on Mastodon or Bluesky?)

One can distinguish at least two approaches to accessibility on the Web. One approach is to produce accessible websites and apps, and to keep or make them more accessible: active accessibility. The other is to produce accessible-making software, including user agents, and to maintain and improve that: passive accessibility. ^*

The first approach is by and large being reflected by web content and authoring tool accessibility guidelines. For the second one, there are user agent accessibility guidelines. (Of course, accessibility guidelines don’t have to come and don’t only come from the W3C.)

Author-Centered Accessibility

When looking at the two approaches, one may get the idea that the field of web accessibility usually favors the first approach. If that is so, which is the working hypothesis of this article, it misses an opportunity. It also puts undue (and maybe unfair) pressure on developers and site owners when it comes to everything that’s more efficiently addressed on the software end.

Making strides for accessibility should be easier through software, because working with a few dozen major vendors—around assistive technology, browsers, and operating systems—must be likelier and faster to lead to success than asking hundreds of thousands developers to do something on close to two billion websites.

Why would we have a situation like this? Maybe it feels easier to tell developers what to do than it is to do the same with implementers. Also, of course, some accessibility problems are hard. (As software needs time to beat what developers and site owners can accomplish—those who can be reached through rules—, the software approach may trigger resistance, too. One example from personal experience includes criticism of the idea of making language declaration and detection a software challenge, not a development requirement.) But besides communication preferences and internal resistance, vendors may be difficult to work with—on the screen reader side, for example, there doesn’t seem to be a Google pulling and uniting the entire field, as with the Chrome ecosystem.

Now, certainly this misses something, particularly viewpoints and reports from accessibility evangelists. After all, the work with vendors may just get a lot less visibility, and maybe this turns out to be the biggest problem. But it seems hard to deny a reflex in our field, that when something is considered an accessibility problem, we defer responsibility to developers and site owners, with sometimes little consideration of the severity of the issue (a separate problem to review), and—again the hypothesis of this post—perhaps insufficient checking, asking, and lobbying that it be solved by software.

…Won’t Lead to Automagical Access

What if instead of preferring active accessibility, our default was to focus on passive accessibility, that is, accessibility on the software end; if that wouldn’t work, to keep pushing on the software end; if that wouldn’t work, to push even harder on the software end, but to provide developers with guidance on the absolute minimum they can do to mitigate; and if that wouldn’t work, to still keep pushing for a software solution and add carefully to what we expect from developers and site owners?

Yet one may disagree.

Maybe there are ways to show how accessibility was only to be accomplished through rules for developers and site owners.

But no one seems to be able to show that we’re already making good use of the software approach: to show how user agents got really good, so good that they make even a bad website accessible—how they automatically and correctly associate or generate alternative content; how they auto-correct colors and contrast; how they automatically associate or label form controls; how they automatically detect and translate language; how they automatically simplify copy, when requested; how they do a lot more automatically that forever, we seems to have put on developers and site owners, as if tooling, automation, machine learning could not benefit the field of accessibility and those who rely on it.

It even seems hard to show how there exists a vision for accessibility today, where everything happens automatically—automagically—, and how that vision didn’t wither with an emphasis of one approach, the one that asks many a developer to run after many a site. (Resistance to any of the automation features above may show much we lack a north star.)

It seems hard, too, to share how there’s continuous work with vendors, and work with vendors first; how mitigations are based not on “developers, do this” but “vendors, do that”; how outreach tackles accessibility problems from both sides, using both approaches, when a software solution is hard to attain; and how we as a community don’t end days bitter on Twitter, blaming x to screw up accessibility issue a, but end it content with how the Web got more accessible because everyone fought hard for tooling to get better—sometimes leading to no web developer or site owner having to do a thing.

Not one, but two approaches, to accessibility on the Web.

Kudos to everyone working on making more information accessible to more people.

Many thanks to Thomas Steiner for reviewing and sharing feedback on this post.

^* This differentiation is rare, but not new: Sébastien Aupetit and Vincent Rouillé cover it in their chapter Annotation Tool for the Smart Web Accessibility Platform for the 2014 edition of Computers Helping People With Special Needs: “[…] active accessibility mostly relies on norms and recommendations […]. Passive accessibility is achieved by a posteriori content transformations.”

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)