WCAG 2.0: Woeful to Wonderful in One Easy Draft?

Posted May 25th, 2007 by Jack Pickard

----

Well, when I commented on the previous draft of Web Content Accessibility Guidelines (WCAG 2.0) 
for Accessites, it was definitely sitting closer to the 'woeful' category, and I was perfectly 
willing to tell them so. That was a year ago. They've since had ample time to work on it and 
improve matters. The question is, have they?

Judy Brewer, in an interview with the The Web Standards Project (WaSP), said:

    ...you'll be seeing significant changes in the upcoming Working Draft. We want people
    to take a good look at this one when it comes out, and let us know what you think. 
                                                             -- Judy Brewer in WaSP interview 

Well, I have, and I will.

The two main criticisms that were leveled against the previous version were that the 
documentation was too wordy and was also bordering on incomprehensible. Taken as a whole, 
the documentation still comes to a sliver under 200,000 words, so it might still seem somewhat 
daunting.

However, to suggest that anyone has to read the whole documentation to use it is a fallacy: with 
WCAG 1.0 the checklist of checkpoints was referred to most, and then links from this to the 
supporting documents were followed if more information was needed.

The nearest equivalent to this for WCAG 2.0 is probably the WCAG 2.0 Quick Reference Document, 
which still comes to a rather hefty 14,700 words. Fortunately, however, this document is set up 
so that by changing the options at the top, you can rule out criteria that do not apply (e.g. 
if you don't use multimedia, you can hide the features that relate to this).

Okay, it's still some size, but unlike the WCAG 1.0 checkpoints, this also includes lists of 
common failures against the checkpoints, as well as techniques to ensure that the checkpoints 
-- whoops, sorry, success criteria -- have been passed. It's therefore directly comparable to 
the WCAG 1.0 list of checkpoints with added cross-references.

This quick reference document will therefore serve as the primary document for my review, once 
I got past some of the other changes. Note that it's not possible to cover everything in the 
document: I've tried to pick out a few things -- hopefully representative -- to give a 'flavour' 
of each section.


Principles, Techniques and Conformance

If you've read any of the documentation relating to WCAG 2.0 before, this section might not 
seem entirely new, but there are still some changes between this draft and the last one, so 
it's probably worth reading anyway. If WCAG 2.0 is new to you, then this will serve to 
highlight some of the major differences...

First, the WCAG 2.0 are based upon 4 POUR (Perceivable, Operable, Understandable, Robust) principles:

    * Content must be Perceivable
    * Content must be Operable
    * Content must be Understandable
    * Content must be Robust

Within each of these principles, you have guidelines. Within each guideline, you have success 
criteria (née checkpoints). Unlike the WCAG 1.0 checkpoints, each of the WCAG 2.0 success 
criteria have been specifically designed to be testable.

Each guideline then has levels -- the traditional A, AA and AAA -- within which may exist 
various success criteria. It is possible for a higher level success criterion to be a stronger 
version of one found at a lower level, and equally it is possible that a particular guideline 
might not have success criteria at each level.

The success criteria that you have to use will depend upon the accessibility-supported 
technologies that you are using. HyperText Markup Language (HTML) and Cascading Style Sheets 
(CSS) count as accessibility-supported technologies: they are widely available and have 
accessibility support in many native user agents. Other technologies which are supported by 
widely available plug-ins would also qualify, but if you're planning on producing your own 
encoding system accompanied by your own browser, don't expect this to qualify.

    Any information or functionality that is implemented in technologies that are not 
    accessibility supported must also be available via technologies that are accessibility 
    supported.                                                                 -- WCAG 2.0 (1) 

It's worth noting that this also allows for closed environments (such as corporate intranets) 
to rely on technologies which aren't necessarily widely availably or accessibility-supported 
elsewhere provided that they are widely available and accessibility-supported within that 
closed environment.

There's also an important distinction made between individual web content pages and pages 
used as part of a process:

    Example: an online store has a series of pages that are used to select and purchase 
    products. All pages in the series from start to finish (checkout) must conform in order 
    to claim conformance for any page that is part of the sequence.            -- WCAG 2.0 (2) 

In the previous draft of the WCAG 2.0 guidelines, it must be noted that in order to achieve 
the AAA (highest) level of conformance, you had to pass all of the success criteria at 
level A and AA, but only half of the relevant success criteria at level AAA. This has now 
changed to be more like WCAG 1.0: you must pass all of the conformance criteria to comply 
with that particular level.

Under WCAG 1.0, once you'd achieved conformance, you just had to stick a little icon on 
your page somewhere showing your conformance level (or more usually the conformance level 
you mistakenly believed you'd reached). WCAG 2.0 handles conformance claims very differently.

In order to make a conformance claim you must now specify:

    * The date of the claim
    * The guidelines, version and Uniform Resource Locator (URL)
    * The conformance level satisfied
    * A description of the scope of the claim (e.g. the whole site, which parts, 
      any exclusions)
    * The accessibility-supported technologies your claim relies upon

Note that 'relies upon' isn't the same as 'uses'. You can use whatever other technologies you 
like providing that your site is still accessible to a visitor at the same conformance level 
even if they don't support technologies you use but don't 'rely upon'. Get it?

They then go on to suggest that you may also wish to list further things -- other success 
criteria you've passed, other technologies you use, any additional steps you've taken to 
enhance accessibility and so on. As none of this is mandatory and is probably of very little 
benefit to any site visitor (see showing web accessibility statements the door -- or not, as 
noted in this counterpoint), I wouldn't put in anything that's not mandatory.

For Web 2.0 technologies (i.e. those things with actual user interaction as opposed to "stuff 
with rounded corners"), there is an awareness that not all of the content is within the user's 
control: comments on blog sites and similar are frequently outside the user's control. The 
Working Group have arrived at the idea of a Partial Conformance Claim to cater for these:

    A "statement of partial conformance" is made. A statement that the page does not conform, 
    but could conform if certain parts were removed can be made. The form of that statement 
    would be, "This page would conform to WCAG 2.0 at level X if the following parts from 
    uncontrolled sources were removed."                                       -- WCAG 2.0 (3) 

These changes from WCAG 1.0 are very significant and show a marked improvement in this version 
of the document. This documentation is much clearer than previously (the previously 
incomprehensible "web units" being replaced by the common-sense "web pages") and provided a 
very good shot at allowing WCAG 2.0 to function as a consistent, enforceable and 
technologically independent set of accessibility guidelines.

So, the quality and clarity of the documentation has improved -- for which I'd like to nominate 
the Working Group for a well deserved pat on the back -- but what about the Success Criteria 
themselves?


Principle 1: Making Content Perceivable

The perceivability guidelines and success criteria cover pretty much the areas you'd expect 
them to: text alternatives for non-text content, how to handle CAPTCHAs, which are "Completely 
Automated Public Turing tests to tell Computers and Humans Apart," and decorative images, as 
well as detailing the appropriate methods for handling live audio feeds, pre-recorded 
multimedia, identifying relationships and sequences, colour differences and so on.

There really isn't much in the way of surprises here: basically the guidelines that fall within 
this principle are all about ensuring that however you've structured and put together your 
content, the meaning of it can still be ascertained by someone with a disability.

It's important to note that while HTML validity is not specifically required -- but I'll come 
to that under Principles: Robustness -- the semantic use of HTML (or equivalent technology) 
is specifically identified:

    1.3.1 Info and Relationships: Information and relationships conveyed through 
    presentation can be programmatically determined or are available in text, and 
    notification of changes to these is available to user agents, including assistive 
    technologies. (Level A)                                                   -- WCAG 2.0 

    G115: Using semantic elements to mark up structure and H49: Using semantic markup to 
    mark emphasized or special text (HTML)                     -- WCAG 2.0 Quick Reference 

There you have it: one of the ways -- in fact the primarily recommended way -- in which to 
ensure that information and relationships conveyed through presentation can be 
programmatically determined is to use semantic coding in the first place. The techniques 
expand further, highlighting using list and heading markup properly, and so on.

It is therefore apparent that while validity may no longer be required (and trust me, I 
will get to that!), the semantic use of HTML is required, and is more specifically required 
than it ever was in WCAG 1.0, which -- although it too requires data tables to be marked up 
properly at level A -- does not require semantic use of elements such as lists and headers, 
or indeed form controls with associated labels until level AA.

In contrast with previous perceptions then -- including my own -- WCAG 2.0 is actually more 
stringent in it's requirements for semantic HTML than WCAG 1.0 ever was. Good for them.

One of the biggest weaknesses in WCAG 1.0 has also been addressed: WCAG 1.0 did not 
explicitly demand that text was resizable. In WCAG 2.0 from level AA you must be able to 
resize text between 50% and 200% without losing content or function.


Principle 2: Making Content Operable

As you might guess, the success criteria relating to operability all relate to interactions 
with the website -- what can you do with it now that you can perceive the content that is on 
there?

This can be boiled down to a series of questions:

    * Can you operate it with a keyboard?
    * Is the input time independent?
    * Can you switch off interruptions?
    * Do you avoid flashing/blinking?
    * You have got skip links, haven't you?

...and so on.

These are generally handled sensibly: time independence allows for exceptions where you're 
dealing with real-time events, or where time is essential such as time-based testing.

Skip links may be more problematical:

    2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are 
    repeated on multiple Web pages. (Level A)                 -- WCAG 2.0 Quick Reference (2) 

Joe Clark has already taken exception to this, pointing out that:

    You can put a few hundred navigation links on a single page and do nothing more, but 
    if you have two pages together that have three navigation links each, you must provide 
    a way to skip navigation.                           -- Joe Clark in "To Hell With WCAG 2" 

The Working Group accept this, but their Understanding WCAG 2.0 document makes it plain that 
the intent of this success criterion is to save people with particular disabilities from 
needing to step through headings, navigation, graphics etc on every individual page when 
they are simply seeking to locate the content.

Joe certainly makes a valid point here, because one page with hundreds of links would actually 
be more onerous that two pages each with three navigation links, but I think despite the fact 
that this success criterion isn't perfect and cases can be found that it misses, the fact 
that the majority of sites are constructed with repeating blocks of navigation means that 
this will serve a useful purpose.

In addition to this, this section of the document talks about things being meaningful -- pages 
should have meaningful titles (level A), descriptive labels (level AA) and the purpose of 
each link should be able to be determined from the link and its associated context (level A).

I seem to recall Joe Clark telling me that this shouldn't be necessary:

    There should be no requirement that links (or headings or honeybees or uranium deposits 
    or anything else) make sense when read out of context. They are not out of context 
    in the author's work and are not meant to be spontaneously remixed. Do not write 
    guidelines to suit kooky fun features of Jaws 
                                -- Joe Clark commenting on "Stuff WCAG, let's do it ourselves" 

Again, he has a very valid point. Why should we? My answer would be because some people will 
benefit from it. That's not a perfect answer, and it doesn't really get to the bottom of why 
we expect the pages to make sense when you chop them up and read them out of context, but 
it will get rid of those "click here" links that annoy me.

Yes, I know that "annoying me" doesn't directly relate to accessibility, but I personally 
am still glad they've said "To Hell With Click Here Links..."


Principle 3: Making Content Understandable

Understanding the content covers quite a lot of ground -- from the expansion of acronyms, 
abbreviations and initialisms -- and finally there's some common sense to stop the endless 
round of arguments over whether you should use <acronym> or <abbr> depending on how you 
pronounce the word in question:

    It is always appropriate to use the abbr element for any abbreviation, including 
    acronyms and initialisms. When using HTML 4.01, Extensible HyperText Markup Language 
   (XHTML) 1.0 or XHTML 1.1, initialisms and acronyms may be marked up using the 
    acronym element.                                              -- Techniques for WCAG 2.0 

Got it? Both methods provide an expansion, and that's the important bit. Use abbr to expand 
any abbreviation you like, and feel free to use acronym for any initialisms or 'true' acronyms.

The minor drawback is that in the examples provided, they define KISS (Keep is Simple Stupid) 
as an initialism, despite the fact it's pronounced as a word, and WWW (World Wide Web) as an 
acronym when no-one in their right minds would try to pronounce it as a word. Still, we'll 
forgive them that, eh?

They've kept language changes and default languages at levels A and AA but intriguingly have 
reversed the order between WCAG 1.0 and WCAG 2.0: now it is more important to specify the 
default language than it is to specify changes in language. I think this is a sensible move, 
although I would always advise marking up language changes appropriately anyway, regardless 
of what others would have you believe.

But one of the success criteria that I just know will floor some people is this:

    3.1.5 Reading Level: When text requires reading ability more advanced than the lower 
    secondary education level, supplemental content or an alternate version is available 
    that does not require reading ability more advanced than the lower secondary 
    education level. (Level AAA)                              -- WCAG 2.0 Quick Reference (3) 

It's not actually as bad as it sounds. This is meant to be a testable equivalent of:

    14.1 Use the clearest and simplest language appropriate for a site's content. 
                                                                     -- WCAG 1.0 Checkpoints 

Basically, what this means is that it should be understandable by someone who has had between 
six and nine years of schooling -- so in the UK as long as someone between the ages of 11 to 
14 could understand it, you're ok. If not, then what you'd be expected to do would be to 
provide additional help to make it easier to understand -- a summary, visual illustrations 
and so on.

This isn't a bad thing, and when you consider that you don't even need to worry about what 
constitutes "lower secondary education level" unless you're trying to achieve AAA Conformance, 
it's not something most sites will need to concern themselves with.

Other success criteria relating to this principle ask you to keep your navigation 
mechanisms consistent, help the user to detect and correct input errors, allow the user 
to check or reverse errors -- particularly in the case of legal or financial transactions -- 
and to provide context sensitive help if you can.


Principle 4: Making Content Robust

This is the shortest of the four principles, with not particularly that much identified in 
the way of 'robustness'. Indeed, robustness consists of just two success criteria: one 
saying that content implemented via markup languages should have complete start and end 
tags according to specification, and one saying that the name, role and state of user 
interface components should be programmatically determined and set where appropriate.

This "having complete start and end tags" is the latest incarnation of the success criterion 
which used to state that the document must be able to be "parsed unambiguously", which in turn 
was the nearest thing to "this document must validate" that WCAG 2.0 contains.

I was one of the people who raised an issue with this on the previous version of WCAG 2.0, 
saying that while I understood unambiguous parsing was the first step towards making content 
robust and was therefore suitable as a level A success criterion, to me it would make sense 
to strengthen this at level AA and require that documents were put together according to 
their specifications which is obviously where "validity" would come into play.

The Working Group rejected that, saying that they felt "validity" was going beyond the remit 
of "accessibility". I personally don't think validity goes any further beyond this remit 
than robustness does -- as robustness with future user agents has little to do with current 
accessibility, but does have a lot to do with validity.

However, despite my call to arms for validity, I was persuaded by their other arguments.

First they pointed out that while they were not mandating validity, it was the first of their 
recommended techniques for ensuring compliance with Success Criterion 4.1.1, which is the one 
about complete start and end tags. I have already pointed out that WCAG 2.0 requires semantics 
as part of 1.3.1, so these two success criteria go a long way already to give a good and 
proper use of HTML at Conformance Level A -- even if it doesn't have to validate.

Then, in answering my question about validity, the working group came up with a crucial factor 
as to why although they feel validity is useful (and therefore is a recommended technique), it 
cannot and should not be mandatory:

    It is also possible in certain situations to enhance accessibility through the use of 
    markup that is not part of the specification.                       -- WCAG Working Group 

I've seen people, ahem, embed invalid markup into their web pages in order to try and improve 
accessibility, and I would agree with the Working Group that making the content accessible is 
more important than having it validate.

I would have liked to see something along the lines of "it should validate except when you've 
done something to make it more accessible that means it doesn't validate any more", but given 
that they're trying to move away from overly long and incomprehensible success criteria, 
maybe it is just best to concede the point...

Yes, that's right: despite my vociferous campaign to include validity, I've been swayed by 
their arguments. Hopefully that demonstrates that it's not just the Working Group who are 
prepared to listen!


Summary

Last time I wrote about WCAG 2.0 for Accessites, I described it as a half-baked set of 
documentation that was of no use to anyone and required significant polishing. It's fair 
to say I was critical.

So what do I think now?

It's usable, it's a vast improvement on the previous draft, and it's an improvement on 
WCAG 1.0 as well.

Ok, it's not perfect, not by a long chalk -- it's significantly lacking in relation to 
cognitive disability for example, and I'd like to see this improved before the final 
release -- but it's still pretty damn good nonetheless. One of the things I particularly 
like about WCAG 2.0 in relation to WCAG 1.0 is that where WCAG 1.0 was focused on 
the technology:

    ...use stylesheets to control layout and presentation                          -- WCAG 1.0 

...WCAG 2.0 is focussed on the user:

    All functionality of the content is operable through a keyboard interface...   -- WCAG 2.0 

I was critical of WCAG 2.0 before, and it deserved that criticism. Now, I'm prepared to 
praise it, because it deserves that praise. They've done a bloody good job on WCAG 2.0 over 
the last year, and the people on the Working Group -- and those that submitted comments -- 
deserve the appropriate credit for all of the hard work that has gone into fixing this.

I don't say this lightly, but I think -- even with the known weakness regarding cognitive 
disability -- that WCAG 2.0 is now the best set of accessibility standards out there: it's 
clear, it's understandable, the focus is on the user, and finally, finally, it's ready.

Bring it on.

----

WaSP
    The Web Standards Project (WaSP) fights for standards that reduce the cost and 
    complexity of development while increasing the accessibility and long-term viability 
    of any site published on the Web. Learn more about WASP

----

Copyright (c) 2007, Accessites.org
http://accessites.org/site/2007/05/wcag2-woeful-to-wonderful-in-one-easy-draft/