WCAG 2.0: when I want a beer, don’t give me shandy

June 2013: I’ve seen this page used as supporting evidence to say that the final WCAG 2 guidelines don’t matter. Please note that I was criticising a previous, draft version of it. This page is no longer current; it’s dated 2006 whereas the final guidelines are dated 2008.

There’s been some excellent discussion about the last call for comments on WCAG 2.0, both on the Web (see Joe Clark’s “To Hell with WCAG 2” and on w3c lists), and also in the hollowed-out volcano where the WaSP Accessibility Task Force meet. The fact that the w3c have extended the review period shows that they’re listening to legitimate criticism.

In many ways, the discussions about the document reflect the disparate philosophical positions within the community on what “accessibility” means. While the ATF hammer out a joint statement on this version of WCAG 2, here’s my personal take on it. This is the first W3c spec I’ve tried to read, so maybe my comments are based on daft mis-readings of the spec. Please do tell me if so.

Executive summary

The ideal of WCAG 2 is measurable, testable guidelines that are technology-agnostic, and will therefore not date so quickly. This is a noble ideal, but the realisation is flawed. While WCAG 2 doesn’t seem to be inherently evil, its message is diluted, both substantively (no requirement for valid code, tables are explicitly allowed for layout) and by excessive verbiage and jargon. Like shandy, it’s not an unpleasant drink, but it doesn’t hit the spot like a nice pint of bitter does – and that’s what I was hoping for.

The views expressed below are my own, and do not reflect the views blah blah disclaimer blah.

Structural problems

The old WCAG 1 had its faults. It reflected the state of the nation in 1999, when it was published. I quite liked old WCAG’s structure of the levels of accessibility, although I’m forever confusing the parallel nomenclatures of “priority 2″ and “AA” which still seem synonymous to me.

But the concept of levels made sense: you could explain, to suits and marketeers what they meant by using the library access ramp analogy. Now we’ve got “success criteria” and the like, which strike me as being largely the same as the old priorities, with none of the advantages of a simple-to-understand word (priority, level). Call me facile, but this is important. 99% of the world don’t understand the point of accessibility (“how could a blind person use a website, anyway?”), and making it more opaque seems to serve no point.

To understand WCAG 2, you need to read it along with the “understanding” document, and preferably the “html techniques” documents too. That’s 400 pages. That’s simply too long.

Unless you’re obsessed by accessibility, it’s simply too much to learn while you simultaneously grapple with CSS, PHP, JavaScript. An old mate of mine, John Dunagan writes,

I don’t have time to understand or decipher guidelines. They have to be dog simple and technically possible for me to implement them. (Source)

Ironically, one of the new decrees of WCAG 2 is that content must be understandable by someone with a “lower secondary” reading level. Yet, I’m a native English speaker with a degree in English, and I find it hard-going.

People will be driven to the backstreet clinics to be “helped out” by the snake-oil salesmen of automated validation and conformance tools.

Clear as mud

I’ve always said, to make accessible pages most of the battle is semantic, valid code. WCAG 1 was pretty explicit:

But this level of clarity has gone. By trying to make it future-proof, the message is hidden. It seems that WCAG 2 still requires semantic markup (the equivalent of 3.5 – 3.7 above), but now says

Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies. (Guideline 1.3.1)

Eh? Did you get that? Now, I think it is an excellent idea to try to write guidelines that aren’t going to go out of date by next Tuesday. But you need an Olympic Gold in completing cryptic crosswords to understand what that really means, and explain it convincingly to the suit from marketing.

How could that be rendered in plain English? Off the top of my head:

“Content delivered over the web should have its internal structural meaning tagged in such a way that the information on meaning may be separated from any information about presentation, and that information is kept up-to-date through all user interactions with the content, available in real-time to any user agent, whenever it is requested”

That’s still a bit clunky, but better than the indigestible splurge that’s currently in the document. (It’s also a bit markup-centric, as the word “tagged” is there. Can anyone else think of a better re-phrase? Please leave a comment.

Tables. Still not deprecated off to the glue factory

Tables for layout don’t cause accessibility misery, because for years, it was the only way to lay out a page, so users of screenreaders are used to it and can navigate a page despite the unnecessary tables.

But it’s an obsolete technique. As I said above, a fundamental tenet of accessibility is semantic code, so that a user of an AT can be told programmatically what an element is, not what it looks like. Layout tables fart in the face of that central tenet, and also provide superfluous, non-semantic information to screenreader users. Interestingly, WCAG 2 notes the undesirability of unnecessary attributes to layout tables:

Do not include a summary attribute and do not use the summary attribute to describe the table as, for instance, “layout table”. When spoken, this information does not provide value and will only distract users navigating the content via a screen reader. (Source)

That logic can’t be faulted. And, by the same logic, the whole practice of using tables for layout should be illegal under WCAG.

Validation. Wherefore art thou, validation?

There’s been a great deal of disagreement about validity of code in WCAG 2. I used to stand with those who said that validity is a goal but in the real world invalid code (the canonical unencoded ampersand or unclosed p) had absolutely no bad effect on accessibility, and that requiring validity was an attempt to smuggle general best practice into the accessibility guidelines.

However, I’ve changed my mind. One of the things that makes WCAG 1′s knees creak a bit is that it reflected the state of browsers and assistive technologies in 1999. And the argument I relate above states that validity doesn’t affect accessibililty in the real world – that is: the user agents available in 2006.

As Assistive technology gets better – as we fervently pray that it will – it will need to deal with the DOM, Ajax, xhtml 2.0, generated content and the like. It’s highly likely that in order to behave predictably, it should expect to receive a predictable DOM. (A quirks mode/ standards mode for ATs?)

The way to a predictable DOM is valid, conforming code. Therefore, in order to properly future-proof WCAG 2, valid code should be a pre-requisite. Full stop.

But think of the children!

There are a couple of occasions in which invalid code actually helps accessibillity as a hack to get over broken user agents. Now, it would be patently absurd to decree that embedded Flash is de facto inaccessible because it doesn’t validate, when in fact it is currently more accessible than the valid method (because Internet Explorer and JAWS combo choke on the content).

But the alternative of a caveat “until user agents can be guaranteed to expose valid code accessibily, you don’t really really have to produce valid code” is unthinkable. We don’t want more “until user agents” caveats sullying the purity of our specs. So what is to be done?

Maybe there’s room for a compromise. If you use invalid kludges to get over broken UAs then you couldn’t claim WCAG 2 compliance (as my full-strength beery WCAG 2 would require validity) but you could legitimately claim single-A conformance under WCAG one, and also note on your accessibility page why these pages are not accessible under WCAG 2. I think that’s an acceptable compromise. (Mind you, I think I can dance and look good in shades, so my judgement is occasionally suspect.)

Right up the baseline

The concept of the “baseline” continues to trouble me, even though greater minds than mine reassure me that it’s a good idea. WCAG 1 was becoming a bit pre-cambrian, in that it assumed you could only be accessible with html and partially-implemented CSS (by which I mean it assumed CSS was so badly supported in browsers that layout tables were still a legitimate method) . It also assumed that assistive technologies couldn’t deal with JavaScript and therefore effectively banned JavaScript.

This is biting us on the behind now that Ajax pages are everywhere and Assistive Technologies can’t keep up. For the first time, developers are legitimately accusing accessiblility advocates of zealotry and holding the Web back for the needs of a minority.

So it’s good that WCAG 2 has an extensible baseline built in, so that as more technologies are invented and Assistive Technologies catch up with them, the idea of the bare minimum (the baseline) could be revised, without the WCAG 2 specification getting out of date, as WCAG 1 is.

But what troubles me is that now you can officially do what the heck you like. As long as you specify, in your conformance claim that you assume Flash as part of your baseline (that is, the minimum specced user agent combo that can access your site), then you don’t have to worry about people who can’t access your Flash content.

Some point out that governments may set baselines as law, and so over-rule high-specified baselines. I’m not reassured by this, as I don’t live in a Utopian state. Most governments have woeful track records in ensuring web accessibility (if indeed, they have any track record at all), and it’s not hard to find brand-new inaccessible tag-soup government “websites” that contravene that government’s own guidelines.

I’d very much like feedback on other people’s views on the baseline concept, and whether I’m being unnecessarily churlish.

Cognitive disabilities

The elephant in the corner in all discussions about technical web accessibility is the subject of cognitive disabilities. It’s relatively easy to think of solutions that expose web content to people with phyiscal disabilities: for example, blind people (screenreaders), or deaf people (transcription), or people with motor problems (keyboard access).

But how to make a page that is equally useful for someone with attention deficit disorder, autism, Down Syndrome, alzheimer’s disease? Can it be done?

I think that physical and mental disabilities are entirely different challenges, and as yet we don’t have the knowledge to write guidelines for that apply as demonstrably successfully to those with cognitive disabilities as to those with physical impairments.

So I agree with Lisa Seeman’s call to remove learning difficulties and cognitive limitations from the list of supported disabilities. But I think that we should note that this is done for reasons of expediency, and not because I believe cognitive disabilities to be less worth catering for.

It should be noted throughout the next draft of WCAG 2 that the spec omits making content accessible to those with cognitive problems.

Coda

I played no part in the drafting of WCAG, and have few solutions to the problems I raise, so it’s legitimate to accuse me of sniping from the sidelines instead of participating. But I believe that criticism is participation. Plus, I’m just a jobbing web developer with a vested interest in maximum accessibility.

Personally, I’m confident that the combined brains of the Working Group participants should be able to square the circle. I’d rather wait another year than have a rushed-out accessibility specification that achieves no more than the lowest common denominator.

I urge the Web Accessibility Initiative’s chief brewer to have a bit more of a think, and serve us a pint of Standards without the lemonade of compromise.


This is an emotive subject that arouses passion and sometimes anger. I encourage comments, but ask that you resist telling me simply that I’m stupid without supporting evidence.And while this is my personal take on WCAG 2 and not that of the Accessibility Task Force, I’m grateful to all those colleagues as things they’ve said in conversation have helped me form my views.

22 Responses to “ WCAG 2.0: when I want a beer, don’t give me shandy ”

Comment by Ian Lloyd

“I urge the Web Accessibility Initiative’s chief brewer to have a bit more of a think, and serve us a pint of Standards without the lemonade of compromise.”

The Judy Brewer, no?

Comment by Ian Lloyd

Alternatively, “When I want a nice, well-made pint, don’t give me several crates of Kaliber and ask me to work my way through the darn lot”

Comment by Jim

Totally agree about levels. I t makes my job a lot easier to go to someone and say “build me a website. It must comply with all of level A and these bits of AA etc. etc.” I’m really baffled as to how to do that with WCAG2 unless, as Patrick suggested on Accessify, I just write my own technical implementation guidelines. In which case, why do I need WCAG2?

I had some thoughts on semantic HTML and Ajax (basically – HTML is a markup language for text documents. Does it have any semantic meaning when you start using it to mark up application user interfaces?) but it’s late, it’s Friday and I’m supposed to be in the local, buying someone a pint…

Comment by patrick h. lauke

“I had some thoughts on semantic HTML and Ajax (basically – HTML is a markup language for text documents. Does it have any semantic meaning when you start using it to mark up application user interfaces?”

as HTML is the only language that is mostly understood by user agents – including screen readers and the like -, HTML is all you gonna be able to use to mark up the output of your web application interfaces at this stage. of course, once we move down a more specialised route (e.g. an internal app using XUL), you’ve got a more sensible set of controls/elements, and i seem to recall that there’s at least a minimum of integration with MSAA on Windows…so you could start taking advantage of more semantically relevant markup there.

Comment by JackP

Very nice article that sums up a lot of the way I feel about WCAG 2.0. Fair enough, it needed updating but could it not have been done in concise, readable english, and this nonsense of tables-for-layout and it-might-not-matter-if-it-doesn’t-validate really need a good kicking. Give me a good full-bodied ale and make sure it’s been well poured…

Comment by Karl

Entertaining and interesting view on WCAG2 Bruce, I atually understood that. Thanks. I really worry about trying to work with this new standard, without plain English it’s going to be difficult for me to understand and even harder to explain to non-techies. I look forward to the @media panel and any future books from the community on the subject.

Comment by Grant Broome

Very nice article, concise and accute (as far as I can tell!)

I don’t agree that cognitive disabilities should not be considered as part of the guidelines. There’s actually a lot in WCAG 2.0 that’s particularly helpful for this group of users (and that’s without having to try to understand 3.1.3!)

There’s plenty that can be easily implemented without resorting to icon delivery (ala widget) that will make pages more accessible. For me, feedback from cognitively impaired users says a lot about the usability of the website and guidance on how to create crystal clear websites shouldn’t be undervalued.

Comment by Bruce

I agree, Grant, that it shouldn’t be undervalued. As someone who’s taught people with Downs and autism, I get very grumpy when people ignore the needs of people with cognitive disabilities.

But are the techniques for those with cognitive difficulties as testable and measurable as the techniques for helping those with physical disabilities?

(Not a rhetorical question)

Comment by Jonathan Worent

You mentioned four distinctly different types of accessibility: blind, deaf, motor problems, and cognitive disabilities. Why not split the spec into these four areas and have different levels or “sucess criteria” foreach. This would allow for better future proofing because as new research is done or new techniques are developed or UA’s add more compliance only the different areas can be updated individually to reflect that.

A site could then claim “Level 3 compliance for blind and deaf. Level 2 for motor disabilities. Level 1 for cognitive.” Granted this would take a massive rewrite.

As you can tell from my use of “levels” I agree with you on this. It just makes more sense

Comment by Christophe Strobbe

“If you use invalid kludges to get over broken UAs then you couldn’t claim WCAG 2 compliance (as my full-strength beery WCAG 2 would require validity) but you could legitimately claim single-A conformance under WCAG one, and also note on your accessibility page why these pages are not accessible under WCAG 2. I think that’s an acceptable compromise.”

That may work for websites that that conform to WCAG 2.0 on a voluntary basis, but not if the law requires conformance to WCAG 2.0 (but it will probably take a few years for legislators to catch up).

Regarding baselines: if we don’t want “until user agents” phrases, what is the alternative? Either we leave the definition of a baseline up to the goverments, or let another body (WAI?) define something like a “highest acceptable baseline” in a document that is referenced from WCAG 2.0 and regulary updated to reflect advances in AT. Any other ideas?

Comment by JackP

You want rid of the word Tagged? Try:
“Content delivered over the web should have its internal structural meaning recorded in such a way”

Comment by Keith Trigwell

Excellent article. Criticism entirely justified.

In my opinion WCAG2 should be a modernising of WCAG1 to make it relevant and remove the barrier between online display technologies and content even further. And deprecating tables for layouts should have been in there.

There is huge potential for this to be ignored by designers and authorities alike.

Comment by burun

Considering WCAG 2.0 guidelines whereas guideline 2.2 is framed in terms of “time limits” on reading and interaction. criterion 2.2.1 instead uses the term “time-out”. Neither “time limit” nor “time-out” is defined. This difference in terminology raises the question of whether there is meant to be a distinction between the two concepts. I don’t think there is, or ought to be, such a distinction.

Comment by Estetik cerrahi

Excellent article. Criticism entirely justified.

In my opinion WCAG2 should be a modernising of WCAG1 to make it relevant and remove the barrier between online display technologies and content even further. And deprecating tables for layouts should have been in there.

There is huge potential for this to be ignored by designers and authorities alike.

Comment by Chris

WCAG 2 is “CRAP”. WCAG 1 is “tough enough”. Why make a Succession based criteria that has criteria that is worse that its predecessor?

Cancel WCAG 2 and leave WCAG 1 for now.

Comment by Orjin Krem

You want rid of the word Tagged? Try:
“Content delivered over the web should have its internal structural meaning recorded in such a way”

Comment by reverta

First we just had to worry about PCs, notebooks and a handful of browsers, now pages have to be readable on all sorts of phones, Androids and iPads. It would be nice if there was one standard that works for everyone.