WCAG 2 Test Drive
12th December 2008 by Liam McGee
WCAG2.0 has arrived! The bouncing baby new de facto accessibility standard arrived into the world yesterday – December the 11th, 2008.
Being the accessibility obsessives we are, we eagerly tore open the metaphorical wrapping paper and started to play with it without reading the instructions. Unlike previous versions released, this is the stable standard and can be referenced with confidence. It’s not going to change again for a long time.
So, first impressions… I’m very pleased to see how thoroughly and extensively the W3C have consulted with the web community about this document – I was also pleased at how the contributions from developers (like us) and ordinary users (like lots of people we know) have been integrated and treated with as much care and respect as if they had come from Microsoft or Mozilla. This is not imposed from on high, this has emerged, flower-like from the contributions of the community as a whole. As a concrete example, we thought the previous ‘beta’ version was not the easiest to read. So we suggested an alternative. They responded with some thoughtful and constructive criticism, which we acted on, and then the improvements to the styling were gracefully implemented. A second example. I wrote in at one point a few months ago querying one of the requirements that asked for ‘liquid’ site designs. I disagreed. One of the team working on the document responded, disagreed right back, but very gracefully, and I amended my criticism to take into account some of the good arguments they raised. The result? The language around that checkpoint is now clearer takes into account my concerns. Again, I am very impressed by the development process.
WCAG2.0 is best thought of as a set of 4 mutually supporting documents – the first is main WCAG 2.0 document, containing the guidelines in a form that would be useful for technical specification, legal requirements etc. The second is the Understanding Wcag2.0 document, which goes into more detail about each checkpoint. It explains, in fairly straightforward language, the intended effect of the checkpoint, the benefits of implementing it, and gives some concrete example situations in which it should be applied. When you consider what was available for WCAG1.0, the improvement is immense, especially when considered alongside the Techniques document that gives more examples including mark-up to support them. One tiny niggle is that the styling breaks down slightly in Google Chrome, but this will doubtless soon be resolved.
The piece de resistance is undoubtably the customisable quick reference, billed as a ‘a key resource for designers and developers using WCAG 2.0′. I have to agree . This is a shorthand set of all guidelines and references that can be customised to display only those that apply to you site. If you aren’t using any rich internet apps (RIAs) then just switch off the WAI-ARIA applicable guidance. Couldn’t care less about SMIL? Then strip those references out with the click of a mouse. Or, this being WCAG, the prod of a key. Or the wave of a head-wand. Improvements could be made – for example, I’d like to kill all audio/video references if I’m not using them, but otherwise, a great effort.
A valiant attempt has been made at WCAG2.0 Documents to show how they fit together.
All very well, you may say, but what is it like to use in practice? I threw it at a wireframe I was building, and it was very interesting. Firstly, it’s less prescriptive… and the result is that it makes you think more. Techniques are referred to as ‘sufficient’ – in other words, you could meet the success criterion by doing this, but if you can come up with a better way? Why, go right ahead. There’s enough information there about the intent and benefits of meeting that criterion that allows you to make a clear cut decision about whether your alternative method is a reasonable substitute.
The AAA guidelines – always a contentious subject in WCAG1 (did anyone ever use access keys without messing up the functionality for some users, somewhere?), are far more sensible. For example,
Contrast (Enhanced):
1.4.6 The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following:Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;
Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
Firstly, this is very easy to see whether you have passed or failed. Secondly, it’s a similar but stricter version of the AA requirement. Thirdly, it gives you a get-out clause for branding/logos. If part of the brand value is ‘extremely subtle’, then you can keep that pale grey on white logo. But that body text had better be readable.
All in all, looks great. I look forward to applying it to many projects to come.
Want any help with getting that site to WCAG2.0 compliance? Give Communis a ring on +44 (0)1373 836 476.
[Technorati Profile]