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:

7 comments

  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
  5. Orv

    For what it’s worth, the reason I was searching for “detecting screen readers” and hit this article is I’m finding screen readers are frequently very broken, and the changes I’d have to make to site design to work around that brokenness would make the site a lot worse for sighted viewers. It’s much like the old situation with IE, where browser sniffing was the only way to make a site that would work cross-browser.

    For example, I’m working on a chat client. aria-live works, sort of, except that if more than one line of output arrives at once, the reader only reads one of them. I could put in a delay to allow each line to be read before the next one is displayed, but that would make the site much less responsive for sighted users. I’m not really sure how to deal with this sort of thing without knowing if a screen reader is present.

  6. Mike Nelson

    I’m developing an app Speaking Email which lets people listen to their email and can swipe between messages. A number of blind users have expressed interest in using this app but because the screen reader takes over swipe gestures we therefore need to add more buttons. We also need to remove the intro slider at the start which is non-accessible and adds no value to blind users. Why shouldn’t we have control of the user experience via code? Makes no sense.


    Mike Nelson
    Listen to your email with
    Speaking Email

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>