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.
- The vast majority of screenreader users are on Windows (87%). The runners up are Mac (8.5%) and iOS (3.4%).
- The free, open-source screenreader NVDA “saw continued increase in usage, up to 13.7% from 2.9% in 2009 and 8.6% in 2010 (a nearly 500% increase in just 2.5 years)”. You can use NVDA to test your sites and maybe send them a donation; it literally is two blind guys in Australia who maintain it.
- The vast majority of respondents (83%) updated their primary screen reader within the previous year. Users of free screenreaders were unsurprisingly more likely to upgrade than paid screenreader users.
- Mobile screen reader usage increased 600% in just over 3 years (only 12% reported using a mobile screen reader in January 2009). 58% were on iOS devices, 20% on Nokia, 7.9% on Android.
- 98.6% of users had JavaScript enabled.
- Internet Explorer accounts for 67.5% of the browser share among respondents – IE8 was 34%, IE9+ was 29.5%. Firefox was the runner-up at 20%. “No-one uses IE” is the same as saying “We don’t care about disabled customers”.
- ARIA landmarks (banner, contentinfo, main, navigation etc) were used “whenever they are present” by 24.6%, “often” by 15.8%, “never” by 15.6%. This is one reason for my changing my mind to support a proposed <main> element in HTML5.
- 60.8% said navigating through page headings was their primary method find information on a lengthy web page. Heading structures are therefore very important. See this blind developer’s short video Importance of HTML Headings for Accessibility for more.
- The most problematic areas for screenreader users (most frustrating first) are:
- The presence of inaccessible Flash content
- CAPTCHA – images presenting text used to verify that you are a human user
- Ambiguous links. Lose those “read more” and “click here” links, people! This isn’t a new revelation!
- Images with missing or improper descriptions (alt text)
- Screens or parts of screens that change unexpectedly. (Perhaps judicious use of ARIA Live Regions could alleviate this?)
I want to re-iterate my thanks to Jared Smith and the WebAIM people for collecting, collating and publishing this information.
7 Responses to “ Developer’s guide to WebAIM screenreader survey ”
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.
Ah yes you’re right. I must have asked a screenreader user who doesn’t use this method!
@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)!
Thanks John!
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.
[...] Highlights from the WebAIM screen reader survey. Thanks for the CliffsNotes, Bruce! [...]
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.