Not All Screen Reader Users Are Blind

The title says it all. But if you came to this page, you probably clicked because you were hoping for a little more detail than that assertion. So here is a little more detail.

The Data

In the 2015 WebAIM Screen Reader User Survey, when asked Which of the following disabilities do you have?, only 64% of respondents (1,610 people) chose blindness from a list. The list allowed respondents to select more than one disability type.

Previous versions of the survey did not ask that question.

Surveys are not studies. The data is anecdotal, but still indicates trends. When trends correspond to what professionals in an industry also see, it suggests that perhaps the trend also corresponds to the truth. This all assumes that selection bias and confirmation bias are not driving survey questions, promotion, and assessment. Also keep in mind that for this survey, respondents self identified.

Update: 10 January 2018

WebAIM released the results of its 2017 survey just before the new year, and it asked the same question of respondents. 75.8% of respondents (1,358 people) chose blindness from a list. The list allowed respondents to select more than one disability type. As you can see, while this is a larger percentage of respondents, it is also from a smaller set of respondents.

If nothing else, this tells us that one-quarter to one-third of screen-reader using respondents are not blind.

Update: 5 October 2019

In the results of the 2019 survey, 76% of respondents (930 of 1,224 total) chose blindness from a list.

Update: 30 June 2021

In the results of the 2021 survey, 79.5% of respondents (1,246 of 1,568 total) chose blindness from a list.

The Users

Many low vision users rely on screen readers to supplement what they see on the screen. Sometimes this allows them to get around poor contrast or text that is too small. Sometimes a user supplements a zooming tool with a screen reader.

Some use screen readers to help with reading comprehension, structural page navigation, or even missing focus styles. These users may have perfectly adequate vision but find the features of a screen reader valuable enough to use regularly.

And oh yeah, some screen reader users are blind.

The Risk

I spend some time at Stack Overflow answering questions about accessibility issues. It is not uncommon for people to both overestimate the need to code things for screen readers and to want to create content only for screen readers (including making separate pages).

Too often these efforts mean that what users see does not correspond to what they hear. This can be a function of oddly hidden content, terrible source order, element mis-use, poor use of tabindex, or even third-party add-ons.

Ok, let’s forget screen reader users who can see, and instead think about being a support rep for or family member of a blind screen reader user. It will be very difficult to help when you are each experiencing what are essentially different pages. You will know not to tell the user to click the green button, but what if the button text you see does not correspond to the button text the user hears?

How likely are you to pop open the browser developer tools to look for an overzealous aria-label on a <div>-as-button-via-role-sans-keyboard-handler monstrosity to explain that the button you thought said “Submit” is the one the user hears as “Activate this button to submit this form,” all thanks to a well-meaning developer who thought it was necessary?

Can you believe I typed that paragraph/sentence in one breath?

Before you start to think about screen reader detection, I can tell you that both as an industry and as users, that has been pretty soundly shot down.

Maybe Do This

I can confidently say that the best approach to making a web site accessible (to screen readers or not) is by using proper HTML. If done well, ARIA is only needed for complex controls (tabs, trees, carousels, …). Screen reader users still benefit the same way sighted users do from hidden elements, particularly visual (and in this case auditory) assaults such as mega menus.

So put away all those nifty libraries, tutorials, and ARIA snippets for a bit (not forever) and maybe spend some time working to be an HTML star first.

Update: 19 May 2020

Don’t be Facebook. This thread demonstrates how to make terrible assumptions about screen reader users (that they are all blind).

4 Comments

Reply

To complicate things, there are also people who use screen readers who have no vision impairments: They have learning disabilities. I know of several individuals with severe dyslexia who rely on screen readers to be able to navigate their computers and the web. The disconnect between what the screen reader announces and what they can see on screen will also cause quite a barrier for them.

Nicolas Steenhout; . Permalink
In response to Nicolas Steenhout. Reply

Exactly. I alluded to that when I mentioned reading comprehension above, but you offer a better, more direct case.

Reply

I have no disability and yet use screen reader. I use Pocket for iOS which can read articles to me while I’m exercising or doing chores.

Alex; . Permalink
Reply

Pocket is not a screen reader, that’s more of a sub-feature of a broader service, just like the reader mode in all major browsers that attempts to free the page from clutter and distractions for anyone. Pocket doesn’t require you to use a completely different mode of controlling the OS and the app or medium that you are working with (keyboard shortcuts), new behaviors and semantics, etc.

There are some cases where hiding content visually does actually have a reason. I am running a blog about blind-accessible gaming where there is a visual logo in the header. I inserted a visually hidden button into the footer to display the textual description of the logo, which is in this case more detailed than two or three words in an alt description of an image. In this particular image, there is no alt description at all, so that screen reader users aren’t bothered by the fact that the link to return to the home page is actually also an image.

Leave a Reply to Nicolas Steenhout Cancel response

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