The W3C has ratified a new 2.0 version of the Web Content Accessibility Guidelines (WCAG). The version WCAG 1.0 has been around since 1999 and had 3 levels A, AA and AAA to cover off different levels of conformance, with most organizations going for AA. There have been a whole heap of improvements to the new 2.0 version, which keeps the A, AA and AAA levels.
There were a number of criticisms of the 1.0 standard, the main ones being that many of the requirements could not be tested automatically, but required human evaluation. For a development team, this is really disruptive. They want binary choices; human evaluation is very frustrating. The other main criticism was that scripting was not allowed. This was a fair choice back in 1999 as many tools did not support scripting, but in the last 5 years this single rule has caused many issues.
This official W3C presentation takes you through the benefits of WCAG 2.0 and differences between the 2.0 and 1.0 versions. I have summarized some of the key differences below.
More testable criteria. As many of the new rules are testable as possible. For example, to contrast an old rule against its new version:
- 2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits…
- 1.4.3 Text (and images of text) have a contrast ratio of at least 5:1…
The old 2.2 version of the rule required someone to make a decision, and to be honest no-one on the development team is qualified to make that decision unless they have experience in this area. The new 1.4.3 rule, now that can be tested.
Written to apply to future technologies. The standard has been written to be broadly applicable and technology-independent. It does not prescribe how to do things, but rather what functionality is needed. The formal standard (which will not change) is supported by ‘Technique’ documents that describe how to meet the standard for a specific technology. These documents can be updated over time, and added to as new technologies come online.
More flexible requirements. The old criteria were very limiting. For example with things like blinking or flashing on a page which were restricted, these are now allowed within specific parameters. For example ‘Content does not contain anything that flashes more than three times in any one second period’
Scripting allowed. Not only is it allowed, in some cases it is encouraged! These include things such as client-side validation, using the DOM to add content dynamically, programmatically identify required form fields. There is also related to work being developed with the Accessible Rich Internet Applications Suite (WAI-ARIA) to give information on active user interface controls such as menus and tree controls.
Flexibility for different situations. If you are developing a public internet site, you cannot use certain technologies as people do not have user agents (browsers, screen readers etc) that support them. However, if you are creating an internal site and the company provides all employees with accessible user agents that support that technology, then you are conforming to WCAG 2.0
Extensive Supporting Materials and practice implementation guidance. For each guideline it should explain the intent, success criteria, how it helps, examples, related resources and how to test.
Having worked with the WCAG 1.0 before, which was not a great experience, this new version looks like a huge advancement that was long overdue. For me, one of main points is around more testable requirements – if we can automate tests, we can automate the developer tools that create the web content to adhere to them and start create accessible web sites by default rather than by exception.