WCAG 2.0 is not structured similarly to the WCAG 1.0 checklist, which listed all the single-A checkpoints, then the double-A checkpoints, then the triple-A checkpoints. This is probably partly because they don’t wish to imply that you can ‘cop out’ by conforming to one of the lower conformance levels, because doing so will still cause issues (of varying degree) to people with some disabilities, and also possibly partly because as WCAG 2.0 is constructed around Principles and Guidelines, it makes more sense to construct the document around these than around conformance levels.

Nonetheless, I’m reviewing it on the basis of conformance levels, as I’m not entirely convinced that anyone with the sufficient authority to mandate conformance against WCAG 2.0 will understand how the whole ‘accessibility’ thing works; I think they’ll just pick a conformance level and tell people to adhere to that, not understanding the consequences of the same (many people will then ignore criteria at higher levels). Therefore I might as well save time now and structure it by conformance levels in my head at least.

Here then, are the 25 success criteria for conformance level A.

Level A: Perceivability

There are 9 success criteria at level A relating to the perceivability of content.

1.1.1 Non-Text Content

Non-text content (images, controls etc) must have a text altern tive that can be programmatically determined which provides an equivalent to the non-text content. For controls, this would be an appropriate name for the control; for meaningful images, it would be an appropriate alt text; for a CAPTCHA you must have an alternative available for a different kind of sensory perception.

1.2.1 Pre-Recorded Audio and Video

For pre-recorded audio, you need to provide a text alternative. For pre-recorded video, you need to provide either a text alternative or an audio track that conveys the equivalent information.

1.2.2 Captions (Pre-Recorded)

Captions are provided for “synchronised media” (e.g. where you hear the actors speak as well as see their lips move!) except where the pre-recorded media is itself provided as an alternative to text content.

1.2.3 Audio Description or Full Text Alternative

A full text alternative for syncronised media including any interactions is provided or audio description of the synchronised media is provided

1.3.1 Info and relationships

Information, structure and relationships conveyed through presentation are either described in text or can be programmatically determined. In other words, if it looks like a heading, it jolly well had better be marked up as a heading…

1.3.2 Meaningful sequece

When the sequence content is presented in affects its meaning, that sequence can be programmatically be determined. I’ll use the trusty recipe analogy here: the order in which the ingredients are presented doesn’t matter, but the order in which the steps required to bake the cake appear in do. In HTML, this would mean using things like ordered lists where appropriate. In Flash or Silverlight… go and ask a Flash or Silverlight designer.

1.3.3 Sensory Characteristics

I just love this one. It sounds like it’s going to be really complicated, but it isn’t. The instructions for operating or understanding content cannot rely on sensory characteristics. In other words, you can’t say “click the button third from the right” because you don’t know how they will be presented; similarly don’t ask them to click on the triangular one. Instead tell them to click on button marked ‘B’ or some other suitable characteristic that is — guess what — programatically determinable. See: easy, isn’t it? At least assuming I’ve understood it correctly.

1.4.1 Use of Colo[u]r

Colour should not be used as the only way of indicating information, whether textual, prompting a response or simply distinguishing an element. Come along, mauve along now, nothing to see here…

1.4.2 Audio Control

If any audio plays automatically on a web page for more than 3 seconds, you should be shot. However the guidelines only require that you provide a mechanism to pause it, stop it, or set its volume independently of normal system volume.

Level A: Operability

There are 9 operability success criteria at Level A.

2.1.1 Keyboard

All functionality of the system must be operable through the keyboard except where the underlying function is to monitor the movement (e.g. handwriting) rather than the text input. This is not to discourage use of mice. Mouses. Whatever, it’s just meaning that even without a working mouse (or without the ability to use a mouse) someone should be able to use your site. It’s easy enough to test — just unplug your mouse.

2.1.2 No Keyboard Trap

If the keyboard can be used to navigate to a specific part of the page, the keyboard should also be able to be used to navigate away from that part of the page, to avoid someone TABbing to part of the page and then getting stuck there…

2.2.1 Timing Adjustable

For each time limit set, you must be able to turn it off, extend it at least 10 times, or allow the adjustment of the time setting to up to 10 times the default setting unless it relates to a timed real time event; or unless timing is essential and the activity would not be valid without it, or the time limit is longer than 20 hours. Although I can hardly imagine anyone complaining that they were viewing your web page for 19 hours and 57 minutes and then it timed them out three minutes early!!.

2.2.2 Pause, Stop, Hide

Is a good way to avoid detection when you’re being chased. However in this case it refers to auto-updating or scrolling information on a page, where you must be able to pause, stop or hide the activity unless that activity is essential to the content.

2.3.1 Three Flashes or Below Threshold

Don’t have any content which flashes more than three times in one second or is below the general or red flash thresholds. This applies to all content on the page, whether or not it meets other success criteria, as failing this criteria may affect the ability of some people to use the entire page.

2.4.1 Bypass Blocks

Use skip links. By which I mean ‘provide a mechanism to bypass blocks of content which occur on multiple pages’. Bhy which I mean use skip links so people don’t have to listen to your navigation bar being read out to them repeatedly.

2.4.2 Page Titled

Pages have a meaningful title which describe the topic or purpose

2.4.3 Focus Order

If a page can be navigated sequentially, and the navigation sequence of the page can affect the meaning or operation of the page, then focusable bits get that focus in an order that means the use of the page is preserved.

2.4.4 Link Purpose (in context)

The purpose of each link can be programatically determined either from the link alone or from that link in context on the page. In other words, if the link text, or a link title conveys the meaning, that’s ideal, but it’s also okay if the text around the link provides that meaning. Just don’t use ‘click here’. That annoys me almost as much as Comic Sans annoys Joe…

Level A: Understandability

There are 5 understandability success criteria at Level A. And yes, I know understandability probably isn’t a word.

3.1.1 Language of Page

The default human language of the page can be programatically determined. As in, is it written in proper English (lang="en-GB"), ‘generic english’ (which usual translates as ‘American’ (en), french (fr), latin or what have you. There’s even a code for Scouse I believe, if you really want to write in that…

3.2.1 On Focus

When an element receives focus it does not cause a change of context, which basically is something like opening a new window, updating or re-arranging the content of the page, or changing the focus back to something else, as these can all cause particular problems for people who cannot view the entire page at once.

3.2.2 On Input

Changing the setting of any component does not cause a change in context unless the user has previously been warned that this will happen

3.3.1 Error Identification

When an error is automatically detected, the item in error is identified and the error is described to the user in text

3.3.2 Labels Or Instructions

Labels or Instructions are provided where user input is required

Level A: Robustness

There are only two ‘robustness’ success criteria, and they both occur at level A.

4.1.1 Parsing

In markup languages, elements have complete start and end tags, are nested according to their specifications, and do not have duplicate IDs or duplicate attributes unless these are specifically allowed by the specification. The easiest way to test for this with X(HTML) is probably to validate your page, and indeed validation is recommended as a technique although it goes beyond the strict requirement for WCAG 2.0

4.1.2 Name, Role, Value

For all user interface components (form controls, links and the like), the name and role can be programatically determined; states, properties and values that can be set by the user can be programatically set, and notification of changes to these components, their states, properties and values can — and most importantly is — supplied to browsers and assistive technology

Level A Roundup

And that’s all, folks. That’s Level A for you. 25 checkp– sorry, success criteria for you to aim at as a minimum requirement. They are all fairly straightforward to do and to understand, with the possible exception of stuff like pre-recorded video captions and the like, but if you’re in the business of producing video, then you ought to know how to do this sort of thing. And if you’re planning on going ‘all YouTube’, with self-uploaded video content, then you’re going to struggle to make this part accessible.

Yes, that part may be hard: but remember why it’s required. It’s required because if you don’t do it, you’re depriving a section of society from being able to look at your content. Even if you’re currently a TAB (that’s ‘temporarily able bodied’ as fellow Ouch!ers will be able to tell you), that doesn’t mean you’ll never develop a disability. Or that someone you know won’t.

We might as well try and make the world a better place. We’ve got nowhere else to live in…