Accessibility: November 2009 Archives

Color Blindness and Warnings: Think Red/Blue, Not Red/Green

| | Comments (0)

Probably the best way to create a color blindness issue on a Web is to use Red/Green color coding. Even the latest WebAim Screen reader survey uses red and green pie charts. The good news is that the WebAim pie chart sections are labeled, but they still come out as a giant mustard brown pie in the Photoshop CS4 Color Blindness filter proofing tools.

One way use the color coding, but enhance usability for color blindness users is to bump your greens towards a blue. Blue is a good color because it typically appears blue to users with different types of red/green color blindness (the most common type of color deficiencies). So instead of a pie chart with lots of yellow slices, the color deficient users would see blue and yellow - which maintains a hue distinction.

You can see a demo below.

2 pie charts, left with red area for Bad and green for Good and right with red for bad and blue for good
Red-green vs red-blue pie chart.

Same charts in color deficient view. Left is yellow fore bad and brown for good, left is yellow for bad and blue for good
Same chart in protonopia color blindness filter view.

The first image shows two pie charts in which red is "Bad" and "Good" is green in the first version and a bluish cyan in the second. The next shows the charts in one of the Photoshop Color Deficient Proofing views. The red/green original becomes mustard yellow and brown while the red/cyan version has both blue and brown. Neither matches my original artistic vision, but at least the one where blue is maintained shows more of a difference.

WebAIM Screen Reader User Survey 2

| | Comments (0)

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 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 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!


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.