Categories
screenreader

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 a bad idea.

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:

Updated August 2023

17 replies on “Detecting Screen Readers – No”

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 🙂

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.

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.

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

By detecting screen readers, websites can remove the outline of buttons for everyone except people who use screenreaders. They can also use less bandwidth by hiding decorative images and using a single pixel image for important images.

Yes please. Detect screen readers! Agancies delivers web applications and sites with poor support and sloppy code with display: none. The clients do not pay the costs to make “smarter” solutions. However, a simple detection mecansim for example to ignore css values like display none or jQuery slideUp() is BETTER than no attention to screen readers at all.

And the privacy talk – come on, this is internet. “I dont want the code to know Im on a cellphone” – is the same thing.

Another use for detecting screen readers – tab stops.

We display read-only text with other information on a form – e.g. an age calculated from the birthdate you enter or fields loaded from the database and just displayed for reference. The only way to get a screen reader to read this information while in forms mode is to put a tab stop on the field. This makes no sense when you can see the information.

I want to detect a screen reader so I can display the information using an field rather than a or .

Its great that this guy has an opinion, but when the rubber meets the road, you do what you are told or asked to do by those above you. You can opine about why you should or shouldn’t do things one way or another all day long, but when your boss says hey give me XYZ, you give XYZ or you better have your resume up to date. Believe me, I have fought the good fight and just like the song, I fought the law and the law one, I wasn’t on the winning end of that conversation. At the end of the day, detecting browsers, plugins and just about anything else is easily doable and companies do it all the time. So, enjoy the opinions but practice your code.

It’s 2019 and this is now a joke. Screen readers like NVDA take over basic keypress events like the up/down/left/right arrow keys. Take a slider control. Focus goes to it, and you hit the right arrow key to scroll right. With NVDA active, the left/right arrow keys read out the element character by character. Without NVDA, keypress listeners are in place to handle it.

Screen readers should attach at least a classname or other attribute to the tag to let all the dynamic content through JS know that they should “use alt-left to move left” while all modern browsers without NVDA active use alt-left for the back button.

I don’t care about server request headers and adjusting content based on that, I’m worried about front-facing applications that are trying to make keyboard navigation easier only to have it stupidly difficult while a screen reader is active.

Leave a Reply

Your email address will not be published. Required fields are marked *