Is WCAG too long?

Yes.

And no.

But mostly it just feels that way.

I just got home from this year’s CSUN Conference and, as always, it was a wonderful time. Like many people, I find myself feeling very energized. The overall feeling of camaraderie at CSUN leaves you feeling like you have an army standing behind you as you venture forth to make the world more accessible. One thing bothers me a bit about this year’s CSUN that’s lead to this post.

On Friday, Billy Gregory and I presented Why WCAG? Whose Guideline is it, Anyway? with The Viking and The Lumberjack. This talk focused on some humorous criticisms we have of WCAG and how people – primarily those who are not experts – can be tripped up by WCAG. Like everything we do, Billy and I attempted to use humor to help clear up some of these points of confusion. The talk was standing-room only and was well-received by the audience. But that didn’t stop some people from objecting to what we had to say.

After Cordelia Dillon put out the above tweet, she was quickly “corrected” by David MacDonald to clarify that WCAG was only 36 pages. Regardless of the accuracy of Cordelia’s tweet, this marked the 2nd time that David MacDonald has chosen to comment on the substance of this talk despite having not been in attendance. Whether or not the “Normative” portion of WCAG is 36 pages or not, David lacked the context necessary to understand what was being said. More importantly, David’s knee-jerk reaction is even more ridiculous when you consider that the Viking & the Lumberjack are very definitely not the first people to make this observation and David knows it. Public criticisms on WCAG’s length have happened since 2006 – 2 years before WCAG reached final recommendation status. I’m not about to get into the history and drama of the WCAG Working Group prior to 2.0’s release because it isn’t relevant to this discussion, but suffice it to say that this had been a topic of discussion prior to Joe Clark’s ranticle on ALA.

It isn’t (just) the length, it is the density

David is correct in saying that the normative information – the actual standard – of WCAG 2.0 is only 36 pages long. Regardless of whether or not the standard itself is only 36 pages, people tend to lump the associated materials into what they collectively refer to as WCAG. In other words, it is an exercise in pedantry to correct people who claim WCAG is too long because the actual standard is only 36 pages. What people refer to as WCAG also includes the informative portions. How to Meet WCAG 2.0 is 44 pages, Understanding WCAG 2.0 is 230 pages, and the Techniques and Failures for WCAG 2.0 is 780 pages. In full disclosure this makes our claim at our presentation to be far higher than reality. What we wanted to convey however is that it feels immense.

The writing style of the actual WCAG Recommendation needs to be written the way it is. Every word of a document like WCAG is important. Every word and phrase has a specific meaning. Because WCAG has been adopted as an ISO standard and because WCAG is (or will be) incorporated into a number of regulations throughout the world, the wording must be explicit and detailed regarding the requirements for conformance. But the informative content, such as that within “How to meet WCAG 2.0” has no such requirement. Despite this, the How to meet… document has an overall grade level of 9.6 and the Understanding… document has an overall grade level of 10.7. Individual entries in the “Understanding…” documents hover around a grade level of 10. The document that discusses Understanding techniques has a grade level of 12!. Clearly, the writing style of the informative content does not help when it comes to peoples’ perception of the content’s length. Also, there’s ample opportunity for people to say, “WTF WCAG”:

Creating components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes. (G10)

I know what this means. But I’ve been professionally involved in accessibility for more than a decade. You could say that I know enough about accessibility that I don’t need to read the above technique to know what it means to conform to SC 4.1.2. The above technique title is simply not any more easy for the layperson to parse than the Success Criterion itself! I admit, this is a particularly bad case. Some of the other technique titles are short and clear. But G10 has plenty of friends, like this one.

The Presentation Doesn’t Help

There’s really no nice way to say this. The WAI site and their deliverables are not attractive. They are mostly just walls of text that exacerbate the content’s readability problems. Recent changes, such as the redesigned Quick Reference are huge steps forward, but the vast amount of pre-existing information presented in typical W3C-wall-of-text-standard-document format does not do this information any favors. The current list of WCAG WG members contains a number of participants with extensive UX experience. The WAI should leverage these resources to work on redesigning the presentation of informative materials to make them easier to navigate and understand by the layperson.

Do I think WCAG is too long?

Not really. I think the writing style and presentation of the associated materials makes WCAG feel too long. I think that the WCAG Working Group should be commended for recent redesigns of some supporting materials and they should continue these efforts. In addition, I think they should strongly consider adopting well-established plain language practices when authoring or revising their materials. This is especially true when it comes to the "How to meet…" and "Understanding…" documents which are often sorely needed by those who are new to accessibility. These steps should help alleviate some of the many well-founded criticisms of the content’s length.

If you are interested in learning about the next generation in Web Accessibility Testing, give Tenon.io a try.
If you or your organization need help with accessibility consulting, strategy, or accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343. Download Resume [MS Word]