Thoughts on screen reader detection

The subject of screen reader detection has been under discussion lately. It isn’t something I’m comfortable with, so I’d like to share the reasons why.

I don’t want to share personal information with websites I visit

My disability is personal to me, and I share that information at my discretion. Proponents of screen reader detection say it would be discretionary, but that’s like choosing between plague and pestilence. Choosing between privacy and accessibility is no choice at all.

I don’t want to be relegated to a ghetto

We’ve spent years encouraging people to move away from text-only websites, and with good reason. If there is one thing that history should have taught us by now, it’s that social segregation is a bad idea.

I don’t want design decisions to be based on the wrong thing

The best screen reader detection can hope for, is to tell whether a screen reader is present or not. People use screen readers for different reasons – because they’re blind, partially sighted, Dyslexic or on the Autistic spectrum for example. Even this may be overly optimistic. Unless screen reader vendors agree to share some kind of UA string, the detection mechanism is likely to be access to the browser’s accessibility layer. In that case it may only be possible to detect an assistive technology in the most general sense, whether it be a screen reader, screen magnifier, speech recognition tool or something else entirely.

I don’t want old mistakes to be repeated

We’ve spent time turning to web standards and feature detection, instead of browser sniffing and excluding the ones we didn’t care to support (guilty as charged). Screen reader detection leaves us vulnerable to the same exclusion allover again, only this time feature detection won’t come to the rescue. The relationship between screen readers and browsers is symbiotic, and in terms of traditionally detectable features, screen readers derive most of their capability from the browser.

I don’t want things to be hard work

Most things that make a website usable with a screen reader are achieved by conforming to web standards, and the rest require relatively little modification. In these days of responsive design, including a media feature for screen readers would automatically double the work involved. You’d need to serve up a screen reader alternative for every break point version of your website.

I do want much more conversation about screen reader detection

Hence this blog post. But as the conversation continues, please bear in mind that this isn’t really about screen reader detection, or even assistive technology detection, at all. What is really being discussed is disability detection, and that is a very different thing altogether.

17 comments on “Thoughts on screen reader detection”

Skip to Post a comment
  1. Comment by PG

    How do you feel about detecting support for ARIA features? I’ve run into situations where I could make something basically work without ARIA or work well with it, but trying to support both at once created something completely unusable.

  2. Comment by lucy greco

    the most in portent thing you said is that its not hard to do access write its just following best practices. giving people an out by letting them code differently for screen readers just means they are not following best practices! just use good clean accessible code and it works. if you make things that are not accessible most people can’t use it any way.

  3. Comment by Michiel Bijl

    “Most things that make a website usable with a screen reader are achieved by conforming to web standards”

    Hear hear!

  4. Comment by Lynn Holdsworth

    As a screen reader user, I don’t want to be offered a “special “experience If a special accessible version is made to work with my screen reader, what about people using Braille displays (are these registered as screen readers on Apple devices?) Or alternative input devices? And will magnification work as expected? Blindness isn’t the only disability.

  5. Comment by Tom Widerøe

    This article takes for granted that screen reader detection is only wanted for redirecting the users to an “accessible version” of the content. In my case I want to use for web analytics. Just like I want to know how mobile users are using my site compared to users with big screens, I also want to know how it works for users with screen readers and other assistive technologies.

    I have written a blog post about it here:

    1. Comment by Léonie Watson

      Wanting to improve UX is a good thing, but it shouldn’t require the user to reveal personal information at the point of delivery. Knowing someone uses a tablet reveals nothing about them as an individual, but knowing they use a screen reader reveals that they most likely have a disability.

      Experience also suggests that people will use the information to redirect screen reader users to alternative sites. If you remember the era of text only sites, you’ll know what I mean. If you think that’s an anachronism, then consider the case of this UK supermarket that recently replaced its accessible delivery booking form with a new inaccessible one and an accessible alternative.

  6. Comment by Sina Bahram

    This is not OK. The moment you allow for web devs to detect assistive technologies, you have built the enabling substraight for facilitating systemic and automatable discrimination. With all due respect, developers can’t usually get headings right, are we expecting them to get actual moral issues, right? Other than analytics, detecting disability is not a benefit to assistive technology users. The analytics argument is built upon a false premise, IMHO, since as this post has beautifully and accurately pointed out, only the most gross of measurements will be possible anyways; therefore, no actionable analytics will come from that, nor should it. Insurance companies, product companies, law firms, and others will jump on this so fast, it’ll make our heads spin, and none of those motives are in any way beneficial to the web nor to its denizens.

    Thought experiment, are you ok with browsers disclosing that someone is gay? What about being a person of color? How about identifying as female? If not, then this should not even be remotely in the realm of conceptual consideration.

    1. Comment by Tom Widerøe

      First of all, let’s agree that identifying users with disabilities, no matter how, is only acceptable for the purposes of creating better user experiences for all. When the new regulations for GDPR takes effect from May 25th, a website will not be allowed to share information about their users without the user’s consent. Thus, if an insurance company gets hold of this information, they will be breaking the law.

      You shouldn’t just dismiss the benefits of web analytics that easily. Just as desktop users and mobile users are having different user experiences, the same may be said about users who actually can see the content and those who has to hear it through a screen reader. Why shouldn’t we know how our site works for them before we decide what to improve next?

      1. Comment by Sina Bahram

        I really want to thank you for your comment. I’ve done my best to respond to all your points, but please yell at me if I miss something.

        I feel there are four areas to your comment. I’ve broken them down in order as they appeared. My answers are separated with “Sina” heading up the block.

        You Said:
        First, let’s agree that identifying users with disabilities, no matter how, is only acceptable for the purposes of creating better user experiences for all.

        I can maybe tentatively agree that the only acceptable use case for such identification is for facilitating better experiences, but I feel there’s a lot of assumptions in your message about the ability and willingness to do good with such information. We have experienced almost three decades spanning trillions of page visits composed of billions of humans across thousands of companies, and the universal constant across these trillions of data points is that A. leaks happen (not “if”, just a matter of “when” and “how”, full stop), B. There are bad actors from world governments to folks like Facebook and Google and thousands of other entities that “will”, (not “may”), abuse this information.

        You Said:
        When the new regulations for GDPR takes effect from May 25th, a website will not be allowed to share information about their users without the user’s consent. Thus, if an insurance company gets hold of this information, they will be breaking the law.

        This in no way matches my understanding of GDPR. Do you have a citation to back up this claim? My understanding is far narrower RE scope. First, it must be an EU Citizen (there’s a majority of the planet now excluded), and secondly, they must be in the EU at the time of data collection (there’s even more of them gone as a result). Therefore, I’m strongly disagreeing with this as any measure of safety. And, not to put too fine a point on it, but can we please be pragmatic about things that are illegal VS things that happen on a daily basis? I’m hoping we can agree that given the overwhelming mountains of evidence against virtually every conceivable industry that mankind has ever created, that we don’t just think companies go around following laws, but instead perform a risk analysis of the cost of compliance against the penalty of discovery.

        You Said:
        You shouldn’t just dismiss the benefits of web analytics that easily.

        I’m taking your comments super seriously. Let’s do the same with mine. I’m not easily dismissing this. I’ve thought about this for decades at great length. If it seems like I am dismissing it easily, then I sincerely apologize without reservation.

        You Said:
        Just as desktop users and mobile users are having different user experiences, the same may be said about users who actually can see the content and those who must hear it through a screen reader. Why shouldn’t we know how our site works for them before we decide what to improve next?

        This is exactly my point. That’s where you should start. Knowing how your site works for someone is the first 5,000 or so steps before then differentiating user paths based on specific adaptations due to modality of access. So, let’s work on educating developers about screen readers, text enlargement, switch-based computing, voice input, color contrast, keyboard-only users, etc. All of that, by the way, needs to happen after we accept, and I hope we do, that developers should write compliant code (both standards compliant and guidelines compliant against WCAG 2.0, preferably level AA).

        I guarantee you that not even 5% of this potential has been realized. Not to sound glib, but it’s why half the people in this comments section get the salaries they do because most content is born inaccessible, is modified to be inaccessible, and then remains inaccessible except for obviously those fantastic developers and organizations that truly strive for best practices and that have been fortunate enough to learn about accessibility. I’m not trying to insult or in any way denigrate developers. I work with hundreds, if not thousands, of them on a yearly basis, and I know for a fact their average level of exposure to these principles is virtually nonexistent. It’s the worst of both worlds because they are told to make things accessible, and for most, it’s the first time they have so much as heard anything about it.

        Every one of us in the accessibility space has a ton of stories of when developers try to do something for the best with wonderful intentions and instead destroy the user experience due to the lack of understanding I stated above. Please believe me when I say that them knowing whether I am a screen reader user or not would not have made a single one of the 100 examples that immediately come into my mind one tiniest bit better. In fact, I can’t even think of a single example of the tens of thousands I’ve experienced in my life in which the developer knowing I was a screen reader user, or not knowing, was the cause of the problem. Instead the causes are lack of compliant code, lack of knowledge of basic HTML and JavaScript, lack of understanding of how the DOM works in relation to assistive technologies, lack of awareness around the effects of various third-party technologies (think video/audio players, image sliders, etc.), and so forth.
        I hope this helps clarify my position.

        1. Comment by Tom Widerøe

          Thank you for taking your time to explain your views so thoroughly. I think I can agree with 90% of your views, but I see some things from a different angle, and sometimes we may relate to different cultures (or maybe I’m just naive). Instead of quoting all your arguments, I will simply refer to them by number. This reply will be long enough as it is.

          I admit that my view depends on trust and moral among those who collect such data, but both technically and conceptually there is a clear difference in collecting data for web analytics and other purposes. These data should always stay anonymous, and for web analytics, each user’s identity is not relevant anyway.

          That said, detecting assistive technologies is not necessarily the best solution either. I have done some experiments based on user patterns, and found some interesting differences between the user groups on some features where we discovered we had an accessibility bug. Perhaps less than 50% of the users I isolated actually had a disability, but for web analytics, that’s good enough to spot potential accessibility bugs. But for commercial purposes, I doubt that will be accurate enough to make it worth the effort.

          A third, and possibly more honest approach, is to simply to ask the users if they have any disability that makes using the web difficult, and if it’s okay to use their traffic data to make them better services. Of course with a legally binding commitment not to misuse those data.

          It’s true that GDPR only applies to EU citizens, but when you first have to relate to that group, why take the extra cost for making a difference? At least the company I work for, which is one of the most visited websites in Norway, doesn’t think that’s worth it. As you might know, Norway is not a part of the EU, but even if our site is in Norwegian language only, we have to relate to the small fraction of EU citizens who use our site. It would also make poor publicity if we treated foreign users better than our own citizens.

          You have convinced me that you don’t take easily. 😉

          Web analytics is our most important tool to know how our site works for our users, but if we can only see how it works for the majority, we can only use it to improve UX for the majority. If we can see how it works for smaller groups, we can also use it to make better UX for minorities.

          I agree that developers should be trained better in using assistive technologies, and I spend a lot of time on running accessibility workshops for my colleagues (more than I spend on web analytics). I also emphasize that valid HTML is best plug-in for accessibility. But sadly, developers are pushed by expectations from the market and the users who are way ahead of the standards provided by W3C. It’s still possible to make such features accessible, but not always by the help of basic HTML. Even when accessibility awareness is high, bugs are easily introduced in minor fixes when you think nothing can go wrong. Web analytics can help you reveal such bugs.

          And to clarify any possible misunderstanding: I do not want to provide a separate set of features for users of assistive technologies. Everybody loses on that. We get twice as much code to maintain, development of features for the “majority” will slow down, and the “accessible” version for the minority will sooner or later fall behind when new features are added. I belive in universal design, with one solution that works for everyone.

          1. Comment by Isabel Holdsworth

            Tom, it’s very encouraging that you’re willing to go to such lengths to offer a more accessible experience for people using assistive tech, and that you see the value in asking us directly what we need rather than just guessing as so many organisations do.
            However, as a tech-savvy screenreader user, if sniffing out the fact that I use assistive tech became possible, I would jump through every hoop known to man to ensure that digital content owners couldn’t get that information from my web-enabled devices. Here’s just one example of why:
            I recently applied for a job online through a recruitment agency, and the company that interviewed me fed back to them that I am blind. A very angry agency rep contacted me saying that if he’d known I was blind he wouldn’t have put me forward for the job. If unscrupulous organisations like this one had the power to exclude people with disabilities based on an assistive tech sniffer, would they use it? I really don’t want that to be a possibility.
            Keep doing what you’re doing 🙂

            1. Comment by Tom Widerøe

              Isabel, it makes me really sad to read your story. If such a story came out around here, it would be devastating publicity for that agency, but some people obviously get away with it.

              As mentioned, «sniffing» might not be the best metod, but rather voluntary giving traffic data comitted to site improvement only. My goal is after all to see how a site works for large numbers of users with disabilities, and the most obvious way to do that is blocked. I don’t expect that change anymore.

  7. Comment by Ian Hamilton

    Real world example from another industry and on a slightly different angle, but I think worth mentioning anyway.

    The developers of Uncharted 4 on the PlayStation 4 implemented options to turn on automated camera movement and assisted aiming, with the goal of enabling one handed play. With both of those assists enabled you no longer need to use both joysticks, you can play one handed.

    They tracked usage data of how many people played with those options turned on, which came out as 1/3 of their players – obviously many many times more than the number of players
    who have one hand, crushing the possibility of the usual “accessibility is too niche” arguments.

    They were able to prove that what they had implemented had made the game a better experience for millions of customers, customers who had paid £60 each for the product.

    That data got the attention of C-level people at the company, which in turn opened doors not only for approval to work on more accessibility features in future, but for cultural change across the company.

  8. Comment by Ian Hamilton

    Also might be worth expanding the discussion from web to also iOS apps, where it has already been possible for a long time to detect screenreader usage through a single line of code.

    1. Comment by Tom Widerøe

      As I spend most of my work on the web, I haven’t been able to study app users, but it would definitively been interesting. Interesting story from PlayStation btw.

      1. Comment by Ian Hamilton

        Yep it’s really trivial, just a single line of code and it returns whether voiceover is currently turned on. Just as trivial to detect it being turned off/on too.

        “There are two ways to determine or be informed of the status of VoiceOver. The first way is to call the UIKit function UIAccessibilityIsVoiceOverRunning(). This returns a BOOL indicating if VoiceOver is active. The second way is to register for the UIAccessibilityVoiceOverStatusChanged notification.”

        It is intended to be used for serving up modified content, but obviously can be and is used for tracking too.

Comment on this post

Will not be published

This site uses Akismet to reduce spam. Learn how your comment data is processed.