Lately I’ve been doing a lot of accessibility training for web designers and developers, as well as the odd group of faculty. When I first started preparing for these training sessions, one of the challenges was to come up with a set of guidelines that make sense not only to people who live and breathe XHTML and CSS, but also to a much broader audience that may include department secretaries using a WYSIWYG editor like Dreamweaver to maintain a web site, non-technical faculty adding online content to the courses they teach, administrators who oversee web sites but don’t maintain them, and so on.

The W3C‘s Web Content Accessibility Guidelines 1.0 might make sense to web developers with a solid foundation in HTML and CSS, but face it: it’s a complicated document that relies heavily on several other associated documents. You have to be familiar with them all before any one of them makes sense.

The US Section 508 standards are okay, but they do ignore several important areas and rely too heavily on assistive technology. As a result, under Section 508 it’s considered acceptable to require JavaScript to access content, as evidenced by the training section of This is misguided and wrong.

I’m quite fond of the State of Illinois Web Accessibility Standards, and have in fact adopted them (with permission) as the basis of the guidelines that I drafted for work. I like the format in which guidelines are presented, and my experience with using this document in training has shown that it can be understood and used by a variety of people with different levels of knowledge about web standards, which is the point. So far so good.

The W3C has released another working draft of their Web Content Accessibility Guidelines 2.0. Even as a working draft, this is a much more accessible document than its first-version predecessor. It does not rely so heavily on a particular technology (HTML) and is geared more deliberately to a broader audience. “The overall goal,” the Guidelines state, “is to create Web content that is perceivable, operable, navigable, and understandable by the broadest possible rande of users and compatible with their wide range of assistive technologies, now and in the future.” The guidelines are then grouped under those five categories, with specific checkpoints and clearly defined benefits for each.

I like how version 2 is shaping up. It will, I think, prove to be a much more useful and broadly applicable set of guidelines than version 1. Now I have to start thinking of ways to incorporate elements of WCAG 2.0 into guidelines for work. Can’t wait until it’s released in its final form.