A couple of weeks ago now, an article was posted on LinkedIn that implied WCAG was “Impossible”. Numerous others, including myself, levied sharply negative responses to the article, but not to this specific claim about WCAG being “impossible”. I’d like to help my readers understand WCAG a little bit better.

Generalized statements are particularly false

The first thing to understand is that while it is easy to find things to say that criticize WCAG, many criticisms don’t stand up in context. Many people say WCAG is too long. I say it just feels that way and in many cases you don’t need an encyclopedic knowledge of WCAG and its associated materials. You need what is relevant to you in the context of your work. Sure, the volume of techniques and failures is massive, but the amount that are actually relevant to you is probably much smaller. Think about it: if you aren’t using SMIL or Silverlight or Flash, you can safely ignore those techniques and focus on what applies to you.

Accessibility, as a topic, can seem pretty nebulous if you’ve never been expected to make your systems accessible. I know this from experience. When I first got interested in accessibility, I knew nothing and made a lot of mistakes. Thankfully there were resources like the WebAIM discussion list where people freely shared information in a friendly environment. The regular contributors to that list helped me understand that accessibility isn’t hard when you learn to consider accessibility along the way.

Steps to Understanding WCAG

It is easy to call WCAG “impossible” if you don’t understand it. In fact, this is exactly why Billy Gregory and I came up with the idea of our talk Why WCAG? Whose Guideline is it, Anyway? with The Viking and The Lumberjack at CSUN this spring. Our point during the talk is that there are a number of things people misunderstand and our goal with the talk was to help people understand those things. It generated lots of talk and even controversy but hopefully also helped people understand WCAG a bit more. For those who weren’t there, let me help clarify WCAG.

WCAG is a Standard

WCAG probably feels long, but as a standard it really isn’t very long at all. The presentational format of W3C documents in general definitely doesn’t help, but as a W3C recommendation its normative content is actually pretty short. The full WCAG 2.0 itself is well organized if you stop and let it soak in a minute. It has a clear Introduction that describes its purpose, structure, and associated materials, and the content itself is well organized. The wall-of-text that is the presentation format doesn’t help the impression of its length, but once you understand the organization of WCAG, it won’t feel so long.

Many people have criticized the decidedly high reading level that WCAG is written in. I can’t say I disagree. It is dense information, but it is also clear. We must remember, WCAG is a Standard. It has been incorporated into international laws and (eventually) into United States laws. A standard can’t get to that point if it is contradictory or lacking in detail. At times, the WCAG Working Group agonized over the meanings of individual words – the type of activity I personally have no stomach for – and we should thank them for it. If you ever find yourself not understanding terms and phrases like “changes in context”, consult the glossary. (Hint: you can also ask for clarification on the WAI-IG mailing list)

Peel the Onion to get what you want

As I mentioned above, one of the things that make WCAG seem dense is its presentation. But what most people seem to miss so often is the true structure of WCAG. They discuss this in “Layers of Guidance” that I simplify below:

  • Principles – At the top are four principles that provide the foundation for Web accessibility: perceivable, operable, understandable, and robust.
  • Guidelines – Under the principles are guidelines. There are 12 guidelines that provide the basic goals that authors should work toward
  • Success Criteria – For each guideline, testable success criteria are provided.
  • Sufficient and Advisory Techniques – For each of the guidelines and success criteria in the WCAG 2.0 document itself, the working group has also documented a wide variety of techniques.

The numeric structure of WCAG’s Success Criterion follows the above structure: Principle, Guideline, Success Criteria. To Illustrate this let’s look at 1.3.1 Info and Relationships:

  1. Principle 1: Perceivable
  2. Guideline 1.3: Adaptable
  3. Success Criterion: 1.3.1 Info and Relationship

To understand WCAG and make it feel much less “impossible” you should first understand the Principles. This is the spirit of WCAG – the things that an accessible system should meet for the user. Everything else about WCAG simply provides more detail on how to meet those goals.

Next up are the Guidelines. There are 12 guidelines. These are the high-level goals for each Principle. For instance: “Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.”

Finally, the Success Criteria. In other words, these are the specific, testable criteria against which conformance is to be judged.

I’m of the opinion that those who criticize WCAG as being “impossible” are concentrating on the Success Criterion first without absorbing the Principles and Guidelines first. To truly get the value of WCAG, it is vital to first absorb and understand it from the top down: Principles, then Guidelines, then Success Criteria. The Success Criteria are worded very specifically and clearly. If, at any time, you find yourself feeling like a Success Criteria is confusing, run through it a couple of times with a careful read.

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)

To understand the above, first we need to understand that this is part of Principle 2: Operable. The goal for this is “User interface components and navigation must be operable.”. Also, this is the first guideline under Principle 2. “Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.” Let’s parse the Success Criterion itself by breaking it down:

  1. If keyboard focus can be moved to a component of the page using a keyboard interface,
  2. then focus can be moved away from that component using only a keyboard interface,
  3. and, if it requires more than unmodified arrow or tab keys or other standard exit methods,
  4. the user is advised of the method for moving focus away.

Our decision tree for testing this is then:

  1. Can focus be moved to a component of the page?
  2. Can that focus be moved to the component using a keyboard? (If not then there’s a 2.1.1 issue)
  3. Can that focus be moved away using a keyboard?
  4. Can focus be moved away standard exit methods? (read as: tab or shift+tab, but this might depend on the type of control)
  5. If standard exit methods can’t be used, is the different method disclosed to the user?

I realize that there are a couple of pieces of information that a layperson may not know in terms of how to test the above, especially when it comes to “standard exit methods”. This is where WCAG’s large volume of related documents come into play. You should explore these documents as necessary to get the additional information necessary to close the gap in understanding.

Impossible is Nothing

To borrow a phrase from Robert Pearson, “Impossible is Nothing” WCAG is not impossible. It would have never reached Final Recommendation status if it was impossible. Although unquestionably dense in nature, a careful read after understanding its structure can help considerably.

My company, AFixt offers full accessibility services from testing, training, consulting, and remediation. If you need help, get in touch with me now!