It’s one thing understand the basic principles and guidelines for making your site more accessible and another thing to actually meet those guidelines.
I’ve been talking about accessibility for a few weeks now. First I offered some thoughts about where I am in starting this journey followed by an attempt to determine what it means to be accessible.
Last week I started to look at some documents from the Web Content Accessibility Guidelines (WCAG 2.0). We took a high level glance at the principles and guidelines of WCAG and left off just as we were about to consider what we need to do to comply with them. Let’s pick things up there and see what we need to meet WCAG conformance.
To conform to the WCAG standards, a site must satisfy all of its conformance requirements, which means it must satisfy the success criteria for the different guidelines. When a site has no content that violates the success criteria, it conforms to the standard.
To conform five requirements must be met.
- Conformance Level
- Full pages
- Complete process
- Accessibility-Supported Ways of Using Technologies
Requirement 1: Conformance Level
Last week I mentioned there are three levels of compliance, A, AA, and AAA. To conform a site must at least satisfy level A compliance, by meeting all the success criteria for level A compliance. That’s the minimum, but there’s more you can do.
To meet level AA compliance you would need to meet all the success criteria for level A and level AA. Similarly AAA compliance needs to meet the success criteria for all three levels. The spec notes that some content can’t meet all the criteria for AAA compliance and doesn’t recommend level AAA for all sites. Level AA is really the sweet spot.
Before you spend too much time wading through all the details of a particular success criteria, you’ll want to decide which level of conformance you’re aiming for and then focus on the criteria and techniques that are the same level or lower.
The quick reference guide makes it easy to filter based on which level of compliance you’re trying to meet, which is one reason you’ll likely revisit it a lot.
Viget offers Interactive WCAG 2.0, which also allows you to filter guidelines based on levels of compliance as well as by responsibility (design, development, front end, or UX). I think it’s easier to use than the quick reference.
Requirement 2: Full Pages
The idea behind this requirement is that an entire page needs to conform. If any part of the page or any piece of content doesn’t conform, then the whole page doesn’t conform.
It can go beyond the page, though. Say you have a page with a video and the text alternative is on a different page. The text alternative would be considered part of the full page with the video for the purpose of conforming to WCAG.
I can see where this requirement will increase in importance as content becomes more modular and perhaps lives in different places.
Requirement 3: Complete Process
For processes that involve multiple pages, such as a multiform checkout process, all pages in the process must conform before any of them do.
It makes sense. If the first page at checkout is accessible, but the rest aren’t, how accessible was that first page? It certainly isn’t accessible in any useful way.
Requirement 4: Only Accessibility-Supported Ways of Using Technologies
The idea here is that all information and functionality must be provided in an accessibly supported way. For example an image that also serves as a link to another document, must have a text alternative for assistive devices.
Another example would be if you created custom controls, something that isn’t a button or link, but carrying similar functionality. User agents wouldn’t be able to present an alternative, since the controls are custom. You would have to provide the alternative, likely in the form of ARIA roles, states, and properties.
Requirement 5: Non-Interference
This requirement offers something of an exception to the first requirement. It says it’s ok use technologies that are not accessible as long as the information is also available using accessible technologies that are supported.
In addition, the non-supporting technologies must not interfere with the accessible technologies in any way.
It is then possible to have part of a web page not conform and have the page itself conform. The non-conforming content would need a conforming alternative and it can’t interfere with any conforming part of the page.
I’ve mentioned success criteria a number of times this week and last week, but I haven’t provided much in the way of specific information about them. There’s a reason. To talk about them means to get very deep into the details, too deep for a single post or series of posts.
When creating your site, you should determine the overall level of conformance you’re trying to reach. We’re new at this, so let’s assume we’re trying to achieve level A compliance.
Once you know what level of conformance you’re after you can find the success criteria you need to meet and you’ll probably be clicking through to multiple documents depending on how much detail you need.
The easiest way I’ve found to get to the details is to start with the guidelines. Each of the sub-guidelines lists which level of compliance it meets. For example guidelines 1.2.2 and 1.2.4 both deal with adding captions to audio. 1.2.2 is for prerecorded audio and will help meet level A compliance. 1.2.4 is for live audio and it meets level AA compliance.
Naturally the success criteria for each will be different. You can find the success criteria through the two links to the right of each guideline.
The “How to Meet” link will take you to the Quick Reference Document. If you wait a few seconds or longer, the page will jump to the criteria for the specific guideline. When it does you’ll find additional links for the details you want.
The “Understanding” link will take you directly to a page with details about the specific criteria. Here’s the page for understanding success criteria 1.2.2 (which is the criteria for guideline 1.2.2). The page will give you details about the intent behind the criteria, some examples of success, and additional links the different techniques and common failures.
Again I can’t possibly cover all of them here, but let me at least give you an example of the success criteria for one guideline.
Guideline 1.4.1 is about the use of color and it says that color should not be the only visual means to convey information, indicate an action, prompt a response, or distinguish a visual element. One example of success is given as a form that uses color and text to indicate required fields.
A form contains both required and optional fields. Instructions at the top of the form explain that required fields are labeled with red text and also with an icon whose text alternative says, “Required.” Both the red text and the icon are programmatically associated with the appropriate form fields so that assistive technology users can determine the required fields.
Again, this is simply an example that would meet the criteria for success for this particular guidelines. It doesn’t mean you specifically have to use red text and an icon with a text alternative.
Techniques for WCAG 2.0
That brings us to the last of the four layers of WCAG guidance, sufficient and advisory techniques. Like the success criteria, the information comes in the form of details for specific guidelines.
You can find the techniques in the same documents as the success criteria. They’re included as a collection of links to yet more pages with yet more details.
You can also find them all collected in the Techniques for WCAG 2.0 document, though I’m not sure how much they’ll make sense when the connection with the success criteria is removed. The list is probably best when you know the name or identification of a technique and want to find it as quickly as possible.
One nice thing about the techniques is the spec mentions updating them twice a year to present current best practices.
Please understand that none of the techniques are required. Meeting the success criteria is required, but how you do that isn’t. The techniques are examples of how you might meet the criteria and there are typically several examples for each.
The techniques come in three flavors.
- Sufficient techniques are reliable ways to meet the success criteria
- Advisory techniques are suggested ways to improve accessibility. They’re often very helpful to some users, and may be the only way that some users can access some types of content.
- Failures are things that cause accessibility barriers and fail specific success criteria. They’re good for knowing what to avoid.
Again the details are far too numerous to try and include them here, however I will offer an example from the same success criteria about the use of color not being the only visual way to communicate information.
One of the sufficient techniques is G205: Including a text cue for colored form control labels. Click through to the specifics and you’ll find an example of using the word “required” in addition to having the label in red.
<label for="lastname" class="required">Last name (required): </label>
<input id="lastname" type="text" size="25" value=""/>
Last name is a required field. The label gets both a class of required, which is styled to display the text as red and it also receives the word required in parenthesis next to the label.
I suggest first knowing what you’re trying to do and then finding a technique to implement it by then clicking through to the various documents that offer the details. If you start at the either the quick reference or the WCAG spec you can find your way to the more detailed documentation.
The web content accessibility guidelines (WCAG 2.0) should be one of your first stops in trying to piece all this accessibility information together.
The WCAG documents provide four basic principles, each with guidelines and sub guidelines. The level of conformance you’re trying to achieve will determine which of the guidelines you’ll want to dig deeper into.
And dig you can. Be prepared to find one source where all the guidelines are listed with links to the different resources that hold the specific details. I’ve presented a few throughout these posts, though the How to Meet WCAG 2.0 Quick Reference , the Viget Interactive WCAG, and the guidelines section of the WCAG spec are probably the best pages to bookmark.
There is a lot of information to absorb and digest when you’re looking through the WCAG documents. Don’t feel overwhelmed. Much are specifics that you don’t need to memorize. They serve as reference.
Hopefully I’ve helped provide some general understanding and context so you can feel more confident as you click around to the specific details. Next week I want to continue and start looking at ARIA role models, states, and properties.
Download a free sample from my book, Design Fundamentals.