I spoke at a Public Sector Forums event on the 15th August on WCAG 2.0. I promised to various people that I’d make my speaker notes available online, so here they are. This is based on the second draft of my speaker notes, which is a slightly longer than the final version and obviously may differ slightly from what I actually said. I believe Public Sector Forums are going to make the slides available on their own site, so if you’re after my slides keep an eye out over there.

Destinations

Our destinations on this whistle-stop tour are as follows:

1. What is WCAG 2?
2. What’s new in WCAG 2?
3. Reaction to WCAG 2
4. Applying WCAG 2
5. WCAG 2 and the Public Sector

What is WCAG 2.0?

This is the Web Content Accessibility Guidelines which are produced by the Web Accessibility Initiative of the World Wide Web Consortium. The WCAG 1.0 was given formal recommendation status by the W3C in 1999 and is a recognised international standard.

Version 2.0 of is currently in Last Call status which means that it is still in draft so may undergo further changes, but equally it is not expected that there will be many significant changes to it. This draft was produced in April 2006, five months after the previous version, and given the amount of comments it has generated, it seems unlikely that it will reach the recommendation status before 2007.

WCAG 2.0 consists of three main documents: the guidelines themselves, the techniques document and the “understanding WCAG 2.0″ document, which total more than 150,000 words in length. As has been noted elsewhere, this is a lot of documentation to try and get your head around.

What’s new in WCAG 2.0

There are a number of significant changes:

• technological independence
• success criteria and success levels, not checkpoints and priority levels
• principles
• baselines
• conformance claims

Technological Independence

The first set of guidelines focussed primarily on the use of HTML to deliver web content. In fact, not only was it assumed that you would be using HTML and CSS to deliver web content, but you were specifically instructed to do so:

Priority 2 checkpoint:
11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.WCAG 1.0

In contrast, while the main goal of the WCAG 2.0 guidelines is to make web content accessible to disabilities, the next goal listed by the Requirements document is technological independence:

WCAG 2.0 requirements should be expressed in generic terms so that they may apply to more than one markup language or content format.WCAG 2.0 Requirements

The obvious advantage of this is that it means the document is less likely to quickly become dated in the event of new technological developments — the same principles will be expected to apply to them also. On the other hand, the obvious disadvantage is that by insisting everything is couched in technologically independent language, you’ve got to define a lot of new terms such as “web unit” and “authored component” and it’s not always so easy to follow:

2.4.6 When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content.WCAG 2.0

Success Criteria and Success Levels

In WCAG 1.0, different checkpoints were loosely grouped in different Priority Levels, with Priority 1 representing the most important checkpoints and Priority 3 the least.

The advantage of these checkpoints and this priority system was that they were very clear and understandable, and looking at the conformance level claimed — from Single-A if all Priority 1 checkpoints were met, up to Triple-A, with all priority 1,2 and 3 checkpoints met — would give you a good overall indication of the level of accessibility of the site.

Unfortunately, it’s not quite so straightforward with WCAG 2.0.

The Priorities and Checkpoints have been replaced by Levels and Success Criteria. The document makes it plain that part of the reason for doing this was that:

Each checkpoint in WCAG 1.0 was assigned a “priority” according to its impact on accessibility. Thus, Priority 3 checkpoints appeared to be less important than Priority 1 checkpoints. The WCAG Working Group believes that all success criteria of WCAG 2.0 are essential for some people.Conformance with WCAG 2.0

So, this seems to me to suggest that the organisation of the Success Levels isn’t about the importance of the success criteria. So what exactly is it about?

Well, apparently:

Level 1 success criteria:

• Achieve a minimum level of accessibility
• Can reasonably be applied to all Web content

Level 2 success criteria

• Achieve an enhanced level of accessibility
• Can reasonably be applied to all Web content

Level 3 success criteria

• Achieve additional accessibility enhancements
• Can not necessarily be applied to all Web content

Conformance with WCAG 2.0

This seems to be very much tying in with a level of importance to me; in fact, apart from the idea that level 3 success criteria don’t necessarily apply to all web content, it looks very similar indeed to the Priority Levels used in WCAG 1.0:

[Priority 1] — A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document…

[Priority 2] — A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document…

WCAG 1.0

So, so far as I can tell, Success Levels equals Priority Levels and Success Criteria equals checkpoints, despite what the W3C are claiming to the contrary.

Principles

WCAG 2.0 is built around four POUR principles

1. Content must be Perceivable
2. Interface components in the content must be Operable
3. Content and controls must be Understandable
4. Content should be Robust enough to work with current and future user agents (including assistive technologies)

The base WCAG document is structured very much around these four principles; each principle contains a number of guidelines to enable to help you conform to it and each guidelines contains a number of success criteria so you can test against it, for example:

• Principle 1: Content must be Perceivable
  • Guideline 1.4: Make it easy to distinguish foreground information from its background
    • Success Criterion 1.4.1 (Level 2): Text, or diagrams, and their background, have a luminosity content ratio of at least 5:1

Baselines

The concept of the baseline is one of the bigger changes in WCAG 2.0. When producing a Conformance claim, you have to list the technologies that need to be supported by someone wanting to use your site; and you’re claiming WCAG 2.0 compliance assuming that those technologies are used.

The baseline cannot be browser or user agent specific: You can say the baseline requires XHTML 1.1; you can’t say it requires Internet Explorer 6.0.

You can use technologies that you have not declared in your baseline, provided that your website still conforms to WCAG 2.0 at the stated level, even if this technology is not supported.

Conformance Claims

Under WCAG 1.0, it was incredibly simple to show that your site was accessible to a particular conformance level. You simply ran it through Bobby or Cynthia Says, and stuck the appropriate logo on your website. Yes?

No. Unfortunately, while automated testing is useful for highlighting errors in your site, there are only a handful of the 65 checkpoints in WCAG 1.0 that could be fully tested by automated tools, and so some degree of manual checking would always be required to ensure conformance. But we all knew that anyway, didn’t we?

Still, at least once you’d done all that, you could stick a WCAG-AA logo on the bottom of your site and everyone would be happy.

Unfortunately, under WCAG 2.0 it’s no longer that easy: you have to provide a full conformance claim.

Your conformance claim must contain :

• The date of the claim
• The guidelines title and version
• The URL of the guidelines used
• Your baseline
• The scope of the claim (this page, these pages, whole site)

As if that’s not enough to be going on with, the W3C also suggest that you might (it’s optional) like to include some of the following:

• Any additional success criteria satisfied beyond your conformance level
• A list of technologies that are used but not relied upon (and therefore not in your baseline)
• A list of user agents tested on, which should include assistive technologies
• Information about the target audience (i.e. language or geographic information; must NOT be related to disability, or physical, sensory or cognitive requirements)

This is obviously starting to get somewhat burdensome, and in many cases may result in a very technical claim that isn’t necessarily understandable by the audience.

In my personal site’s claim, I’ve tried to incorporate as much of possible of what has been said while still trying to lean towards the “Plain English” side of things:

This site has been designed to comply with WCAG 2.0 level AAA, and relies on XHTML technology being supported by your browser. The site also uses css, javascript, png, jpeg and gif images but your browser does not need to support these. The site has been tested using Internet Explorer, Opera and Mozilla Firefox running on Windows XP although Browsercam has been used to test pages on other browsers and platforms.My conformance claim

I also add information on which part of my site I’m claiming conformance for and when the claim was made. You may also notice that I’ve claimed the triple-A level of accessibility, which was almost impossible to achieve under the old guidelines. This is where the good news comes in.

In order to achieve triple-A accessibility, you no longer have to pass every single checkpoint or success criterion. You still need to pass all of the Level 1 and Level 2 criteria, but you only need to pass half of the Level 3 success criteria that are applicable to your site.

In short, the Holy Grail of Triple-A compliance is now in reach, if you’re willing to go an extra mile.

WCAG 2.0 Reaction

The reaction to WCAG 2.0 has tended to range between the lukewarm and the outright hostile. It would take all day rather than just a segment of a 25 minute slot to cover everything point by point, so I’ll just try and give you a flavour of the reaction by focussing on what a few people said.

Bruce Lawson

Bruce thought that it was:

…simply too long…Bruce Lawson

…and that it was:

…too much to learn while you simultaneously grapple with CSS, PHP, JavaScript…Bruce Lawson

Nor did he think that it was particularly easy to understand, suggesting that:

…you need an Olympic Gold in completing cryptic crosswords to understand what that really means…Bruce Lawson

On the actual success criteria themselves, his biggest bugbears seemed to the fact that tables were still allowed:

Tables. Still not deprecated off to the glue factoryBruce Lawson

…the whole practice of using tables for layout should be illegal under WCAGBruce Lawson

Nor was he impressed that validation was no longer required:

…I’ve always said, to make accessible pages most of the battle is semantic, valid code. Bruce Lawson

And that while the ideal of making the guidelines technology neutral is very noble, the execution was flawed:

By trying to make it future-proof, the message is hidden.Bruce Lawson

Joe Clark

Joe Clark wrote an article for the online magazine A List Apart called To Hell With WCAG 2, in which he picked out a number of the things he wasn’t so keen on; for example the ability to scope your conformance claim to only certain parts of your site:

You’ll be able to define entire directories of your site as off-limits to accessibility (including, in WCAG 2’s own example, all your freestanding videos).Joe Clark

He also felt it was the terminology used was part of the problem, highlighting:

programmatically determined

determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities

WCAG 2

and quite sensibly asking:

Can you translate any of these terms into words that every reader of this article understands, like “page”, “site”, “valid”, “well-formed”, or “template”?Joe Clark

In fact, he goes on to makes the claim that because you never have to have valid HTML in WCAG 2.0 compliant sites…

It’s as if web standards never existedJoe Clark

Okay, so Joe obviously has some issues with WCAG 2.0. That doesn’t means he thinks it is irreparable, but he’s not convinced that the Working Group are the ones who will be able to fix it:

WCAG 2 is not too broken to fix, but we have no reason to think the WCAG Working Group will actually fix it. The Working Group is too compromised by corporate interests, too wedded to the conclusions we see in the current “draft”, too broken in general.Joe Clark

It’s fair to say he’s not been wonderfully impressed with it to date.

Lisa Seeman

Lisa raised a formal objection to WCAG 2.0 which has been countersigned by a number of people, claiming that it does not address cognitive disabilities in its current form and therefore it should not claim to be doing so:

WCAG 2.0 claims to define and address the requirements for making Web content accessible to people with learning difficulties, cognitive limitations and others. We object to that claim. Specifically, the requirements for making content understandable ignore the needs of people with learning difficulties and cognitive limitationsLisa Seeman

This point has been echoed elsewhere, with Gian Sampson-Wild, who has actually been involved in the production of WCAG 2.0 saying that one of the biggest problems she has with it is that where WCAG 1.0 has 21 checkpoints which relate to cognitive disability, only 10 of these have made it through to WCAG 2.0.

Plainly, WCAG 2.0 simply does not adequately address cognitive disability as it currently stands.

Mine

Aside: the powerpoint slides included an image at this point of a sign Joe Clark had seen with “flamer Jacks” written on it. Thanks again to Joe Clark for allowing me the use of the photo and indeed my gratitude to him for that WCAG 2.0 article in the first place, which finally acted as a kick up the backside to me that it really was about time I got round to reading up on it.

Personally, I feel that the neutrality of the success criteria has seen them made toothless and incapable of matching up to the guidelines that they are meant to enforce. Just look at this:

Guideline 1.3 : Ensure that information and structure can be separated from presentationWCAG 2.0

Now, this seems to me to directly relate back to some WCAG 1.0 checkpoints – telling you to use stylesheets to control layout and presentation, telling you not to use layout tables, and telling you to make sure nothing is reliant on colour alone. Yeah?

Unfortunately, the colour alone is the only one that’s made it through to WCAG 2.0. You can use font and align elements which were deprecated in HTML 4.01 nine years ago, tieing your presentation in to your information and structure, and yet somehow still pass all of the success criteria relating to the guideline that specifically tells you to “ensure that information and structure can be separated from presentation”. And this is meant to be a step forward?

Or we can look at guideline 1.4:

Guideline 1.4: make it easy to distinguish foreground information from it’s backgroundWCAG 2.0

…for which the currently non-existent technique “using readable fonts” is only ever going to be an advisory technique. How exactly are you going to be able to distinguish the foreground information if the font isn’t readable?

Toothless, I tell you, toothless…

I also noted — and informed the working group — that 19 people had added comments relating to validity, of which 18 people believed validity should be reincluded as either a level 1 or a level 2 success criterion. When you ask for public feedback, and 94% of the comments you get on a particular issue agree, I don’t think you can really ask for a clearer response than that. As the working group specifically asked for comments, I hope they will be prepared to take note of them. But we’ll have to wait and see.

Other comments

A chap called Alastair Campbell — probably not the PM’s ex-press secretary — has expressed concern that there’s nothing in the guidelines which tells you to use relative sizes for fonts, as this better allows font scaling particularly on IE for people with mild to moderate vision impairments.

But not all comments that have been posted to the comments archive are negative: some people are keen to offer telecommunications advice to the W3C, advising them where they can get:

the best free Samsung ringtones, Cingular ringtones and more, Ringtones for free!

It’s reassuring to know that spammers take accessibility seriously, too.

Drawing a line under this, let’s hope the W3C take some note of the more serious comments and address these issues before the final Recommendation. Otherwise I’m sure there will be further reactions…

Applying WCAG 2.0 as it currently stands

Okay, so the first step is to ignore all the things that we want changed about it and look at it as it is, because that’s our exercise for today.

Step 2 is to look at our baseline, assuming that this isn’t being set for us by the Government or the EU. Think about the site and decide what technologies were using, in order to make up the baseline. Chances are HTML or XHTML is going to be in there. Now comes the tricky questions: the other technologies only need to form part of our baseline if you cannot use the site without them. If you provide an alternate to images, they don’t have to be in your baseline. If your site works fine without CSS enabled, that doesn’t have to be in your baseline.

Do you provide PDFs? Word format files? RTF files? If so, is the information in these also provided in something that’s in your baselines, such as HTML files? If not, these need to be added to your baseline recipe.

And now the baseline questions get a little trickier. Do you use javascript? Does the site still work if javascript isn’t supported at all? What if it’s partially supported? If you rely on javascript for key functionality, it has to be in the baseline.

And multimedia. Again, if the entire information content of your multimedia is represented elsewhere by a technology already in your baseline, then you don’t need to include it. Otherwise all of these file types need to go into our pot as well.

Simmer gently for fifteen minutes on a low heat and then look at the WCAG recipe book.

Yes, the W3C have produced a concise, helpful and easy to understand document that is by far the most useful document in the set and proves invaluable here. They, and Gez Lemon of JuicyStudio, I’ll repeat that: Gez Lemon of JuicyStudio, who provided the initial coding deserve due credit and I applaud them here. It is called the WCAG 2.0 Quick Reference document and it’s bloody useful.

Simply hit the ticky boxes to indicate which features you use and are incorporated into your baseline, which you use but don’t rely on, which conformance level you’re aiming for, and then work your way through the document. It will now be showing you which success criteria are relevant to your site, which techniques you can use to ensure that your site complies with the appropriate success criteria and even showing you common failures against those criteria.

So what now? Well, as before we need to check through the tests.

Find an automated checker to run through the bulk of your pages and tick off any checks it can make. I’m only aware of one checker that currently tests against WCAG 2.0, which is the ATRC checker from the University of Toronto, although I’m sure that by the time WCAG 2.0 has become a formal recommendation other checking engines will have been developed.

As before, remember that you can’t check everything automatically, so you’ll need to get on with manually testing your site. The best way to do this would be to bring in some people with disabilities to carry out your testing. You’ll need to do this anyway — I’ll explain why later — so if involving “real people” in your testing has been anathema to you in the past, you might as well get used to the idea now.

Okay, so that’s a lot of pages, but the W3C suggest there’s no need to initially go through everything you’ve already done – which should be conforming to WCAG 1.0 anyway; just set your conformance claim to indicate that content added or amended after date X conforms to WCAG 2.0, with pages earlier than that conforming to WCAG 1.0 and then you don’t need to wade through a huge backlog of existing pages.

WCAG 2.0 and the public sector

I’ve discussed WCAG 2.0 with Tom Adams from the Cabinet Office, and I put a number of questions to him about what WCAG 2.0 meant for us in the public sector. I can summarise these neatly with my first question:

What do we need to do for WCAG 2?

Nowt (yet)

But I’ll expand on this a little:

When will the public sector be expected to comply with WCAG 2.0?

Tom currently believes WCAG 2.0 to be a large, unclear document that would lead to great practical difficulties if it was implemented as a standard before these issues were resolved. It is likely that even after WCAG 2.0 has resolved its problems that it will be expected to run in parallel with WCAG 1.0 for some years, alongside an information campaign to show how to map WCAG 1.0 to WCAG 2.0.

Furthermore, in the UK we are following the EU line on web accessibility, which means that we’ll be following the line set by the Ministerial declaration from the eInclusion conference in June, stating that we should be promoting inclusive eGovernment by:

ensuring accessibility of all public web sites by 2010, through compliance with the relevant W3C common web accessibility standards and guidelines.Riga declaration

It’s unlikely that UK public sector sites would be asked to take a different tack to the EU policy, which means we’re likely to formally adopt WCAG 2.0 as a standard only when the EU does so, although the Riga declaration does not directly reference a specific version of the W3C guidelines.

Will the government set baselines?

It was felt that this isn’t necessarily as straight forward a question as it sounds and is likely to be the subject of much debate. However, if we were to adopt WCAG 2.0 as a standard, it would be a logical progression to provide a baseline – or series of baselines – against which this standard could be measured, and that without providing a standard baseline implementation would be chaotic at best.

Should a public sector organisation switch to using WCAG 2.0 early?

No. There’s no reason not to carry out parallel testing with WCAG 2.0 for internal use and study, but Tom believes that WCAG 1.0 at level AA should continue to be used as the core public sector objective until such time as WCAG 2.0 has been formally adopted for the public sector and the issue of baselines has been clarified.

So what should we be doing?

Adhere to WCAG 1.0 level AA. But we shouldn’t stop there.

Our job is not simply to meet a given standard, it’s to supply good quality public sector sites that are as accessible and as easy to use as possible. As we’ve just heard, this means going beyond that which is stated by the guidelines. These points are spelled out for us in more detail by PAS78 and the Disability Equality Duty, which is part of the Disability Discrimination Act.

If you’re already following the PAS78 guide to Good Practice in Commissioning Accessible websites, you’ll be involving disabled people in the requirements gathering process, in the process of defining the accessibility policy for your website and in testing the website against this on an ongoing basis.

This dovetails neatly with the Disability Equality Duty which you might want to comply with — particularly since it’s a legal requirement. This means that you have a duty to promote equality of opportunity, eliminate unlawful disability related discrimination and harassment, promote positive attitudes towards disabled people and encourage participation by disabled people. Indeed, as I’ve said elsewhere, you’re now legally obliged to do exactly what you should have been doing in the first place.

In your Disability Equality Scheme, which needs to be published by December, you’ll need to show how you have involved people with disabilities in key stakeholders in the production of your scheme and produced your action plan.

In short, work with users with disabilities and disability groups to ensure that your sites meet WCAG 1.0 AA as a minimum standard that you are seeking to exceed; ensure that you are continually testing your sites against your standard and that you are continually revising and updating your policies to improve access.

And that’s it!

<span lang="fr">Fin<span>