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

Mobile

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…

JavaScript

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.

Headings

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.