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