An overview of WCAG 2.0

Web accessibility is about universal access. It is the idea that any user should be able to access all content on the Web, regardless of platform, user agent, or physical disability. This is not some lofty philosophical ideal. It is just plain good business.

As with usability, accessibility is not a binary thing. While accessibility checker sites exist, they are only a starting point. User testing with real live people is the only way to know for sure a site is accessible. However, we do have guidelines for how to create Web pages that help us along the path towards universal access.

The WCAG WG is going to publish WCAG 2.0 as a formal recommendation later this year. I love the revisions and the new approach they are taking. It is a much more practical and accessible (pun intended) set of guidelines, more of a philosophy of how to make pages, than mechanical rules. This article is an attempt to digest and summarize the guidelines.

The guidelines are based on four principals of accessibility. The four principals are:

1. Content must be perceivable to each user
2. User interface components in the content must be operable by each user
3. Content and controls must be understandable to each user
4. Content must be robust enough to work with current and future technologies

The four principals above are the basis for the recommendations. The following is my summary of the WCAG 2.0.

Section 1 – Content must be perceivable to each user

1.1 Provide text alternatives for all non-text content &
1.2 Provide synchronized alternatives for multimedia

Providing a text alternative to non-text content (charts, diagrams, audio, pictures, animations) allows the information to be rendered by a variety of user agents, making it available to visually impaired users via screen readers, or aurally/visually impaired users via tactile devices (e.g. Braille translators).

Added benefits of text alternatives are the ability to search the content, as well as the ability to repurpose the content in multiple formats.

This is especially valuable to your biggest segment of blind users: search engines.

For non-text content that conveys information the text version should convey the same information.

Non-text content that does not convey information that is intended to create a specific sensory experience should be described and labeled with a text alternative.

Non-text content that does not convey information or sensory experience should be able to be ignored (i.e. placed as background images in the style sheet, etc.)

For live audio or video content, the text alternative should at least identify the purpose of the content with a descriptive label, when possible, full live captioning should be made available. Offering a sign language alternative also helps greatly, as it is a primary language to many deaf users.

Captioning for video should contain not only the dialog, but also should identify who is speaking and notate sound effects and other significant audio.

1.3 Ensure that information, functionality, and structure can be separated from presentation.

Essentially this point can be taken care of by designing your site according to Web standards. Use of proper semantic markup ensures that user agents will be able to interpret all information you wish to convey.

Information that is conveyed by variations in the text (size, shape, color) should also be conveyed via alternative methods (proper semantic html tags, symbols, etc). Keep in mind that what you see on your screen in a screen browser is not necessarily what the user is experiencing. (Monochrome or low-contrast monitors, text only browsers, etc).

1.4 Make it easy to distinguish foreground information from background images or sounds

There should be sufficient contrast between foreground and background colors to be able to discern the information in a chart or text. (Defined as a luminosity contrast ratio of 5:1 for level 2 compliance and 10:1 for level 3 compliance)

A user should be able to turn off any background sound that plays automatically (may I interject that you shouldn’t use background audio at all?).

Make sure that non-speech sounds (background noise, music) are low enough in the mix so that a user can understand the speech (defined as 20 decibels lower than speech.)

Section 2 – User interface components in the content must be operable by each user

2.1 Make all functionality operable via a keyboard interface.

When content can be operated through a keyboard or alternate keyboard, it is operable by people who cannot use devices such as mice that require eye-hand coordination as well as by people who must use alternate keyboards or input devices that act as keyboard emulators.

2.2 Allow users to control time limits on their reading or interaction.

Some users may require more time to complete a transaction than is allowed by session timeout limits. (I find myself in this camp from time to time and I don’t really have any definable “disability”). Make sure that users don’t lose and data entered due to a time out, and that they have the ability to extend their session time.

2.3 Allow users to avoid content that could cause seizures due to photosensitivity

Flashing or blinking content can cause seizures. Make sure users are aware that they are about to see content that is flashing or blinking, and allow them to access the content without seeing the flashing or blinking.

More info on flash thresholds

General Flash Threshold

Red Flash Threshhold

2.4 Provide Mechanisms to help users find content, orient themselves within it, and navigate through it.

As you create the navigation, group related links together. Use <a> tags or the <link> element appropriately (rather than image maps or flash navigation) and provide a way to quickly skip through and past links.

Each page should have a descriptive <title> tag and have descriptive header tags within the page.

Link text should be comprehensible outside of the context of the rest of the page (ask yourself “if I was seeing only this link, would it tell me what I’m going to see?). Use the title attribute on <a> tags to help supplement this description.

Pay attention to tab order on links and forms on the page, does it make sense logically?

Provide methods such as breadcrumb trails, site maps, and other queues to help a user understand where they are in the context of the site at large.

2.5 Help users avoid mistakes and make it easy to correct them.

Provide the user with clear instructions and context-sensitive help information if input is required.

If an error occurs, make sure the user is aware of the error, and can determine what is wrong. Give them suggestions for how to correct the error (if correction is possible). An interesting application of this is 404 error pages. Instead of presenting someone with a blank 404 page, take them to a site map or search form for your site. Let them know possible reasons they are seeing a 404 page.

Make sure the user can avoid serious consequences as a result of a mistake. Financial and legal transactions should all be able to be cancelled or reversed, and should be confirmed before submission.

Section 3 – Content and controls must be understandable to each user

3.1 Make text content readable and understandable

Identify the primary language of a page, and identify any changes in the primary language within a document.

Allow the user to expand abbreviations and acronyms.

Provide glossary definitions for unusual or difficult terms, jargon, or idioms.

When content requires reading ability above “lower secondary education level”, provide a summary, illustration, or other alternative content in the “lower secondary education level”.

3.2 Make the placement and functionality of content predictable

To me this is the most no brain-er one of all. Essentially, don’t change the order of navigation links, the look and feel of the site, the labels on forms or content units, except by user request, or with warning before and explanation after.

Section 4 – Content must be robust enough to work with current and future technologies.

In Short: code to specification with whatever technology you are using.

Conformance Levels

There are three levels of conformance for each guideline. Unlike WCAG, these are labled “levels” rather than “priorities”. WCAG 1.0 gave the impression that level 1 was more important than 2 which was more important than 3. This was never the case, however, and so the new revision hopes to clarify that. All levels are essential, but are grouped as follows:

Level 1

1. Achieve a minimum level of accessibility through markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies.
2. Can reasonably be applied to all Web resources.

Level 2

1. Achieve an enhanced level of accessibility through one or both of the following:
   1. markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies
   2. the design of the content and presentation
2. Can reasonably be applied to all Web resources.

Level 3

1. Achieve additional accessibility enhancements for people with disabilities.
2. Are not applicable to all Web resources.

Source:
WCAG 2.0 November 23, 2005 Working Draft

WCAG, W3C, accessibility, web, design, usability