WebAIM Blog

The results from WebAIM’s most recent survey are now available at http://webaim.org/projects/screenreadersurvey2/. Thank you to those who participated. We had 665 responses to the survey. The data collected is informative, useful, and will help direct development of accessible content for screen reader users.

Be sure to check out the results of our previous survey as well.

While the full details are available, here are a few findings we found interesting, surprising, or relevant:

• JAWS continues to be the most popular screen reader (75%). Window Eyes use remains at 24%. However, NVDA (26%), System Access (23%), and VoiceOver (15%) all saw tremendous increases in usage in the 10 months since our previous survey.
• 83.6% of respondents updated their primary screen reader within the last year.
• 50% of respondents (53% of respondents with disabilities) use a screen reader on a mobile device.
• 75% of respondents do not have javascript disabled in their primary web browser.
• 42% of respondents did not know that ARIA landmark functionality even exists.
• CAPTCHA, Flash, ambiguous links, poor/missing alternative text, complex forms, and poor keyboard accessibility are cited as the most problematic items on the web
• YouTube (51.3%) and blogs (47.7%) are the most commonly used social media tools, with LinkedIn (13.4%) and MySpace (9.0%) rarely used.
• The majority of respondents found blogs, Facebook, Twitter, MySpace, and YouTube to be accessible and most reported LinkedIn as being inaccessible.
• 62.6% say it is somewhat unlikely or very unlikely for Flash content to be accessible to them.
• Headings are the primary mechanism (50.8% of respondents) for finding information within a page.

Please take some time to review the survey results. We will be posting observations and details from the survey’s open ended questions in the near future. If you have questions, want us to analyze a particular piece of data, or have recommendations for a future survey, please contact us or leave a comment below.

Totally inaccessible.

That’s the most accurate way that Google Wave (not to be confused with the original WAVE) accessibility can be summarized. It must be disclaimed that this is a very early preview release of Google Wave, and functionality and accessibility will certainly be improved along the way. Still, it is rather disheartening to see no attention paid to accessibility. For example:

• Alternative text is not provided for any images.
• Background images are used to convey content.
• Roles, states, and other accessibility properties are not defined.
• There is no document or heading structure or semantics. None! Not even a list!
• Form elements do not have labels or titles.
• Keyboard focus indication is hidden, making keyboard navigation nearly impossible.
• Most interactive elements are not in the tab order or do not respond to keyboard activation.
• Keyboard focus is often trapped, requiring the page or browser to be closed to resume keyboard navigation.
• The application becomes unusable and unreadable when text size is increased only slightly.

… and I think you get the general idea. One positive point – the welcome and introductory videos are captioned.

Possibilities

Despite it’s rudimentary nature, e-mail continues to pose a relatively significant accessibility issue to users with disabilities. This is primarily due to its dual-threaded nature – meaning that messages can have replies, but the content of replies often takes an entirely different form. The response text of a particular e-mail might be top-posted, bottom-posted, or intermingled throughout the original message. This complexity is compounded by the fact that participants can join or leave the e-mail discussion at any point.

Google Wave does a wonderful job of addressing these issues by presenting the conversation in a way that does not rely on threads or quoted replies. The entire history of a conversation can be viewed or replayed. Conversation participants can join or leave along the way without losing context, history, or content. Additionally, Google Wave adds real-time interactivity and collaboration to the communication.

In short, the potential for Google Wave to streamline and enhance communication for people with disabilities, especially screen reader users, is great. Could Google Wave be made accessible? I believe it could be. I would never advocate that accessibility constraints should limit innovation – indeed many of the most accessible technologies now available started as accessibility black holes. Of course it is always easier and better to implement accessibility as part of innovation, something clearly lacking in this case.

With ARIA and modern-day user agents and screen readers, Google Wave can be made accessible and become a powerful tool that ALL users can enjoy and benefit from – and people with disabilities have particular need for such enhanced communication tools. With a bit of education or guidance, and typical Google ingenuity, Google Wave has great potential to not only be a wonderful tool, but a wonderfully accessible tool.

(Contact the author through Google Wave at jaredsmith36459@googlewave.com)

Access the survey at http://webaim.org/projects/screenreadersurvey2/. The survey will take approximately 10-15 minutes. Please redistribute, particularly to screen reader and disability groups. The survey will remain open through October 2009.

As a follow-up and update to the original WebAIM Screen Reader User Survey, we are happy to provide an updated survey. By completing this survey you will help inform development choices for those creating accessible web content. All screen reader users, even those that use screen readers only for evaluation and testing, are invited to participate.

WCAG 2.0 color requirements

WCAG 2.0 requires that the foreground and background colors have a 4.5:1 contrast ratio at Level AA and a 7:1 contrast ratio at Level AAA. You can use our contrast checker tool to determine what the ratio is between any foreground and background color.

WCAG 2.0 also requires (at Level A) that color not be used as the sole method of conveying content or distinguishing visual elements. They further define this requirement for links with Technique G183, which states, “Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them.” This means that if you do not underline your links (or provide some other non-color designator for links), that the links must be sufficiently different in contrast from the surrounding text.

So if you combine these two requirements, in order to be Level AA conformant, your page must have all of the following:

• A 4.5:1 contrast between the non-link text color and the background.
• A 4.5:1 contrast between the link text color and the background.
• A 3:1 contrast between the link text color and the surrounding non-link text color.

In other words, your link color has to be significantly different from the background color AND the surrounding text color, which also has to be significantly different from the background color.

Meeting these requirements

If you start exploring this, you’ll find that this requirement leaves only a small window of available page and link colors. For example, if your page has black text on a white background and you use the standard blue color for links, the link color must be between approximately this color of blue (#6e5eff) and this color of blue (#531fff). Any lighter or darker and it will not have sufficient contrast to the adjacent black text or to the white background, respectively.

And if your text/background colors aren’t pure black and white, this significantly narrows or eliminates the window of colors with sufficient contrast.

Link states

This becomes more complicated if you want to provide various link states (hover/focus, visited, active) colors. If you go with the traditional blue, red, and purple colors for link states, each of these three colors would have to fit into the narrow window of available contrasts.

Some testing shows that this is possible… barely. The following colors for link states meet these requirements for a black on white page:

Normal: #3344dd
Hover/Focus/Active: #bb1122
Visited: #884488

But there’s not much wiggle room – if you change any of these colors much you’ll break either the 3:1 requirement to black or the 4.5:1 requirement to white. The W3C does provide a list of web-safe colors that fit within these contrast requirements. But if your page doesn’t have black on white (or vice versa), it quickly becomes impossible to get any one color to work, let alone two or three colors for the various link states.

Level AAA conformance

To complicate things further, if you’re looking for AAA conformance, which requires foreground/background contrast of 7:1, you have virtually no choice in the color combinations. You must have black text on a white background and your blue/red/purple colors must be VERY close to #3344dd, #b50010, and #804180. These work out exactly to 3:1 to black and 7:1 to white, the very minimal levels allowed.

Hover/focus state requirements

It’s important to note that according to G183, focus/hover states for links must have a non-color designator. This typically means that you would add the underline style to the link when it is hovered or tabbed to. This is a Level A requirement.

Because links that have current focus or are being activated will be visually apparent through the non-color designator, not to mention the fact the user has manually focused them, I believe the 3:1 contrast rule does not (or should not) apply to the hover, focus, or active states. In other words, it’s acceptable to have the hover, focus, and active link be very similar in contrast to the surrounding text color because the user must have done something with the link to activate that state AND the non-color designator must be present if they’ve done so. The 4.5:1 (or 7:1) contrast requirement to the background does apply to all link states.

Summary

Because of the WCAG 2.0 contrast requirements, if you don’t underline your links, there’s not much flexibility if you want to be Level AA, let alone Level AAA conformant. WCAG recognizes that meeting these contrast requirements “is not the preferred technique to differentiate link text”. Of course the easy solution to this is to simply underline links in their default state. Interestingly, underlined links can be the exact same color as their surrounding text, though this is far from optimal.

The contrast requirements for non-underlined links is a Level A guideline, which might suggest that they are of more importance than having high levels of contrast for non-linked content (which, interestingly, is only addressed at Level AA and AAA – white text on a white background with white underlined links is seemingly allowed at Level A). Regardless of conformance, it is vital for accessibility that there be good contrast for text and that links be discernible.

So, are the WCAG contrast requirements too stringent and inflexible? Or is it optimal for accessibility for WCAG 2.0 to limit non-underlined links to this narrow contrast window?

Update: The United States signed the treaty on July 30, 2009.

This Friday, July 24^th, at 4:45pm, President Obama will indicate his intention to sign onto the United Nations Convention on the Rights of Persons with Disabilities (CRPD). The document will likely be delivered to the UN on July 30^th. This is a historic occasion—one that will positively affect web accessibility here in the U.S.

Many WebAIM readers are familiar with the impact that this UN treaty will have on accessibility (We have posted on this topic before). The CRPD embeds requirements for accessible information throughout the document and it includes an entire section (Section 9) devoted to accessibility. The authors of the CRPD view the work of accessibility as an important mechanism for a “civil society” to affect true social inclusion.

Once the U.S. is a signatory to the CRPD, we will begin the long process to align our national laws and policies to that of the UN treaty. There will be much work ahead for those of us who advocate for accessible web content. We in the U.S. have waited a long time for this moment. Although our internal ratification process may take some time, let us give thanks that our nation has begun to join 140 others who have already signed onto the CRPD. As the 19th anniversary of the ADA draws near, this is a fitting step toward providing persons with disabilities with important extensions of their civil rights.