Why screen reader detection on the web is a bad thing

On February 26, 2014, the webAIM project published the results of their 5th screen reader user survey. Two questions were new in this survey that pertain to a recently growing desire of some web developers to know whether they’re dealing with assistive technologies on the other end or not. The results were rather shocking to me as a representative of a browser vendor and experienced assistive technology user:

78.4% of respondents were very comfortable or somewhat comfortable with letting a web site know they are using a screen reader. And even 86.5% were very or somewhat comfortable if doing so resulted in better accessibility of the website. For each question, only roughly 2% of respondents answered “I don’t know” to that question.

In my opinion, it should have been the other way around. I took the questionaire myself back in January, and because I am involved in making a web browser and knowing about the various desires by web developers and some standards people, I knew what was meant here, and also knew the implications. I submit, carefully, and without wanting to diminish anyone’s maturity in this matter, that most of those who responded didn’t actually know what the screen reader detection actually means. There was just too little context given, and information on this subject is also not so easy to find on the web.

For one, letting a website know you’re using a screen reader means running around the web waving a red flag that shouts “here, I’m visually impaired or blind!” at anyone who is willing to look. It would take away the one place where we as blind people can be relatively undetected without our white cane or guide dog screaming at everybody around us that we’re blind or visually impaired, and therefore giving others a chance to treat us like true equals. Because let’s face it, the vast majority of non-disabled people are apprehensive in one way or another when encountering a person with a disability.

Second, this is just a modern form of the text-only alternative web sites of the 1990s when screen readers were still learning to stumble around graphical user interfaces, let alone the web, and those text-only alternatives were a necessary evil to get anything done in most cases. In the early 2000s, as screen readers became better and browsers more modern, those faded away. And only in recent years has the trend sort of reverted, primarily because people just don’t know, or don’t care, to make their new shiny dynamic web sites and widgets properly accessible, even though the techniques exist to do just that. The current worst of the bad examples is the “accessible alternative” of the Audible.com web site. For one, its feature set is limited, and second, it constantly throws you back to the standard web presence, when doing searches, for example, and other totally screwed user experience snafoos. Or is there anyone out there who is actually wanting to tell me they enjoy this and find it even remotely useful? And to add insult to injury, the stuff that is currently a bit tricky on the standard web site can easily be fixed by some WAI-ARIA markup and some consistent keyboard navigation JavaScript.

And the old arguments still apply: Alternative versions of web sites tend to get out of date, no longer being maintained, and creating and maintaining them is more expensive than properly applying markup and learning the web accessibility skill properly once.

Third, there are security implications. Ever since I started working for Mozilla in 2007, there have been repetitive inquiries about exposing whether a screen reader is running with the browser, and if so, also granting access to the accessibility APIs to content JavaScript to manipulate what screen readers read to the user. Either of these would give web sites knowledge or exposure of operating system bits that, in every other case, would be considered unacceptable. You wouldn’t want to give web site JavaScript access to your file system, which type of keyboard you’re using, what brand your processor is, or if your machine still has a floppy drive or not, would you? Accessibility APIs hook into all kinds of channels to expose all the needed information to assistive technologies. Granting a web site access to these APIs would open a level of access to a computer that is just unacceptable, and unnecessary, for a web site to have.

Some might argue that apps on mobile devices have access to that information, even through defined APIs, and the same is true on desktops. Yes, but the entry for an app is much higher. There is usually an installation process, and apps have by definition access to more information. They aren’t as casually visited as a web site is. Even on Firefox OS, there is a 3 level app privilege model, even though Firefox OS is built of web technologies, and not all of these levels will have access to the information whether the screen reader is running or not.

Aural style sheets never gained acceptance because the expected gain was just not there, and the desire to have equal access to the same content as everybody else was much stronger. More recent requests all are just the same thing in different disguise.

WebAIM should either have given more context to this question, especially since it was not a topic even most advanced screen reader users would be familiar with, or they should have asked a third question highlighting the privacy/security context. Funny enough, the question about plain text alternatives was answered with “seldom or never” by almost 30% of respondents, so the desire to use such sites in general is much lower than the two screen reader detection questions might suggest. So I again submit that only the lack of proper context made so many people answer those questions differently than the one about plain text alternatives.

It is my sincere hope that the work currently done by the IndieUI group at the W3C will provide enough incentive for web authors not to abuse the querying mechanisms described, and that this will only be used by very well-informed sites where the developers provide actual value. The privacy examples in that document look at least promising. Let’s hope it all holds up until this becomes a standard one day. I, for one, will strongly discourage web developers who ask me from using this unless I am personally convinced they know what they’re doing. And yes, like with Location sharing, I will personally be very restrictive about allowing sites access to that particular information if I’m asked.

Show Comments