A Contented course on WCAG 2.0 for content authors looked like a piece of cake at first—after all, the information is all readily available in 159,800 easy words. Why would that prove difficult?
We believe there's a need for a quick, practical course in WCAG 2.0 for government employees who—at least sometimes—write stuff that is published on a web site or intranet. For example, by the end of 2012, all Australian government web sites are required to comply with WCAG 2.0 to level A. And there's no way most web teams have time to tidy up accessibility in the truckloads of content now being published by staff.
So Contented has undertaken to write this course. And we will. As always, our course will be in plain language that non-technical government employees can understand.
But as you probably know, WCAG 2.0 has tried so hard to future-proof its guidelines that they are sometimes incomprehensible. Slightly weird terms are used that are intended to cover all possible technologies. While this goal may be laudable, the resulting generic terms are not plain language. For example, maybe browsers will be obsolete in 10 years time, so WCAG 2.0 tries not to mention them, and instead says something like this:
Success Criterion 4.1 Maximize compatibility with current and future user agents, including assistive technologies.
Our job is to:
- disentangle the sentence
- decipher the jargon
- figure the meaning
- deduce any implications for non-IT staff who produce web content
- translate the implications into plain language.
If this guideline means that web pages must be correctly and validly coded, it doesn't obviously affect most government content authors—for example, an HR manager publishing a procedure through a web content management system. However, it's appropriate to remind content authors to do a few relevant things that will make the web team's job simpler.
- They should use templates correctly, putting the right items in the right fields. (Some content authors are highly creative about the way they use templates, and that's bad for accessibility.)
- They should use WYSIWYG buttons very conservatively. (I'm assuming most content authors do not understand HTML.)
- If content authors are expected to enter metadata, they should do this correctly.
I was sad to see the previous WCAG 1.0 plain language guideline disappear, requiring 'the clearest and simplest language appropriate for a site's content.' (It's now an advisory technique, not critical to success.) Now, the only requirement is at the third highest level, AAA, a level of accessibility that is rarely expected and will virtually never be fully achieved. And it states:
When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.
That 41-word sentence, by the way, has a Flesch Reading Ease Score of 0.0, which means nobody—but nobody—would find it easy to read. Another test, the Flesch Kincaid Readability test, found you'd need 24.86 years of schooling to comprehend the sentence.
Strictly interpreted, this guideline is very odd.
- If a page was accidentally written in a style too obscure for its intended audience, that's OK, as long as you provide a second version that is easy for its intended audience. Example: voting instructions.
- If a page was deliberately written for readers at a high reading level, then you need to provide a second version that is easy for a 13-year-old to understand. Example: a research paper for astro-physicists.
Don't worry: we will succeed in writing a great course on WCAG 2.0 for content authors. We will interpret the guidelines in a commonsense way, and give thoroughly practical advice about compliance. Difficult things are usually more fun, we reckon. And you can find the full and authoritative version of WCAG 2.0 elsewhere.
That said, I must say this version is easier to comprehend than the first published WCAG 2.0. For example, Guideline 3.2 was heavy on abstract nouns:
Make the placement and functionality of content predictable.
Now, thank goodness, it's in plain English:
Make Web pages appear and operate in predictable ways.