Joe Clark: Media access

Updated 2004.09.21

WCAG 2: All the sugar and twice the caffeine™

Today we’re going to talk about the Web Content Accessibility Guidelines, WCAG.

It’s one of the three accessibility guidelines produced by the Web Accessibility Initiative of the W3C.

Note

I just contribute to WCAG. I don’t work for the W3C and I’m not even a “participant in good standing.” Today what I’m giving you is expert opinion. You need to keep both those words in mind. Other experts will give you other opinions.

I’ve got good news and bad news

The good news is that WCAG 2 is more comprehensive but actually easier to understand and comply with.

The bad news is that a significant minority of the concepts in WCAG are terrible or simply false – but they nonetheless stand a good chance of making it into the final guidelines.

Quickie recap of WAI

WCAG is brought to you by the Web Accessibility Initiative, or WAI, a unit of the World Wide Web Consortium, the W3C. The people who put WCAG together are the WCAG Working Group.

Other guidelines

WAI actually has three sets of Accessibility Guidelines. Today we’re talking about Web Content Accessibility Guidelines, or WCAG. The other two are Authoring Tools Accessibility Guidelines (ATAG, pronounced “AY-tag”) and User Agent Accessibility Guidelines (UAAG, pronounced “YOU-ag”).

The current WCAG gives you three levels of “conformance.” You can declare that your page or your site meets any of three priority levels of accessibility.

Naturally, each level has two different names.

Levels

  1. Level A means you meet all the Priority 1 guidelines. There are 15 of those.
  2. Level AA means you meet all the Priority 1s and 2s. There are 29 of those.
  3. Level AAA means you meet absolutely all the guidelines, Priorities 1 through 3. And there are 18 of those.

In practice, there are fewer sites online that meet Level AAA than there are people in this room. Some people make the case that the Priority 3 guidelines are so vague and contingent that it’s actually impossible to meet them.

For example, in the U.K. they released a survey of Web accessibility of 1,000 sites (HTML version). Using automated testing, they found no sites whatsoever that met Level AAA. Now, automated testing can’t tell you everything, but it is at least indicative.

And in practice, Priority 2 gives you the biggest bang for your buck. If you don’t meet Priority 1, some people with disabilities will have trouble using your site, WAI tells us. If you don’t meet Priority 2, some people may have trouble. So if you meet Priorities 1 and 2, you serve the largest single chunk of people with disabilities online.

Also, Priority 1 doesn’t require valid code, while Priority 2 does, and that’s known to be important to screen readers. And anyway, as we all know, valid code represents Correct Thought.

The Ontario government and the federal government both require Priority 2 for their sites, though of course it’s easy to find pages that don’t comply.

Current status

WCAG 2.0 is in a draft stage, and if we’re very lucky it will become an official W3C Candidate Recommendation by this time next year. After two more stages, it becomes an official W3C “recommendation.”

What WCAG 2 isn’t

WCAG 2 is not like XHTML 2. It isn’t a replacement for WCAG 1.

Nothing says you can’t still comply with WCAG 1. Especially if you’re using HTML instead of XHTML, you might want to stay oldschool, since your code already is.

It also isn’t a hopelessly radical departure. WAI isn’t proposing something insane, like eliminating the img element.

Something else not to worry about

If your existing pages meet Priority 2, you may only have to tweak a few things to meet WCAG 2 at some level.

But if you barely scrape by with Priority 1, you’ll definitely have work to do. Among other things, there’s a strong chance that you won’t be able to claim compliance with WCAG 2 at all if you don’t have valid code. Say goodbye to tag soup.

New shit

Not just about HTML

In theory, WCAG 2 will apply to any Web resource of any kind. WAI wants to publish generic guidelines and then also publish separate techniques documents for different technologies, like HTML and CSS. But in practice, WAI can’t stop thinking about the kind of HTML we saw back in 1997. They’re mentally fixated on primitive Web sites that look like the W3C’s own site. Plus they really hate dealing with anything they didn’t invent themselves.

We’ll be really lucky if the guidelines do end up being truly generic. We’ll also be lucky if we see techniques documents even for widespread technologies like Flash and PDF.

Get your priorities straight

WCAG 2 still has priority levels. At the moment, WAI thinks there should be three priority levels, just like WCAG 1.

But there will probably end up being only two priority levels. I’m waging a battle to get the WCAG Working Group to accept that, if nobody meets Level AAA now, nobody is gonna meet it five years from now, either.

Nonetheless, priority is less important in WCAG 2 than in WCAG 1. That’s because the guidelines are organized around principles first rather than increments.

And in true quasi-governmental fashion, the principles have really euphonious and consistent names:

Principles

You’d think those would work better as nouns – Perception, Operation (or Function), Comprehension, and Robustness – but you can’t budge WAI on that. They love their polysyllables.

Within each principle are the various priority levels. They don’t have their story straight on those yet, either: Some topics have only Priority 2 guidelines, not even the basic Priority 1. Many have no Priority 3. Some skip Priority 2. So the concept of priorities is unstable and needs work, but there’s no chance at all that WAI will drop it.

So let’s assume they accept reality and go with two priority levels. That means you’ve got four or eight sets of requirements to fill, depending on which priority level you want to meet. You’ve got four principles with one or two priority levels each.

By all appearances, that seems like more work, but in practice the guidelines are better organized and you can handle them in chunks much more easily than you can with WCAG 1.

More emphasis on LD

People with learning disabilities like dyslexia were neglected in WCAG 1 because:

  1. accessibility advocates, including me, were pretty much unfamiliar with their needs, and
  2. their needs are difficult to meet on the real Web, since the Web is mostly text and this group’s relevant problems are reading and writing.

It’s all being fixed in WCAG 2, but it’s not going all that well thus far.

Scoping

If there are certain parts of your site you can’t bring into compliance, you will probably be able to declare those parts as exceptions and still meet WCAG 2. They’re calling this “scoping”: You can declare that the scope of your accessibility statement includes X number of pages and excludes Y number of pages.

In a lot of cases, people will use scoping to exempt themselves from having to deal with multimedia, since that’s time-consuming and expensive and relies on expertise that almost nobody has. But, on the whole, scoping is a more realistic approach: Getting 95% of your pages to WCAG 2 compliance and being honest about the other 5% is a step up from WCAG 1.

Another way you may be able to use scoping is if the WCAG Working Group makes a mistake or technology leaves a guideline in the dust. With discretion and in good faith, you can exempt yourself from meeting a guideline.

However, all of these concepts are under discussion, because it’s too easy for wankers to come in and simply exempt themselves from whatever they don’t feel like complying with. The recent settlement with Ramada and Priceline in New York state allowed both companies to exclude about half of WCAG 1 but still meet the terms of the settlement. We don’t want that happening across the board in WCAG 2.

Principles

Perceivable

You still need alt texts
Only now, they’re trying to do sensible things like handle images of paintings and so on that can’t really be epitomized in words. You won’t have to try to encapsulate the “Mona Lisa.”
You still have to do captioning and audio description
People overlook the fact that WCAG 1 Priority 1 requires captioning and audio description of video, both of which are pretty much impossible to find online. It’s still a basic requirement in WCAG 2, though I’m trying to get WAI to accept that not every piece of video needs description. Plus they’ll let you put a placeholder in for things like Webcams, though they haven’t gotten that one worked out yet. Audio-only feeds are still up in the air, but if you run an Internet radio station, you probably won’t have to do real-time-captioning of the whole thing. Thankfully.
You’re supposed to separate “information, functionality, and structure” from presentation
This one’s gonna be tricky, since you can use a presentation mechanism like CSS to add information through generated content. Plus WAI is obsessed with micromanaging details like emphasis. And they still don’t understand the real issues in colourblindness after my telling them what the real issues are for a year and a half. I even explained it to them when they were in Toronto for an “f2f” a year ago.
Foregrounds and backgrounds need to be distinguishable
WAI also wants to micromanage you on foreground and background colours and sounds, even though the real way to handle that problem is through different stylesheet variations.

Operable

This one’s kind of weak, since operabililty is really a question of user agents, and we already have UAAG for that.

Make everything work via keyboard
That’s obviously impossible if your Web interface requires drag-and-drop. Or at least very difficult. Apart from using standard event handlers, it’s not your problem. And in the real world, you don’t even have to do that, really, since adaptive technology long since adapted itself to event handlers that assume you’re using a mouse.
Time limits
You have to let people pause or extend time limits, unless we’re talking about a game or a test or an auction where that would be contradictory.
Don’t blink your Flash
They’ve got much better guidelines, backed up by actual research, that tell you how fast your flashing or blinking object can and cannot flash or blink. Too much flashing and you can cause seizures for epileptics, like that episode of The Simpsons where they watch the seizure-inducing Japanese anime.

They’ve got some dodgy stuff in there, too, like “facilitate the ability of users to orient themselves and move within the content.” Well, that’s information architecture, not accessibility.

Also, they want you to correct people’s errors. Essentially, that will require a spellchecker, which should be built into a browser. That requirement is obviously relevant to forms, though. You should be able to type information into a form and have it do a sanity check. That’ll help people with dyslexia and other learning disabilities who don’t type well.

Understandable

This is the one that’s really not gonna work.

What advocates for learning disabilities really and truly want is to remove content from the Web that they deem too hard to understand. And I really mean “what the advocates deem too hard to understand” – advocates, not actual people with learning disability.

They also want to stop you from writing it in the first place. As icing on the cake, they want to force you to use as many illustrations as possible (even if you’re blind and you can’t illustrate anything). And if they had their way you’d use “simple, uncluttered, legible fonts” fonts like Comic Sans.

Now, they’re not going to get all of that in WCAG 2, but they’re certainly trying hard. WCAG 2 threatens to impose severe and unmanageable restrictions on the content you can produce.

First the good news.

Language is still important
You still have to declare base language for documents and any language change inside them. That way, screen readers can use the correct pronunciations.

And thus ends the good news.

Now, these guidelines are the most likely to change of anything in WCAG 2, but at present they would force you to do the following:

There’s also two full pages of guidelines that deal with reducing the complexity of your writing. The implication here is that we have to justify any use of any terminology that some dyslexia advocate somewhere might consider too hard.

And it gets worse: All related pages have to look and act the same: “Components that are repeated on multiple ‘pages’ within a resource or a section of a resource occur in the same sequence each time they are repeated.” Goodbye, Web design. All your design are belong to us.

Robust

This one’s more technical. It’s about compatibility and futureproofing.

You have to use valid code
It won’t be an option. The only question is which conformance level will require it, Priority 1 or 2.

However, they also want you to conform to UAAG, which you couldn’t possibly do unless you’re writing your own browser or player. When was the last time you did that?

Summary

I’ve given you a tour through the major points of interest in WCAG 2. You’ll find every link you ever wanted in my speaking notes. Now, how can you get involved?

What you can do to help

The WCAG Working Group has a lot of wankers running amok in it. It’s also very insider: In principle anyone can contribute, but in practice only the insiders are listened to.

It’s very hard to explain basic facts to these people. If an insider says 2+2=5, it takes the better part of a year to prove that it actually equals 4.

So what we need to do is overwhelm them with evidence. I wrote an article for A List Apart calling on standardistas to contribute to WCAG 2, and nobody did. This is my second kick at the can.

I need you to do three things:

Come up with test pages for as many WCAG 2 issues as possible
We need real-world examples. So if you’ve got a page that’s remotely similar to the topic they’re talking about, consider modifying it slightly and putting it at a stable URL we can use.
Read and comment on at least one WCAG 2 draft
You can just send an E-mail. It’ll take you an hour or two. I especially need you to get all reality-check on their arses: Whenever they say something ridiculous, you need to counter it.
Keep the LD “advocates” from overthrowing the Web
We need to support any proposal that can be proved to increase accessibility for people with cognitive disabilities. We need to eliminate everything else.

Now, why would you want to bother? Essentially, it’s a question of enlightened self-interest.

We need your help here to make WCAG 2.0 bulletproof. If you don’t help out now, you’ll have nothing to complain about later. And, if we actually do a good job with WCAG 2, your pages will probably actually be accessible.


You were here: joeclark.orgMedia accessTOevolt presentation → Speaking notes