On Detecting Assistive Technology

It’s what everybody’s talking about, so why not chime in?

And spawned by the results from WebAIM’s 5th Screen Reader User Survey.

First off: the original question was whether screen reader detection should be allowed, and not about detecting all assistive technology – and there’s a good reason for that. The relationship between screen readers and browsers is much closer than, say, the relationship between an adaptive keyboard and a browser.

The screen reader has a highly dynamic interaction with the browser; the adaptive keyboard is fundamentally identical to any other keyboard in how it acts as an input device. (Different in how it interacts with the user, but essentially the same when interacting with the computer.)

Breaking down the Question

Looking at this question with screen readers in mind, it breaks down into two questions:

  1. What are the advantages to detecting screen readers?
  2. What are the disadvantages to detecting screen readers?


Obviously there’s the potential to provide a better experience to users with screen readers because you know they’re there. And there’s the ability to gather statistics on screen reader usage in a way we’ve never been able to before.


The risk that screen reader users will just get shrugged off into a simpler, poorly-updated version of the site because nobody can be bothered to create and maintain an equal experience. And there’s the ability to gather statistics on screen reader usage in a way we’ve never been able to before.

Funny how the second sentence is the same in both cases…

What you can do when you detect a screen reader

Has there ever been a time when separate but equal was a legitimate treatment? As much as it could hypothetically be an advantage to know that you’re dealing with a screen reader, in practice it really shouldn’t make much of a difference. Screen readers are damned sophisticated pieces of software: if you’ve built your site right, they’re fully capable of allowing somebody to use it.

What would you do? Only push aria attributes into the HTML when a screen reader is detected? Isn’t that just more work for a developer? Is there ever an environment where maintaining two interfaces for a site is actually an advantage?

As much as I can imagine some edge cases where detecting a screen reader could lead to better accessibility, I can also easily think of better solutions for those same cases — so it hardly seems like this is any kind of benefit.

So many accessibility failures amount to ignorance and laziness, rather than failures of technology, that I can’t see this as solving the root problem: developers.

What about those statistics?

Wouldn’t it be great to have solid, evidential statistics about screen reader use? Sure. But at what cost? The sacrifice of privacy? The exposure on the web that your visitor, during a support chat, has a disability, causing that support person to treat you differently than they would otherwise?

Statistics aren’t the argument for web accessibility: as much as it’s important to be aware how many people may be using assistive technology on the web, if that was the only argument that mattered we’d have already lost the battle. We build accessible web sites because it’s the right thing to do: it gives everybody a fair chance to use your site, rather than privileging the majority.

I can see far more harm coming from the ability to detect assistive technology than good. The potential for good is there, absolutely: but only by stifling the development of interfaces that provide equal access for all and relegating people with disabilities to an experience determined by their assistive technology.

What about detecting all assistive technology?

Oh. And that question about detecting all assistive technology? You’ve got to be kidding. If you think it’s practical to detect all assistive technology from the browser, then you have no concept of what assistive technology really is.

Have something to contribute?

« Read my Comment Policy

Start the conversation!