After nearly a year of deliberation, the Australian government has finally decided to move from using Web Content Accessibility Guidelines 1.0 (WCAG 1.0) to WCAG 2.0 as the benchmark for website accessibility. On Wednesday February 24, The Australian Government Information Management Office (AGIMO) announced:

“Government agencies will transition to WCAG 2.0 over a four year period, reaching level Single A within two years, and Double A within four years. A Transition Strategy will outline the process for implementation, and will address scope and inclusion issues. The Transition Strategy will be made available on the Web Publishing Guide in July 2010.”

Almost immediately half truths and wild rumors began to circulate around the web. I heard a report of one developer saying, WCAG 2.0 Double A compliance was almost impossible because it meant that you had to meet over 700 checkpoints. This is incorrect.

And so, following a little prompting by friends, I decided to write this very brief overview of WCAG 2.0.

But first, although the announcement relates to government websites, it is extremely likely that the WCAG 2.0 requirements will extend to all web pages developed by organizations in Australia or placed on a web server in Australia.

Differences between WCAG 1.0 and WCAG 2.0

One major difference between WCAG 1.0 and WCAG 2.0 is that while WCAG 1.0 was primarily concerned with HTML, the WCAG 2.0 Guidelines and Success Criteria do not refer to HTML or any other web content technology.

Instead, WCAG 2.0 introduced the concept of “accessibility-support”. This means that for a web content technology (e.g. HTML, Flash, JavaScript etc) to qualify as accessible it must meet two basic requirements:

First, the way a particular web content technology is used must be supported by assistive technologies such as screen readers and switching devices.

Second, users must be able to obtain user agents (e.g. browsers and plugins) for the web content technology. These user agents have to have to be accessible and work with the assistive technologies, and the availability should not discriminate against people with disabilities.

WCAG 2.0 is not concerned with the technology used, but how you use it. However, this doesn’t mean you can use any technology you like. It is going to be up to authorities in Australia, probably AGIMO and the Australian Human Rights Commission, to decide which technologies they will consider accessibility-supported and under what circumstances. For example, will they decide to accept JavaScript, or PDF, or PDF forms as accessible formats? We may not get the answers to these questions until the Transition Strategy is released in July.

Structure of WCAG 2.0

The structure of WCAG 2.0 starts with four basic principles of web accessibility:

1. Perceivable – Information and user interface components must be presentable to users in ways they can perceive with at least one of their senses.
2. Operable – Users must be able to operate the interface and it can’t require interactions that the user can not perform.
3. Understandable – Users must be able to understand the information as well as the operation of the user interface.
4. Robust – Content must be robust enough so that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Within these four Principles there are 12 Guidelines and each Guideline contains a number of Success Criteria. All together, there are 61 Success Criteria and each Criterion is given one of three levels of conformance, A, AA or AAA. It should be noted, the WCAG 2.0 Success Criteria are not the same as the Checkpoints in WCAG 1.0.

WCAG Documents

The core W3C Web Content Accessibility Guidelines 2.0 is a “normative” document which contains the Principles, Guidelines and Success Criteria. These are basically the rules.

The Guidelines provide the requirements for making content more accessible to users with different disabilities, but in themselves are not really testable. Success Criteria, on the other hand, are designed to be testable, either by machines or humans, and are usually presented as testable statements. Success Criteria can be used for things like design specifications and for conformance testing to see if a site has satisfied contractual agreements.

The “normative” document containing Guidelines and Success Criteria is supported by “informative” documents, including Understanding WCAG 2.0 and How to Meet WCAG 2.0. The How to Meet document contains a number of suggested techniques for complying with each Success Criterion, but developers do not need to comply with all the suggested techniques, just those that are required to satisfy the Success Criterion. For example, when it comes to identifying a form input, you might use the ‘label’ element with the ‘for’ attribute (Technique H44) or a ‘title’ attribute for the input element (Technique H65) depending on the circumstances, but it is not likely you will use both.

It will be important for developers to understand the relationship between Principles, Guidelines and Success Criteria. But the How to Meet document is where you will find practical advice and many very useful examples about how to make things accessible.

WCAG 2.0 Conformance Requirements

The W3C provides five Conformance Requirements that must be met in order for content to be classified as ‘conforming’ to WCAG 2.

1. All the information or content on a page must meet one of the Success Criteria levels. For example, is it Level A or Level AA? Or has an appropriate complying alternative been provided. NB: No conformance is possible if all the content does not fully satisfy Level A
2. The whole page has to comply. You can’t just exclude the parts of a page that might have content that doesn’t comply. However, you can use non-complying content so long as an alternative is provided and it doesn’t interfere with the page (see point 5).
3. Where a page is part of a process, e.g. purchasing a ticket, all pages or steps in the process must conform at the specified Success Criterion Level.
4. Only “accessibility supported ways of using technologies” can be relied on and where this is not possible an alternative that is accessibility supported should be provided.
5. Technologies that are not accessibility supported can be used, as long as all the information is also available using technologies that are supported AND the non-accessibility-supported material on the page does not interfere with the ability of users to use the rest of the page, for example it doesn’t trap the cursor, or users can control audio content.

WCAG 2.0 – No Need to Panic

Finally, although the WCAG 2.0 documents contain a lot of words, which some might find a little confusing, and there are a few new requirements, most experienced web developers won’t find moving from WCAG 1 to WCAG 2 difficult. Furthermore, WCAG 2 offers greater flexibility and some real benefits for designers and developers, for example a more practical approach to the use of colours and the mark-up of forms.

More information:

WCAG 2.0 Guidelines (W3C)
http://www.w3.org/WAI/GL/WCAG20/

Understanding Accessibility Support (WAI)

WCAG 2.0 and Accessibility Supported (Roger Hudson)

Comparison of WCAG 1.0 Checkpoints to WCAG 2.0 (WAI)

Migrating from WCAG 1.0 to WCAG 2.0 (WIPA/Roger Hudson)

NOTE: I will be looking at how to comply with the key Single A and Double A Success Criteria during the WCAG 2.0 in Depth workshops in April and May.