Bruce Lawson's personal site

Developer’s guide to WebAIM screenreader survey

For the last four years, those excellent people at WebAIM have surveyed screenreader users about the kit and setup they use. For some reason, I didn’t see this when it came out in May.

Here’s a brief summary of the results to help web developers who care about accessibility (that is, professional-standard web developers). I urge you to read the full report when you have 30 minutes to spare.

I want to re-iterate my thanks to Jared Smith and the WebAIM people for collecting, collating and publishing this information.

Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)

7 Responses to “ Developer’s guide to WebAIM screenreader survey ”

Comment by David

Hi Bruce, I’ve been researching this recently and writing “click here” and “read more” links aren’t actually that bad. I spoke to a blind screenreader user last week in length about this and he says it’s absolutely not a problem as long as the links are in context.

So if the content is heading, blurb, read more, heading, blurb, read more, it’s actually absolutely fine.

I know that’s different to what we’re told and isn’t strictly best practise, but it makes logical sense to a user when read aloud.

Thanks for the article, I think more web developers need to think more about blind users.

Comment by Lewis

David, the problem with “click here” and “read more” comes up with users who step through links and therefore are not provided context. According to the survey 13% of screenreader users navigate in this way.

Comment by John Foliot

@David Be careful of the trap that many can fall into: PWD (People With Disabilities) are not a monolithic group of users who all access the web the same way, any more than all Mac Book Pro users all access the web in the same way.

While most (but again, not all) screen reader users will likely share common usage-traits (for example, the majority of screen reader users will advance the speech rate of their applications to a speed much quicker than the normal human speech rate of 120 words a minute), we cannot further presume that all screen reader users use a speech rate of 180 words a minute – it is like suggesting that all users have a monitor of at least 1240 X 768 – we simply cannot be sure.

To further add to the complexity, different combinations of gear (OS/browser/Assistive Technology) can often lead to different user experiences, and accessibility SME’s such as WebAIM, Knowbility, The Paciello Group and of course the W3C/WAI spend a lot of time researching and testing these differences to help determine the Best Practices you reference.

As someone who has spent a lot of time in the web accessibility field, I urge you to stick with the Best Practices, even when it might seem that they might be worked around or “excessive”. And should you ever wonder why one of these Best Practices are BP’s, feel free to ask any of the above mentioned groups – you will find that you will usually receive a friendly, detailed response right away.

Keep on Codin’ (accessibly)!

Comment by Prashant Ranjan Verma

Thank you for the article. I agree with the conclusions.
The web browsing pattern of screen reader users are generally similar, they like to look for headings and then links.
“Read more” and “click here” type links are a pain and image based captcha is the biggest problem.

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.