May 2007 WCAG 2.0 draftTuesday, May 29, 2007
The Web Content Accessibility Guidelines 2.0 draft is out (dated 17 May 2007). Thankfully the Working Group has backtracked from its Last Call last year owing to severe criticism of the document. In a lot of areas the document has improved, and in certain areas there's still a bit of work to be done.
The two things I liked about the previous version were the four principles (Perceivable, Operable, Usable and Robust), and the baseline concept. Of the four principles, three of them are user-centric, with the odd-one-out being a visionary-type principle. Baselines made sense - by allowing the choice of accessible technology. Accessibility suffered so long with the oppressive HTML only, the correction is a relief, and allows us to effectively tackle many disabilities that HTML is incapable of handling.
The four principles are there, but baselines have been replaced with "accessible supporting" which just sticks in the throat.
What is WCAG 2.0?
WCAG 2.0 provides requirements for making Web content more accessible to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, and others. Because many people develop vision, hearing, cognitive or motion impairments as they age, following these guidelines will make your Web content more usable by many older users. However, even content that completely conforms to WCAG may not be fully accessible to every person with a disability.
Again, it is clear. Web accessibility is about disability - a human-level difficulty. It's encouraging to see W3C recognise that as people get older and their eyesight degenerates, their movements are less precise, this is recognised as a form of disability that we need to seriously consider. You don't need to be certified disabled to suffer from it.
WCAG2 Success Criteria are meant to be testable. Some Success Criteria could perhaps be machine testable, others will require human testing. The Success Criteria are written in such a way that two accessibility assessors (who understand how people with different types of disabilities use the Web) should obtain the same results and conclusion with a high level of confidence.
Design impact of Web accessibility
The three levels of compliance are structured in terms of support of visitors using assistive technologies and the trade-off in presentation. Level A puts the fewest possible limits on presentation which improving the assistive technology support. Level AA does impose some presentation constraints for additional assistive technology benefits, and Level AAA places tighter constraints on presentation whilst providing additional benefits for the assistive technology user.
It's a sincere realistic approach that, yes, accessibility can place some presentational constraints on your websites.
Font resizing and horizontal scrolling
Level AA conformance encourages that fonts should be resizable between 50% and 200% without loss of content or functionality. At this conformance level horizontal scrolling is allowed, but not allowed at Level AAA. Again, this highlights the realistic and pragmatic approach of the Working Group.
Note: Being able to reduce the font-size does cater for a disability. People with reduced field of vision - like tunnel vision - can benefit, they can squeeze more content into their field of vision by reducing text size.
The replacement terminology for baselines is the awkward "accessibility supported". It's not an elegant reflection of its purpose, and less intuitive than baselines. Baselines were simple - a list of technologies used in building an accessible experience. Although "accessible supporting" probably does the same thing, it's not quite as clear. It is quite a waffle of text.
WCAG 2.0 makes it clear this is not a document for developers or designers. It is still an abstract document. A set of technology specific guidelines should emerge from this document - written by the W3C or independent parties. I strongly encourage the Flash accessibility gurus to get together and write up Flash accessibility guidelines based on WCAG 2.0 (when WCAG 2.0 is a full Recommendation), and not for Adobe to react. I'm sure your guidelines will be pragmatic, realistic and relevant to today's world.