brhfl.com

The delusion of accessibility checkers

There is a delusion that I deal with, professionally, day in and day out. That nearly any piece of authoring software, be it Microsoft Word or Adobe Acrobat, has some inbuilt mechanism for assessing the accessibility of a document. Before I get into the details, let me just come out and say that if you are not already an accessibility professional, these tools cannot help you. I understand the motivation, but in my experience, these things do more harm than good. They allow unversed consumers to gain a false sense of understanding about the output of their product. That sounds incredibly condescending, but that’s honestly how it should work when you’re talking about fields that require extensive training.

The ultimate problem is that accessibility comes down to human decision. Accessible tech is, thus far, ‘dumb’ — it almost exclusively responds to cues embedded by a human. Some day, I believe that AI will be good enough to largely make the decisions that currently necessitate a human. But we aren’t there yet. A good analogy, but one that only gets through to a select group, is that of a compiler throwing warnings and errors. I can’t just type make me a roguelike but where all you do is find cute clothes in treasure chests into gcc and get my game to come out — the computer is not that smart. I could program dresscrawler myself, and attempt to compile it. gcc might throw errors — these are just things that make it incapable of compiling. gcc might throw warnings — these are just things that it thinks could be problematic, or are outside of accepted style. gcc can’t stop me from making dresscrawler a game where the player can spawn inside an inescapable room with no exits. gcc can’t guarantee I even remembered to code dresses into dresscrawler. gcc can’t even ensure that I didn’t create some kind of stack overflow that would cause a fatal exception when I place my jeggings of holding inside my purse of holding.

Perhaps a faultier, but more lay explanation would be that of purchasing a meal. If I go to a local restaurant, and I order a veggie burger, and it’s awful… I don’t actually know why. I might have a vague idea, that it’s too sweet, say. But why? Did they add too much beet? Did they sweeten it to make up for something else? With what? Sugar? Glucose syrup? Some bizarre synthetic? I don’t have all the information; I cannot make accurate conclusions. All I can make are vague suggestions, and this is how accessibility checkers (and compilers) work.

If I knew how to make the perfect veggie burger, I’d just do it myself. If the computer was smart enough, it would program dresscrawler for me (and, oh, how I wish it would). And if the computer was smart enough, none of what I do for a living would even exist! This is a human job because, for the time being at least, it requires human decision-making based on human experience. I am very engaged with the accessibility community, the disabled community, as far as current best practices. But these are still judgment calls. Some things are explicitly laid out — WCAG 2.0 put forward mathematically acceptable contrast levels, for example. But a lot of accessibility work still boils down to human decision-making, based on ‘how would I want to experience this, if I was experiencing it differently?’

Universal digital accessibility is incredibly difficult to do right1. But it’s so detached from the reality of most abled people, that they trust relatively naïve algorithms will absolve them. I’ve tried to get customers to use JAWS or NVDA just to experience the misery of a poorly-structured document, and… they often don’t even last long enough to care. I honestly wish vendors would stop bundling these half-baked accessibility checkers into their authoring software. Come see me once your approach involves neural networks.


  1. I’m always willing to help queer creators make their content accessible pro bono. Just FYI. ↩︎