How do actual users of screen readers behave and what do they want? The WebAIM organization has been conducting surveys in the past few months, and they recently released results from the second screen reader survey of 655 users. Some things I thought were worthy of noting:
Windows, JAWS & IE Still Rule
There wasn’t an explicit question about Mac vs. PC, but when the top responses for screen readers (JAWS, 66.4% and Window Eyes, 10.4%) and browser (IE 6/7/8, 70.9%) are all Windows-only…you don’t really need to. It’s ironic that Internet Explorer is the most preferred browser, since it is known for its non-standard quirks and thus a major headache for Web developers. Nevertheless, it is still the standard for the screen reader community.
One visually-impaired user even considered a recommendation to use Firefox an accessibility barrier. If you need to learn a new interface by speech only, you could see that a switch to a new application is not necessarily a trivial matter.
Some Flexibility
On the other hand, there are some bright spots for the Web developers. One is that 8.9% of users use Apple’s VoiceOver as their primary screen reader and 14.6% of users report commonly using VoiceOver. Apple appears to be a viable system for some users. Users are also willing to user Firefox and Safari. About 18.8% use Firefox as the primary browser and 39% report using it at least some of the time.
Other important metrics include how often the screen reader is updated and proficiency. Most users (83.6 %) have upgraded their browsers in the past year; this is important for Web developers since many accessibility code recommendations typically work only for newer screen readers. The more recent the technology/recommendation, the newer the screen reader has to be.
Proficiency is another metric, since many accommodations may require that users know to switch into different modes. For instance, JAWS contains table mode and forms mode where the special tags actually do their magic. If users don’t know these modes, then a page would be considered “inaccessible” even with the technology properly implemented. Fortunately….only 4.7% of the users surveyed considered themselves beginner in screen reader usage and over half (52.6%) considered themselves expert.
On the other hand, it’s not clear if the respondents are true representatives of the population. This was an opt-in online survey, so the population could be skewed towards more advanced users who are aware of the WebAIM organization or online accessibility resources. For instance, this audience is also 50% on mobile devices, which indicates a certain level of affluence and technological sophistication.
Social Media
Social media tools (Facebook, Blogs, YouTube, Twitter, etc) did fairly well. For most of the tools, over 50% of the users rated them as “somewhat accessible” or better. The two lowest scoring tools were LinkedIn (only 38.5% considered it “somewhat accessible” or better) and Facebook (58.7% consider it “somewhat accessible” or better). Compare this with Twitter which is rated 91% (with 61.9% of users rating it as “very accessible”).
There are still concerns, especially if the tool is relying on Flash, but developers of social media are getting the job done, whether it be through standards compliance or through accessibility testing.
Problematic Issues
Technologies identified as being problematic included Captcha and Flash. Although Flash can be made accessible, the perception is that it probably isn’t (62.2% agreed that Flash content was somewhat or very unlikely to be inaccessible). If nothing else, Adobe has a PR problem with the screen reader community (and probably a PR problem with the Web developer community as well).
Another interesting problem reported is “ambiguous link text” – that is a link whose destination is unclear out of context. The classic example are multiple “Click here” links. In principle, this is easy to solve, but lack of awareness means it’s extremely prevelant…especially in a lot of content management systems which program canned link text statements. A good example of what to do can be found in Movable Type (i.e. Blogs at Penn State platform). The output generally includes distinct links including the blog title (which doubles as the permalink), tags and categories.
The last set of major problems included:
- Improper or missing image ALT Tags – A file name (e.g. Photo1356) is not a good ALT tag, but that’s only option in tools like Flickr.
- Complex forms – Web forms (including login screens) can still be a major barrier unless they are properly structured.
- Unxpected screen changes – Web 2.0 tools need to announce when content changes. This can be implemented via ARIA (and Javascript) or some other technology.
- Poor Keyboard accessibility – I suspect this is going to be a bigger problem for Penn State as veterans enroll in college. Many may be having various hand mobility issues depending on their injuries.
Javascript Enabled…Sort Of
One preference Web developers will like is that only 50% now disable Javascript. Javascript can be accessible…so long as it is properly coded. On the other hand, there are still a lot of people disabling it, so you may want to use non-Javascript options for simple interactivity (e.g. non-Javascript date stamps, CSS rollovers vs Javascript rollovers).
Another good piece of news is that Skip Link technology has minimal impact. It should still be included, especially to skip the main navigational link block, but doesn’t need to be implemented everywhere.
Use H tag Headers
An accessibility recommendation the community stresses is to break up content into headers (e.g. H1,H2….). In fact the survey indicates that most users (50.8%) prefer to scan though headers if the page content is long. That is, it seems like users still want a sense of overall information architecture. And don’t forget the benefits of descriptive headers for your Google search ranking!
Images….Again
In terms of images, users definitely want ALT tags, even for decorative images (77.3%). So if your page has a cute cartoon lion, go ahead and describe him in the ALT tag.
A preference that may cause more of a headache are preferences for complex images (e.g. a bar graph or map). Web developers may be using the LONGDESC attribute or D link to send users to a different page, but most users (55%) actually want the description on the same page. But here, there is divergence – of the 55% mentioned, about half want the description right after the image (no link) and the other half want the description, but as an optional link. The remaining 45% either want want the link on a separate page (19.8%) or in the ALT text (19.8 %).
WebAIM says there is no clear consensus, but I do see a general preference for staying on the same page for the image description (either text or ALT tag) and not linking out (sort of like how visual users don’t want to click a link to open an image in a pop-up window).
What you can do may depend on context. There are times when it makes sense to have a visible description for everyone, and others when you need to split the description for visually impaired users as a separate entity. The long ALT tag would be an ideal situation here, but JAWS may still have a 155 character limit (grrr). So….if you do have to go to a separate page for the image description, make sure you can link users back to the main text
A Positive Note
Any user of a screen reader can tell about the many problems encountered in everyday browsing, but the plurality (46.3%) feel the Web is becoming more accessible. It’s slow progress, but at least it’s progress.