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.
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.
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.
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:
- Create documents that validate to published formal grammars. (Checkpoint 3.2)
- Use header elements to convey document structure and use them according to specification. (Checkpoint 3.5)
- Mark up lists and list items properly. (Checkpoint 3.6)
- Mark up quotations. Do not use quotation markup for formatting effects such as indentation (Checkpoint 3.7)
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
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.
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.
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.