WCAG 2 - a backward step for accessibility?

— Published August 4th, 2006  |  by David Moore   |  1 Comments

Published in 1999 by the Web Accessibility Initiative (WAI) committee of the W3C, version 1.0 outlines three priority levels of accessibility attainable by websites, from the basic level one (A) to the practically unobtainable level 3 (AAA).

The WAI have been working for years in updating the guidelines. This is a good thing, as the 1.0 requirements are confusing and outdated – having not kept up with recent best practice in the field.

Web accessibility and standards-compliant design

As well as the increase in the adoption and understanding of accessibility techniques since the 1.0 guidelines were published, there’s been a parallel uptake of standards-compliant design.

Led mostly by a grassroots movement headed by Doug Bowman, Jeffrey Zeldman, Eric Meyer and others, more and more websites are being built with code that conforms to standards (also published by the W3C).

Along with this, browsers have become much more uniform in how they interpret and display web pages. (IE 6 is still something of a laggard in this, but the forthcoming IE 7 is more compliant.)

This sounds like an uber-geeky topic, but standards-compliant pages have real benefits:

• Developers can build one version of a page that displays accurately across of a range of browsers and other devices.
• Pages are smaller in size, quicker to load and cheaper to host.
• Crucially for this debate, many of the standards requirements have played a major role in the the move towards accessibility.

A first look at WCAG 2 Oh dear

So it was with great interest we started poring through the final draft versions of the 2.0 guidelines (or “success criteria”, as they’re now called).

Laurence put it best in a posting to our intranet after his first trip through them, “Spent an hour on the WCAG. To summarise, I want those 60 minutes of my life back.”

To start with, the guidelines themselves are almost impossible to understand (and we do this for a living.) And this despite the fact that one new guidelines says to include an alternative version of any material that would be hard to understand for readers with a lower secondary education level. So they want everyone to write stuff for poorly educated readers, while they can’t even manage to communicate to their expert peers.

However, if you can work out what it is being said (and Joe Clark’s opinionated but comprehensive attack in A List Apart is a great help here), there are some serious problems. These are just the most problematic of the ones from Clark’s list:

• “You can still use tables for layout. (And not just a single table - tables for layout, plural.)
• You'l be able to define entire technologies as a 'baseline' meaning anyone without that technology has little, if any, recourse to complain that your site is inaccessible to them.
• You also have to provide an alternate document if a reader with a 'lower secondary education level' couldn't understand your main document. (In fact, WCAG 2 repeatedly proposes maintaining separate accessible and inaccessible pages. In some cases, you don't necessarily have to improve your inaccessible pages as long as you produce another page.)”

These run completely counter to the growing set of tried and tested accessibility techniques that have been developed over the last few years.

As Clark says, “as a working standards-compliant developer, you are going to find it next to impossible to implement WCAG 2.”

The danger of wiggle room

Another concern is that there’s so much obscurity and wiggle room in the guidelines (partly because they’re deliberately supposed to be technology-neutral) that, when it comes to specific coding:

• it’s very hard for careful developers to work out exactly what the guidelines require
• it’s very easy for less-than-careful developers to claim to have met the guidelines while not actually building sites that are easy for people with disabilities to use

There’s much argument about the process by which this happened – with whispers that it only really benefits big businesses, who can now crank out dodgy pages with impunity, and sell automated testing kits to measure things that can’t really be automated.

But if you bear in mind that under certain circumstances it’s illegal to build an inaccessible site, it’s likely that WCAG 2 will be the standard used to evaluate accessibility (and hence legality) in many jurisdictions.

Many public sector organizations such as universities and government departments currently use the WCAG 1 guidelines as their basis for accessibility work, and many of those will no doubt shift to WCAG 2. So even if you’re not running the risk of breaking any laws, you might still be forced to interpret and adhere to what seem to be flawed requirements.

Other options

There are other more useful standards out there, such as the US Section 508, and the particularly good UK PAS78 (although both of them could do with catchier titles).

And Joe Clark is planning a 'WCAG Samurai' group to work on their own edits to WCAG 1.

The state of things

So where does this leave you, as a manager of a website or a developer working on one? Sadly, more confused than before.

The good news, however, is that people who build websites already have access to a set of best-practices that actually work.

The bad news is that it’s not clear how we should work them up into standards that we could all agree to follow. WCAG 2 seems to have sent us backward—not forward—on this.

We’ll be looking at the implications of WCAG in much more detail at one of our half-day workshops in our upcoming Boot Camp event. If accessibility is something you have to, or choose to, care about, then you won’t want to miss it.