Before I go any further it seems reasonable to admit it: given that I’m arguing about WCAG, you can pretty much hoist me by my own petard and accuse me of being one of the Greater Standardista’s I spent my time ridiculing in The Standardista’s Alphabet.

[Edit: Secondly, if you've arrived here from Isolani, you might wish to read my rebuttal to his argument. But please read the article below first. The rebuttal will make more sense then.]

But I have encountered a lot of situations where I’ve been told “this site is inaccessible” because it fails to meet a single particular WCAG guideline, particularly one at priority level one or two. It is important to understand that complying with WCAG will help you produce an accessible site, but it is no guarantee that your site is accessible, any more than failing to meet WCAG is a guarantee that your site is inaccessible. It’s an indicator that this is likely to be the case, but it’s not a guarantee.

While WCAG 1.0 is currently the standard for Accessibility on the web, it is not infallible. It was created seven years ago and it is desperately in need of updating. To be fair, the WAI are aware of this and are in the process of producing WCAG 2.0, but it is important to realise that just because WCAG says something doesn’t automatically make it true.

Of course, it’s certainly likely to be true, which is why in my look at the “holes” in WCAG I’ve tried to justify each reason. Of course, it’s also possible that I’m wrong, so don’t just accept my points at face value: consider what they mean, weigh up the arguments and arrive at your own conclusions. I’m a firm believer in people making their own minds up.

To begin with, let’s start with a couple of definitions:

Web accessibility means that people with disabilities can use the WebWAI

…okay, that’s not precisely how I define accessibility, as I include things that don’t relate to disabilities, such as user agents, different screen sizes and so on. However, for the purposes of assessing the WAI’s documentation, we really have to use the WAI’s definition.

Next, the priority levels in WCAG:

[Priority 1]

A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document…

[Priority 2]

A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document…

[Priority 3]

A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document…

WCAG 1.0

So, Priority 1 failures will prevent some people from using your site; priority 2 failures will make it difficult for some people to use your site and priority 3 failures will make it somewhat difficult for some people to use your site.

It’s just not practical to go through every checkpoint — besides which I have no problem at all with many of them — so I’m just going to cherry-pick from the ones that I have some issues with.

Priority 1 Checkpoints

4.1 Clearly identify changes in the natural language of the documents text and any text equivalents.WCAG 1.0

Hmm. So If I was to write:

Arnie said "Hasta la vista, Baby"

…i.e. without marking up the changes in language, then I’d be in breach of this guideline and, according to WCAG, some people would therefore find it impossible to access the information on this site. I disagree with this. I’d say that someone who doesn’t understand Spanish won’t be able to understand it, whether or not they are disabled, and a disabled person using a screenreader and having it pronounced incorrectly will find it difficult — but not necessarily impossible — to understand even if they do understand Spanish.

Of course, longer passages may be more difficult to understand if pronounced incorrectly, so it’s important that you do mark up these passages appropriately, and longer passages may well be impossible to understand if pronounced incorrectly.

What I’m actually trying to establish here is that accessibility guidelines do not always reflect a yes or no state in user experience accessibility. In some cases, failure to mark up a piece of text may make the information incomprehensible to a user with a screen reader. In other cases, it may not.

It is obviously more important to ensure that your site is accessible to real people than it is to comply with arbitrary guidelines.

6.3 Ensure that pages are usable when scripts, applets or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.WCAG 1.0

Bear in mind some people may consider cookies to be programmatic objects. If you use a shopping cart of any description, how do you store the information in it? Do you use a cookie? Do you provide an equivalent function that doesn’t use cookies? Of course you don’t. You just tell the user that cookies must be enabled in order to use this part of the site.

Now in this case, it’s clear because of the way WAI define cookies that they don’t see them as programmatic, but as data—

Cookie

Data sent by a Web server to a Web client, to be stored locally by the client and sent back to the server on subsequent requests.

WAI Glossary

It would have been helpful perhaps to be more explicit in WCAG that cookies aren’t barred, but on the other hand most people have managed to arrive at this conclusion without any help! Okay, that’s a misunderstanding rather than a genuine problem, but there are issues with Checkpoint 6.3.

Note that this broad brush is applied to javascript as a whole, without any referencing to particular pieces of javascript which may or may not be supported by assistive user agents. For example, Microsoft .NET uses javascript to carry out a “postback” which my limited testing has suggested is certainly supported by at least some assistive user agents.

Other checkpoints have an “until user agents…” clause meaning that the checkpoint needs to be carried out until most user agents (i.e. not every single one) readily available to their audience include the necessary accessibility features. This seems perfectly appropriate here: if the majority of assistive user agents support certain aspects of javascript, then why shouldn’t using those parts of javascript be allowed?

Certainly, people can choose to turn off javascript — or this may be done for them in an internet café — but this does not come under the WAI definition of accessibility: this particular aspect is therefore an issue of universality and therefore does not belong in what the WAI term “accessibility”. This is not to say that every part of javascript is supported by the majority of user agents, but that a properly tested small piece of javascript that works with the majority of assistive user agents should not be against the principles of what the WAI term “accessibility”.

Priority 2

3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation.WCAG 1.0

I can certainly understand how using blockquote to apply formatting effects may cause confusion, but surely, provided the text itself is sufficiently clear, does failing to markup a quote specificially as a quote actually make it difficult for people to access the information?

Let’s try that Arnie thing again. Which disabled group would find:

Arnie said "Hasta la vista, Baby"

…more difficult to access than…

<cite>Arnie</cite> said <q>Hasta la vista, Baby</q>

In both cases, the fact that we’re saying that this is what Arnie said is perfectly clear without the additional <q> element. Yet according to WCAG, this is creating a barrier that will make it difficult for some people with disabilities to access. According to me, this is bollocks.

11.1 Use W3C technologies when they are appropriate for a task and use the latest revisions when supportedWCAG 1.0

I have no personal objections to this; the W3C technologies are widely supported across the board. Unfortunately this flies in the face of the WAI’s own definition of accessibility, which states that “content is accessible when it may be used by someone with a disability”. In what way would using accessible flash, or an accessible PDF document therefore be in breach of this? In no way whatsoever. It’s less universal as it requires a plug-in of some description, but that is an equal barrier to both those with and without disabilities. If the WAI are defining accessibility purely on the grounds of disability, then this checkpoint simply does not belong.

13.3 Provide information about the general layout of a site (e.g a site map or table of contents)WCAG 1.0

The example may well be facetious, but note that this does not in any way specify the size of your site. Even if your site consists solely of one page — for example if it is a news bulletin site — then unless you provide a site map or a table of contents for your one page somewhere on your one page, then you are clearly in breach of this checkpoint and you are creating a “significant barrier” to some people accessing your site. What patent nonsense. For a one-page site, an additional site map or table of contents shoved onto the page would be more distracting.

Granted, if you’ve got a site with hundreds of pages, and there’s no contents, categorisation or search facility then you are certainly making it difficult for someone to access your site, but for a one page site, this checkpoint is absurd.

Priority 3

9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controlsWCAG 1.0

It will apparently remove some barriers to accessibility if your site uses accesskeys as shortcuts to important links. Well, it might. Unfortunately studies have shown that many people who would be likely to use accesskeys aren’t aware of them—

The people who are supposed to benefit from access keys rarely know what they are. When testing a site with people using screen readers, none tried using the access keys available. A typical comment was “I don’t think they work with a screen reader”.Nomensa

…there’s no standard for accesskeys on the internet meaning that they are implemented in numerous different ways, accesskeys are frequently at risk of over-powering normal browser controls, and in addition to this numeric access keys can prevent people from being able to enter some special characters.

In short, using accesskeys might remove some barriers to accessibility, but they’re likely to cause more problems for end users than they resolve, and you’re better off without ‘em.

What WCAG Missed

I’m sure everyone has their own ideas of what should have made it into WCAG 1.0 but didn’t, so I’m simply going to list a few of the items from my earlier article designing for dyslexia that I think fit well into the WAI’s concept of accessibility as they would have removed barriers for people with dyslexia and should have been easy enough to include.

• Do not use all capitals for emphasis; this makes text more difficult to read
• Ensure your font can be easily scaled by your users up to a minimum of 12pt (or equivalent thereof)
• Do not right-justify text. This leads to the “rivers of white” phenomenon where the variable white space appears to “run” down the page and makes it more difficult to read.

… and I’ve ignored the ones that are harder to set a rule, such as “as a general rule, the more structured your document is, the easier it will be to understand” — because I can’t imagine it would be easy to turn this into a testable checkpoint!

Summary — The Do’s, Don’ts and Donuts

Firstly, note that I use WCAG regularly. I think it’s a great document. However it is absolutely essential to realise that it is seven years old, creaking at the seams and in need of updating. It includes some things that I don’t think belong in there; it misses out some things I think should be in there, and of the things that I’m happy are in there, I don’t necessarily agree with how they’ve been phrased and/or the priority level they’ve been given.

And yet, if it wasn’t for WCAG as a starting point, my knowledge of accessibility would still be hovering somewhere around the “empty” mark on the gauge. WCAG is a fantastic starting point and possibly far enough for someone who just wants to have reasonable cover of the basics. However, if you want to go further, you’ve got to actually understand it yourself, consider actual user requirements, read around the subject, and as per bloody usual … arrive at your own conclusions (although obviously taking into consideration other people’s thoughts, research, standards and so on).

Do’s

• Do use WCAG as a useful starting point.
• Do learn about how users with disabilities, and users with different assistive technologies use the web
• Do test your site with assistive technologies, ermulators and as many real people as you can get your hands on.
• Do seek to make your sites as accessible to everyone as is possible

Don’ts

• Don’t treat WCAG as infallible
• Don’t think that because WCAG isn’t infallible, it isn’t extremely useful
• Don’t break the WCAG checkpoints unless you know exactly what you’re doing and why you’re doing it
• Don’t beat someone over the head with an accessibility stick just because they fail a WCAG checkpoint: check that this will actually make their site inaccessible to some users first, and only then beat them over the head with an accessibility stick

Donuts

• Jam
• Ring
• Custard
• Chocolate sprinkles