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.
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.
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.
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.
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.
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.”
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
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.
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.
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:
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.
People with learning disabilities like dyslexia were neglected in WCAG 1 because:
It’s all being fixed in WCAG 2, but it’s not going all that well thus far.
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.
This one’s kind of weak, since operabililty is really a question of user agents, and we already have UAAG for that.
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.
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.
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.
This one’s more technical. It’s about compatibility and futureproofing.
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?
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?
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:
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.