My Take on the WebAIM Survey

WebAIM’s Screen Reader User Survey #4 Results are out! Like many accessibility-minded web developers I eagerly anticipate these survey results, which have been released on a roughly annual basis since 2009. Few resources have as large an impact on the work we do as this one does.

The report includes a summary of key findings in the Conclusion, but I thought I’d take a moment to share my takeaways as well…

Free and Low-cost Screen Readers

A growing percentage of users are turning to the free and open source screen reader NVDA. When asked to identify their primary screen reader, 13.7% of respondents selected NVDA, up significantly from 2.9% in 2009 and 8.6% in 2010. JAWS continues to be the most popular screen reader, but only 49.1% of users claim it as their primary choice, down from 66.4% in 2009.

It’s also interesting that 10.4% of respondents identified Serotek System Access or System Access to Go as their primary screen reader (SA ToGo is free), jumping from only 4.7% in 2010.

Of course, with any of these results it’s impossible to know whether these trends are due to real trends in the marketplace, or simply reflect vendors’ increased efforts to “get out the vote” among their dedicated users. That said, 66.5% of respondents did express that free and low cost screen readers are a viable alternative to commercial products (up from 47.8% in 2009).


71.8% of respondents use a screen reader on a mobile device. Of those, 58.5% are using Apple iPhone, iPad, or iPod touch. This underscores the importance of testing web pages with VoiceOver on iOS. WebAIM provides some simple tips for how to do so using VoiceOver on the iPhone, iPod Touch, and iPad. I recently gave a presentation at the UW in which I demonstrated some of the things I’ve learned from my own Mobile Tests. More on those in a future blog post…


98.6% of respondents have JavaScript enabled. This has important implications for organizations with policies that require conformance to the W3C Web Content Accessibility Guidelines 1.0 (WCAG 1.0), which includes a Priority 1 requirement (checkpoint 6.3) to “Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.” This is no longer a requirement under WCAG 2.0, and in fact JavaScript is needed for many emerging accessibility solutions, such as those that use ARIA to dynamically identify the properties and state of interface elements. So—it’s time to upgrade policies from WCAG 1.0 to WCAG 2.0 to better reflect the changing technological landscape.

Older Screen Readers

82.7% of respondents updated their screen reader in the last year. That may sound like a high percentage, but it leaves a fairly large minority (17.3%) that did not upgrade. We need to keep this minority in mind as we develop products, since some users won’t have the latest assistive technologies. That’s especially important when it comes to web (including mobile) applications that require ARIA, since ARIA support among screen readers is a work in progress.


By far the most common way that users find information on a lengthy web page is to navigate through the headings (60.8%). Also, 82.1% of respondents find the heading level (“Heading 1”, “Heading 2”, etc.) to be useful. This underscores the importance of ensuring documents have a good heading structure, with headings identified in the markup. I’ll add that this is not only important in HTML, but also in other document types such as Word and PDF. Both of these document types support heading structure and other accessibility features, but the percentage of document authors who know about and use them is still quite small. We need a massive education effort (coupled with better PDF authoring tools) to change this.

ARIA Landmarks

ARIA landmarks enable developers to identify specific common regions such as the banner, navigation, main, complementary (e.g., sidebar), and contentinfo (e.g., footer) sections of a web page. In turn, screen readers provide functionality that enables users to jump directly to these sections, and in doing so typically announces the role or function of each section. These are very simple to implement (for example, just add role=”navigation” or role=”main” to existing HTML elements) and used in conjunction with headings, they can be downright revolutionary in the degree to which they improve access. Given this, I’m surprised that only 2.3% of users turn to them first when navigating a web page, and 44% of users seldom or never use them at all. Granted, ARIA landmarks are new and few pages actually use them (see my previous blog post for a few examples of pages that do). I believe this to be a case where the old Field of Dreams adage is true: If you build it, they will come. Add ARIA landmarks to your web pages, and tell users you’ve done so. Then let’s see how this finding changes in the 5th WebAIM Survey.

Skip Navigation Links

Respondents are all over the map when it comes to how often they use “skip navigation” or “skip to main content” links. The most frequent survey response was “sometimes” (28%), with only slightly fewer respondents answering with “never”, “often”, “seldom”, or “whenever they’re available”. If I was a screen reader user out of necessity, the only time I would ever use “skip” links is if a web page didn’t use ARIA landmarks or have a high-level heading marking the main content. They really aren’t necessary for screen reader users since there are better alternatives.

However, the diminishing need for skip navigation links for screen reader users must be interpreted with caution. There are other users who still benefit from these links. Users with mobility impairments who are navigating by keyboard rather than mouse still benefit – imagine having to tab through dozens or hundreds of navigation links to get to that one link you’re after at the top of the main content. It would be great if browsers would natively support jumping to headings or ARIA landmarks using keyboard, but currently Opera is the only one to do so. (In Opera the “s” and “w” keys navigate forward and back through headings. These single-key shortcuts must be enabled in Preferences > Advanced > Shortcuts in versions 9.5 and higher).

Screen magnification users also benefit from “skip” links, especially if these links are visible and positioned in the upper left corner. If users are zoomed in significantly, it can be challenging for them to find the main content and typically requires a hunt, with the user scrolling in all directions. Again, browsers (and magnification software) could provide better functionality in support of this need, using headings and ARIA landmarks as landing points. But we’re not there yet, so “skip” links still play an important role in make web pages accessible.

Flash and CAPTCHA

Flash and CAPTCHA continue to be the nemesis of screen reader users. They’re hands-down the two biggest problems identified by users in the current survey, just as they were in the 2010 survey. When faced with technologies that chronically cause problems, the solution is to either (a) fix the problem technology, or (b) stop using it.

Regarding Flash, I choose option b. At CSUN 2012 the Adobe accessibility team announced that it was discontinuing work on improving accessibility in Flash (I’m not finding a press release on that, so unfortunately you’ll just have to take my word for it. I was there!) I interpret this to mean we will never have accessible Flash on Mac or Linux, and of course Flash is inaccessible to everyone, with and without disabilities, on Apple mobile devices. So, the solution: Don’t use Flash!

Regarding CAPTCHA, I choose (again) option b. WebAIM has written an excellent article with a variety of techniques on how to attain spam-free accessible forms without CAPTCHA (see the comments for some additional tips and discussion). A web search for “accessible captcha alternatives” yields a variety of other creative solutions as well. The bottom line: There are better ways to keep robots out than requiring human users to recognize surreal distorted characters or surreal distorted sounds. Don’t use CATPCHA!

Expanding the Scope of the Survey

There are—count ’em—four links to WebAIM resources in this blog post. I can’t say enough about the contributions these folks make to web accessibility. Given this I hate to ask them to do more, but in an email to Jared I asked whether they had considered surveying other populations. For example, I’ve made some assumptions in this post about certain web features being beneficial to users with mobility impairments, but I have no data to support my opinions. What could we learn from surveying these users as well, or what about surveying users with learning and/or cognitive disabilities? I think that could yield some very important information, as we have very little objective understanding of how these users interact with the web and the types of challenges and frustrations they face.

8 replies on “My Take on the WebAIM Survey”

Thank you Terrill for this excellent analysis and for your thoughts.

To answer your question, yes, we have thought about surveying other populations with other disabilities. We’re happy to have recommendations for questions we could ask.

A survey of eye readers, those who still use their eyes but not well, would be most welcome. Subjects to explore Besides “what bugs you the most?”, are Colors, Button Design and Placement, Mouse-over use, Drop-down Menies vs Icons. and meeting the needs of those with poor contrast sensitivity, limited visual field, and cataracts. Poor acuity is not our only problem. Also ask about the availability of feedback for web pages and software. For me, Win7’s Ease of Access is inaccessible. Needs feedback. Program adiustment panels are generally not adjustable or movable.

It distesses me that there is no community of eye readers or organization to represent them. When Google presents me with an illegible button, who should I tell?

Excellent analysis, insightful, helpful and something we can build on. I have a slight disagreement, or at least would like to think a bit further about one point that you made however. That is regarding Flash support, and that Flash should simply be dropped. HTmL5 streaming of multi-media files will happen, but it has to be adopted by the standard, by the browsers and by the assistive technology, and I just can’t see that process happen in less than a couple of years at best. Flash has done wonders for multi-media experiences on the web, and there is no good solution for the present (I sure would not want to go back to streaming video files in Windows Media Player, Winamp or some other media player). I see more that the solution may lie in open source player like the Nomensa one and one from 6 degrees. I believe as long as one is able to start and stop, increase or decrease volume and move within the Flash file, that Flash player and Flash adds a lot of life, color, excitement and accessibility (in a way) to web content. YouTube is simply brilliant, and without Flash it would never have been here. I realize there may be issues for dyslexic users, users with mobility impairments etc, and I do not speak for those, but as a blind user, I believe access to Flash is relevant, urgent and imediate solutions need to be found. Just waiting till html5 comes along and solves the problem is nog good, and could leave a lot of people out of very interesting and important web content. (again, I am sorry for typos in this post, my screen reader, sarcastically, decided to shut down on me so I cannot go back and recheck). Again, would be cruious to hear you ellaborate further on this point. I know you have a lot of authority, good points and very solid coverage, so feel free to prove me wrong, if you feel I am *smiles*.

Thanks for your comment Bikkir. Regarding Flash, I don’t disagree with you about the contribution Flash has made to the evolution of the Web. I’m particularly grateful for the role Flash has played in delivery of media—I remember all too well providing video in Windows, Quicktime, and Real formats hoping to reach all users. The multi-platform, virtually ubiquitous Flash plug-in made it possible to reach most users with a single format. The trouble is—even this has not been truly a universal solution. Accessibility was only available in Windows. And even there, there’s a long history of accessibility problems. For example, it has historically been seemingly impossible for users to tab into Flash content in any browser other than IE (this is especially problematic for physically disabled non-mousers, not screen reader users). There’s an excellent explanation of this, plus solutions, on Henny Swan’s blog. Another problem is that Flash doesn’t honor users’ custom browser or OS settings, so if a user depends on large fonts and a high contrast color scheme, they’ll get that with all their HTML content, but not Flash content.

That said, 87% of the respondents to the WebAIM survey are Windows users, where accessibility has been possible for screen readers for years (that is, authors can control tab order and can add alternate text to content, and supporting screen readers can read it). However, like most other accessible design practices, authors either weren’t aware of these practices or simply chose not to follow them. I think that’s the primary reason so many survey respondents are down on Flash. If all authors took the necessary steps to ensure their Flash content was accessible, more screen reader users in Windows would be happy.

The biggest problem I see moving forward though is that the Web is evolving. If Flash is used to deliver rich, dynamic, interactive content, then it needs to expose the roles, states, and properties of user interface components so assistive technology users can interact in meaningful ways with that content. The Adobe accessibility team has worked hard over the last few years to make that happen, and to make it more than a Windows-only solution. (See this discussion on Flash and Flex Support for IAccessible2 and WAI-ARIA for background). But their announcement at CSUN seems to suggest they’re abandoning this effort before it’s complete. If that’s the case I personally respect that decision—to me it says that Flash has had its day in the limelight; now Adobe is turning its attention elsewhere and giving other technologies higher priority. I’m suggesting we developers should accept that change in direction and turn our attention elsewhere as well.

Hi Terrill, thanks for your insightful comments. I would like to suggest a middle ground between your suggestion about Flash and Birkir’s. For now, Flash continues to be the only accessible solution for streaming multimedia on a webpage, and for that, Flash can be accessibly implemented (with the right accessible player, etc). We get into trouble when we use Flash for interactivity beyond its intended purpose. Flash for streaming video is great; Flash interactivity is hard to make accessible, and displaying static text in Flash (i.e. in web-based training modules) has insurmountable difficulties. (The text can’t inherit the OS’s color contrast settings.) Static text should be displayed in HTML, interactivity should be managed with JavaScript, and multimedia should be streamed in Flash. So what to do about iOS/OSX users and populations for whom video presents an accessibility barrier? I think the solution is progressive enhancement ( provide captioned/audio-described video for those who benefit from it, detect OS with JavaScript and display HTML5 video as needed, and provide a text version of the video content for those who prefer the content that way. Sure, it’s a more complicated solution, but you end up with a better product for more users using Flash. At least until HTML5 video has better support for accessibility. Those are my thoughts! Thanks again Terrill.

Excellent article.

I do have a comment about aria landmarks however. I’m seeing lots more over-use of section and nav elements, not understanding that these produce landmarks and start/end region messages in most screen readers. Many people are now simply replacing vanilla divs with sections or navs which creates pages with many many landmarks. This completely defeats the purpose of landmarks.

Here’s a fairly good example. Note the excessive use of nav elements after the “Quick Links” heading.

Following the “Quick Links” heading there are about 8 distinct nav elements, each wrapping a heading followed by one list of nav links.
Wrap the entire block in one nav element, and name it using aria-label:

<nav aria-label=”quick Links”>
<h2>Quick Links</h2>



Comments are closed.