In short: WCAG 2.0 is here, it’s ready, now get on and use it.

Focus on the User

One of the main things I’ve noticed about WCAG 2.0 (and which has been the case for several versions now) is that it is much more focussed on the user and how the user interacts with the website than WCAG 1.0 was. WCAG 1.0 on the other hand tended to look at how precisely you’d used HTML to achieve a particular goal.

The emphasis has shifted from ‘are you using HTML according to the specification’ very much to can your site be used by disabled people. And that is how it should be.

For example, both sets of guidelines want text to be resizable by users. WCAG 1.0 says this:

Use relative rather than absolute units in markup language attribute values and style sheet property values.WCAG 1.0 Checklist

Doing that will mean that by changing the default text size in their browser, users will be able to change the size of text displayed on screen. The purpose of the rule — to allow users to adjust text size — is not explicit, instead you’re asked to comply with some technical rule without understanding how or why anyone will benefit from it.

With WCAG 2.0, it’s much clearer what the purpose is, even if it no longer cares how you achieve it:

Text (but not images of text) can be resized without assistive technology up to 200 percent without loss of content or functionality.WCAG 2.0

The emphasis is on the impact on the end-user. And that’s where in reality we find whether a site is accessible or not.

Validity

At an earlier stage of WCAG 2.0 I was very vocal in my objection to their decision to drop the requirement of HTML validity. This was watered down to the gubbins about properly nested tags covered in the level A criterion 4.1.1 Parsing. I had objected to this, but the WCAG Group came back to me and convinced me to agree with their point of view.

Their basic stance was, if you can use invalid code (for example embed which is well supported but is not part of the HTML specifications) to make a site more accessible, then is it not better to have an invalid site which is more accessible, as opposed to a valid site which has accessibility barriers.

And I had to agree with that. Don’t get me wrong, I still want my code to validate, but it’s more important that it is accessible and usable, and as the WCAG guidelines are taking accessibility as their goal, rather than ‘technical good practice’ it’s inevitable that this stance has to be taken.

Semantic HTML

There is an implication that WCAG 2.0 no longer cares about semantic use of HTML (using blockquotes properly, using tables properly, using headers and lists properly), because of its technology neutral stance.

It’s true certain things which were required in WCAG 1.0 are no longer required in WCAG 2.0. There’s no commandment explicitly stating that direct quotations must be used in <q> or <blockquote>, for example. Also, WCAG 2.0 doesn’t seem to care whether you used tables for layout or not, unlike WCAG 1.0 which specified:

Once user agents support style sheet positioning, tables should not be used for layout.WCAG 1.0, Checkpoint 5.3

Obviously the question here is whether user agents support style sheet positioning. I would argue that they do and therefore you can’t conform to WCAG 1.0 at AA if you use tables for layout. But WCAG 2.0 simply doesn’t care.

And why should it? It’s taking a technology-neutral standpoint; it doesn’t know whether you are using HTML, Flash, or some other technology to build your site. All it cares about is whether or not the site is accessible to your users.

But there are still a lot of things in WCAG 2.0 which would push you down the route towards semantic HTML: information and relationships need to be programmatically determinable (if items appear to be in a list, they need to be coded as such); a correct reading sequence can be programmatically determined (so even if you are using tables for layout, it still needs to work when linearized); pages are titled; meaningful headings and labels are required, section headings are used, the pages must parse successfully for markup languages and the name, role and value of all user interface components can be programmatically determined.

It’s just that these things aren’t explicitly stated in a technical manner, because of WCAG 2.0′s technology agnosticism.

My Personal Standard

I’ve shifted my personal standard to consider WCAG 2.0. I will strive to achieve WCAG 2.0 at the double-A standard for all new developments (except those requiring video, where I’ll stick with WCAG 2.0 at the single-A standard unless the resources available to me allow me to provide audio description and the like). In addition to this, I will also attempt to meet the following AAA-rated success criteria:

• 1.4.9 Images of text (no exception)
• 2.1.3 Keyboard (no exception)
• 2.2.3 No Timing
• 2.2.4 Interruptions
• 2.3.2 Three Flashes
• 2.4.8 Location
• 3.1.3 Unusual Words
• 3.1.4 Abbreviations

How well I achieve at this remains to be seen — I’ll let you know — but that’s what I’m aiming for.