Detecting Screen Readers – No

There has been much discussion about the idea of detecting a screen reader from a website and optimizing the code. In the W3C editor’s draft IndieUI 1.0: User Context, screen reader detection is proposed. This scares me and many others in the web accessibility community.

In the recent publishing of the WebAIM screen reader survey, one of the questions is “How comfortable would you be with allowing web sites to detect whether you are using a screen reader?”. Surprisingly 54% of respondents replied “Very comfortable”. This sure sparked some discussion on Twitter and on blogs.

For the most part, detecting a screen reader has been ill-received from the accessibility community. I am also strongly opposed to this idea.

The reasoning boils down to two issues: development and privacy. And it’s bad for both. Here are some reasons why it’d be bad for development:

  • Text-only websites didn’t work before and you know devs will do this if a mechanism is provided.
  • Screen reader detection is eerily similar to the browser-sniffing technique which has proven to be a poor practice.
  • Maintaining separate channels of code is a nightmare; developers overloaded already with supporting multiple browsers, devices, etc (via RWD). And if done, it will many times become outdated if not entirely forgotten about.
  • Why screen reader detection? If you follow that logic, then detection should be provided for screen magnifiers, braille output devices, onscreen keyboards, voice-recognition, etc. That’s just crazy.

Let’s hope screen reader detection is removed from the W3C draft of IndieUI 1.0: User Context.

PS: Interestingly, @LFLegal recently announced that Safeway is (finally) removing a text-only version of its website in the blog Separate is Not Equal: Good News for Grocery Delivery.

Further reading:


  1. Pingback: On Detecting Assistive Technology - Joe Dolson Accessible Web Design
  2. Pingback: On Screen Reader Detection | Adrian Roselli
  3. Jason

    I can think of one reason: HTML payload. Right now the consensus on what to send to the client to handle accessibility is something along the lines of

    div – class=”visually-hidden” -> Title of thing
    div -> actual content

    This is good for accessibility but bad for site speed if enough of these are in the payload. If I’m able to detect whether or not the user is using browsing with a site reader, I can conditionally include or exclude all these divs that a non-screen-reader-user would never see. While the savings wouldn’t be huge, every little bit helps, especially if you’re on a mobile device with a slow connection.

    Another reason I can think of would be the inclusion or exclusion of the CSS file. Correct me if I’m wrong, but a user using a screen reading device has no need for CSS, meaning that a *lot* of transfer can be saved for those users, as CSS files are generally pretty large.

    Sure, this opens up the possibility of abuse, but so does allowing javascript to be run, and 99% of sites have JS on them and all browsers have it enabled by default. Maintaining two separate codebases? Hardly. Just have conditionals wherever there may be something you might/might not need to include. You may even be able to write a helper of sorts in some client side frameworks. If you’re building your site correctly, you shouldn’t have to rearrange anything due to the presence of a screen reader or lack thereof.

    I think this would be a powerful feature that gives developers the opportunity to optimize the site for the user in terms of both content and site speed.

    Disclaimer: Jennison is a coworker of mine :)

    • Dennis

      In this regard, creating conditionals is not much different than a separate code base; still adds code complexity and creates a second /separate experience. It’s ideal to have the same experience for all users (well, as much as possible).

      And again, there are also privacy issues with detecting a screen reader user.

      About the point about CSS, all users including screen reader users do have a need for CSS. For example, in today’s web dev, often times content is hidden with CSS (usually display:none) which needs to be hidden for all users, otherwise it makes no sense and is unusable.

      I recommend that sticking with best practices for front-end development (especially light, semantic markup) should be the priority for website content and speed.

  4. Pingback: Toolness » Blog Archive » Discovering Accessibility

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>