WCAG 2.0: Woeful to Wonderful in One Easy Draft?
Principle 3: Making Content Understandable
Understanding the content covers quite a lot of ground — from the expansion of acronyms, abbreviations and initialisms — and finally there’s some common sense to stop the endless round of arguments over whether you should use <acronym> or <abbr> depending on how you pronounce the word in question:
It is always appropriate to use the
abbrelement for any abbreviation, including acronyms and initialisms. When using HTML 4.01, Extensible HyperText Markup Language (XHTML) 1.0 or XHTML 1.1, initialisms and acronyms may be marked up using theacronymelement. — Techniques for WCAG 2.0
Got it? Both methods provide an expansion, and that’s the important bit. Use abbr to expand any abbreviation you like, and feel free to use acronym for any initialisms or ‘true’ acronyms.
The minor drawback is that in the examples provided, they define KISS (Keep is Simple Stupid) as an initialism, despite the fact it’s pronounced as a word, and WWW (World Wide Web) as an acronym when no-one in their right minds would try to pronounce it as a word. Still, we’ll forgive them that, eh?
They’ve kept language changes and default languages at levels A and AA but intriguingly have reversed the order between WCAG 1.0 and WCAG 2.0: now it is more important to specify the default language than it is to specify changes in language. I think this is a sensible move, although I would always advise marking up language changes appropriately anyway, regardless of what others would have you believe.
But one of the success criteria that I just know will floor some people is this:
3.1.5 Reading Level: When text requires reading ability more advanced than the lower secondary education level, supplemental content or an alternate version is available that does not require reading ability more advanced than the lower secondary education level. (Level AAA) — WCAG 2.0 Quick Reference (3)
It’s not actually as bad as it sounds. This is meant to be a testable equivalent of:
14.1 Use the clearest and simplest language appropriate for a site’s content. — WCAG 1.0 Checkpoints
Basically, what this means is that it should be understandable by someone who has had between six and nine years of schooling — so in the UK as long as someone between the ages of 11 to 14 could understand it, you’re ok. If not, then what you’d be expected to do would be to provide additional help to make it easier to understand — a summary, visual illustrations and so on.
This isn’t a bad thing, and when you consider that you don’t even need to worry about what constitutes “lower secondary education level” unless you’re trying to achieve AAA Conformance, it’s not something most sites will need to concern themselves with.
Other success criteria relating to this principle ask you to keep your navigation mechanisms consistent, help the user to detect and correct input errors, allow the user to check or reverse errors — particularly in the case of legal or financial transactions — and to provide context sensitive help if you can.
Principle 4: Making Content Robust
This is the shortest of the four principles, with not particularly that much identified in the way of ‘robustness’. Indeed, robustness consists of just two success criteria: one saying that content implemented via markup languages should have complete start and end tags according to specification, and one saying that the name, role and state of user interface components should be programmatically determined and set where appropriate.
This “having complete start and end tags” is the latest incarnation of the success criterion which used to state that the document must be able to be “parsed unambiguously”, which in turn was the nearest thing to “this document must validate” that WCAG 2.0 contains.
I was one of the people who raised an issue with this on the previous version of WCAG 2.0, saying that while I understood unambiguous parsing was the first step towards making content robust and was therefore suitable as a level A success criterion, to me it would make sense to strengthen this at level AA and require that documents were put together according to their specifications which is obviously where “validity” would come into play.
The Working Group rejected that, saying that they felt “validity” was going beyond the remit of “accessibility”. I personally don’t think validity goes any further beyond this remit than robustness does — as robustness with future user agents has little to do with current accessibility, but does have a lot to do with validity.
However, despite my call to arms for validity, I was persuaded by their other arguments.
First they pointed out that while they were not mandating validity, it was the first of their recommended techniques for ensuring compliance with Success Criterion 4.1.1, which is the one about complete start and end tags. I have already pointed out that WCAG 2.0 requires semantics as part of 1.3.1, so these two success criteria go a long way already to give a good and proper use of HTML at Conformance Level A — even if it doesn’t have to validate.
Then, in answering my question about validity, the working group came up with a crucial factor as to why although they feel validity is useful (and therefore is a recommended technique), it cannot and should not be mandatory:
It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification. — WCAG Working Group
I’ve seen people, ahem, embed invalid markup into their web pages in order to try and improve accessibility, and I would agree with the Working Group that making the content accessible is more important than having it validate.
I would have liked to see something along the lines of “it should validate except when you’ve done something to make it more accessible that means it doesn’t validate any more”, but given that they’re trying to move away from overly long and incomprehensible success criteria, maybe it is just best to concede the point…
Yes, that’s right: despite my vociferous campaign to include validity, I’ve been swayed by their arguments. Hopefully that demonstrates that it’s not just the Working Group who are prepared to listen!
Summary
Last time I wrote about WCAG 2.0 for Accessites, I described it as a half-baked set of documentation that was of no use to anyone and required significant polishing. It’s fair to say I was critical.
So what do I think now?
It’s usable, it’s a vast improvement on the previous draft, and it’s an improvement on WCAG 1.0 as well.
Ok, it’s not perfect, not by a long chalk — it’s significantly lacking in relation to cognitive disability for example, and I’d like to see this improved before the final release — but it’s still pretty damn good nonetheless. One of the things I particularly like about WCAG 2.0 in relation to WCAG 1.0 is that where WCAG 1.0 was focused on the technology:
…use stylesheets to control layout and presentation — WCAG 1.0
…WCAG 2.0 is focussed on the user:
All functionality of the content is operable through a keyboard interface… — WCAG 2.0
I was critical of WCAG 2.0 before, and it deserved that criticism. Now, I’m prepared to praise it, because it deserves that praise. They’ve done a bloody good job on WCAG 2.0 over the last year, and the people on the Working Group — and those that submitted comments — deserve the appropriate credit for all of the hard work that has gone into fixing this.
I don’t say this lightly, but I think — even with the known weakness regarding cognitive disability — that WCAG 2.0 is now the best set of accessibility standards out there: it’s clear, it’s understandable, the focus is on the user, and finally, finally, it’s ready.
Bring it on.
- WaSP
- The Web Standards Project (WaSP) fights for standards that reduce the cost and complexity of development while increasing the accessibility and long-term viability of any site published on the Web. Learn more about WASP (Back to WASP Instance)

Mel Pedley responds:
Posted: May 25th, 2007 at 5:33 am →
It certainly looks as if a great deal of the feedback on last year’s draft has had a positive effect. Whilst I’d agree that the current draft isn’t perfect (and probably never will be), it is beginning to look as the Working Group is in the right road to creating a usable, practical, set of guidelines.
The current deadline for submitting comments on the WCAG 2.0 Last Call Working Draft is 29 June 2007. The feedback from last year’s draft seems to have had a real positive effect. Let’s not let the opportunity to comment on this draft slip away either.
patrick h. lauke responds:
Posted: May 25th, 2007 at 5:39 am →
nice write-up. i’m currently on the last few pages of the appendix (only reading through the core WCAG 2.0 document, not the associated techniques etc) myself, and will soon be sending my comments off.
on the issue of “having complete start and end tags” … that whole thing just sounds awkward in the guidelines. you can tell they tried to carefully pussy-foot around the issue without saying “valid”…but by doing so, they’ve come up with something that seems very (X)HMTL specific. what i’ll be proposing is something more along the lines of: “must be well formed and follow the language’s syntax rules” (as “well formed”, i.e. following syntax, does not necessarily mean “valid”).
goetsu responds:
Posted: May 25th, 2007 at 5:51 am →
I am totaly agree with you, this version was a major improvement, wcag 2 or now understandable. But, i think there is still mistake, lake or change that need to be made on the technique and Understanding Success Criterion document. Particulary, i think that guideline 3 and 4 need a lot more of exemple and failure exemple.
Clive Walker responds:
Posted: May 25th, 2007 at 7:43 am →
In order to get web designers/developers on board with the WCAG 2 guidelines, I think the checkpoint document has to be much shorter. The current version may be OK for a large web design company who can spend time and resources on this, but for the smaller company or freelancer, it has to be easily assimilated. The WCAG 1 document is very good for this. The WCAG 2 document is likely to put people off in my opinion [even if it can be shortened using the options you describe]. This applies particularly to non-experts who would like to learn more about accessibility and want to do better.
John Faulds responds:
Posted: May 25th, 2007 at 8:40 am →
I agree with Clive. I don’t have time to try and digest all the guidelines myself at the moment so the best I can do is keep an eye out for summaries like this one. Thanks, Jack!
Noemi responds:
Posted: May 25th, 2007 at 8:49 am →
Thanks for putting together this great write-up. I’d seen a lot of the criticisms of the working draft, and was ready to dismiss the present document as well, but now I’m re-thinking it.
Here’s a question for those who have actually read the document: does it contain any recommendations or requirements beyond the accessibility best-practices that have been circulated in the web standards community for the past few years?
By the way, there are a lot of gremlins in the text-only version of this article, at least in Firefox on WinXP.
Mike Cherim responds:
Posted: May 25th, 2007 at 9:08 am →
@Clive: Good point. Make it too daunting and people will run away, especially the little guys who see it from an ant’s perspective.
It is a step in the right direction, though, better than before, and thanks to Jack’s hard work in writing this up, it seems more palatable than it previously did.
@Noemi: Thanks, I’ll get out my gremlin swatter.
Update: Gotta love “Find and Replace.” The text version gremlins have been swatted
Respiro, the logo design guy responds:
Posted: May 25th, 2007 at 9:12 am →
Great article! Thanks!
Paul Armstrong responds:
Posted: May 25th, 2007 at 9:26 am →
You’re complaining about the length of the WCAG documents?
And just how many words is this THREE PAGE post??? 4000+? That’s longer than most University-level essays.
Grant Broome responds:
Posted: May 25th, 2007 at 10:05 am →
Lovely post Jack, good level of detail as always.
No more ‘web units’ eh? That’s the best thing I’ve heard for weeks. Who’s crumby idea was that in the first place. I feel inclined to take another look at the guidelines now after previously writing them off Joe Clark stylee. This post has addressed the major concerns, thanks for taking the time Jack.
Henny responds:
Posted: May 25th, 2007 at 11:49 am →
Thanks for the write up, really useful. I agree that you can read WCAG 2.0 in a way that works best for you and not necessarily all at once. The Quick Reference document also seems like to good way in especially as you can make it yopur own by customising it.
I posted about in the RNIB Blog a couple of days ago which I hope people will find useful.
Joe Clark responds:
Posted: May 25th, 2007 at 2:36 pm →
“Click here” and “more” as link text are explicitly permitted.
Defying document semantics and the document tree just because somebody’s toy can mix and match headings is not equivalent to “accessibility,” and if convenience features were the threshold, who knows what else would get in there.
Jack Pickard responds:
Posted: May 25th, 2007 at 7:52 pm →
Whoops! Joe is right about the click here thing… and here’s the specific reference:
I think that’s a shame to be honest, but like Joe says, it’s not really about convenience. Okay, I would have personally preferred it if you couldn’t have used “click here”, but I still think that the rest of it is sound…
links for 2007-05-26 « Richard@Home responds:
Posted: May 26th, 2007 at 12:19 am →
[…] WCAG 2.0: Woeful to Wonderful in One Easy Draft? - Accessites.org Accessites looks at the latest WCAG with a favourable report. It’s not perfect yet, but it’s definitely progressing in the right direction. (tags: accessibility wcag) […]
Wild Ted responds:
Posted: May 26th, 2007 at 2:31 am →
Great write up, for which many thanks.
Just one small point on “click here” and “more” as link text.
Whatever the accessibility rights or wrongs, “click here” and “more” are search engine optimisation opportunities gone begging. However, if you use link text such a “more on hot topic 1″ and hide all but the word “more” offscreen with CSS you will keep both Google and JAWS users happy.
Web Community seems a Little More Positive on the Latest WCAG 2.0 Draft « Oatmeal Stout - Justin Thorp’s Web 2.0 blog responds:
Posted: May 26th, 2007 at 11:52 am →
[…] There has also been a bit of positive feedback. Jack Pickard wrote the following… It’s usable, it’s a vast improvement on the previous draft, and it’s an improvement on WCAG 1.0 as well. […]
goetsu responds:
Posted: May 27th, 2007 at 6:14 am →
by the way, about the text resize criteria, read carfuly the suffisent technique and you will see you can perfectly still use pixel text-size just because ie7 and opera have a zoom mode (to break the opera’s zoom, good luke) or just because you use font-size widget in pure javascript on your page.
» WCAG 2.0 Working Draft May 2007: A closer look responds:
Posted: May 28th, 2007 at 2:13 pm →
[…] You don’t have to wait until I manage to read it, understand it, and write something about my opinion on it though. Jack Pickard has already done that work, and presents his verdict in WCAG 2.0: Woeful to Wonderful in One Easy Draft?, an article split into three pages (WCAG is a large document, so commenting on it may require using quite a few words after all). […]
Jared Smith responds:
Posted: May 29th, 2007 at 5:31 pm →
With a write-up like that, who needs to read the guidelines?!? Of course we all do, but this write-up is excellent for anyone not already familiar with the guidelines.
That there is about the most witty thing I’ve ever read and pretty much sums up the entire validity argument. It’s interesting that you have been swayed on this regard. But with logic as clear as you present it, I think more people will understand why validity might not be best implemented in WCAG.
Gregg Vanderheiden responds:
Posted: May 31st, 2007 at 12:49 am →
Thanks everyone. We are looking for your comments and input on the new draft. What you like and what you don’t.
A couple of documents that are helpful in reviewing the newest draft and seeing what changed and why.
1) A document that highlights the changes in WCAG 2.0 along with context is now available. It is at http://www.w3.org/WAI/GL/2007/05/change-summary.
The major overall changes are discussed up front along with rationale. Then it goes through each success criterion that has changed and lists the changes. The document length issue is one topic discussed.
2) An improved Quick Reference now allows you more flexibility for including just the information you would like.
Use the customization feature at the top to have only the information you would like shown. The Quick Reference will vary in length from just a few pages on up depending on how little or how much information you want included.
http://www.w3.org/WAI/WCAG20/quickref/
Looking forward to hearing what you like and any issues you see.
Thanks
Robert Wellock responds:
Posted: June 1st, 2007 at 10:07 am →
The Quick Reference seems a little wordy in places and also appears to be contradicting itself in certain paragraphs or that maybe it is just the fuzzy-wording.
ThePickards » Blog Archive » WCAG 2.0: The Next Draft responds:
Posted: June 2nd, 2007 at 5:26 pm →
[…] As the more astute of you will have noticed, I have already commented on the latest draft of WCAG 2.0 having written a review of WCAG 2.0 for Accessites just over a week ago. Why not pop over there to read it if you haven’t already? […]
WCAG: Recomendaciones de accesibilidad « Soldat’s log responds:
Posted: June 10th, 2007 at 3:16 am →
[…] Pues bien, a mediados del mes pasado la W3C publicó el nuevo borrador de la WCAG 2.0, esta vez con mejores críticas (WCAG 2.0: Woeful to Wonderful in One Easy Draft?), y hace un par de días se publicó la primera edición de WCAG Samurai Errata for WCAG 1.0. […]
A review of the Web Content Accessibility Guidelines 2.0, May 2007 Working Draft - The Web Standards Project responds:
Posted: June 11th, 2007 at 8:40 am →
[…] Jack Pickard, WCAG 2.0: Woeful to Wonderful in One Easy Draft? […]
WebAIM: Blog - WCAG 2.0 - Polishing the rough edges responds:
Posted: June 27th, 2007 at 5:49 pm →
[…] I am not intimately familiar with WCAG 2.0. I’ve followed its development and was even accepted at one time as a WCAG working group member, although I’ve ashamedly never really participated. So, I am mostly looking at WCAG 2.0 from an outsider’s perspective. As such, many of my concerns may be entirely due to misunderstanding the language or structure of the guidelines themselves. Yet if I have encountered such misinterpretations, it’s quite likely that someone less familiar with accessibility will have them also. Jack Pickard has written an excellent writeup on WCAG 2.0. I almost entirely agree with his conclusions (particularly those surrounding validity) and will not address the specific issues that he has brought up. […]
Search Engine Optimization » Blog Archive » A review of the Web Content Accessibility Guidelines 2.0, May 2007 Working Draft responds:
Posted: July 6th, 2007 at 11:43 pm →
[…] Jack Pickard, WCAG 2.0: Woeful to Wonderful in One Easy Draft? […]