Well, quickly would be a good start, as it’s a lot better than WCAG 1.0 — it doesn’t rely testing based on specific technologies, but instead looks at the impact on the user. But that’s not what I’m looking at here.

I’m looking at what parts of WCAG 2.0 that I think are appropriate to set as a minimum standard for public sector sites in the UK. Personally, I think there are three key points that need to be considered.

• Public sector organisations come in a variety of shapes and sizes, and aren’t just Local Authorities and central government departments. Is it appropriate to demand that all public sector sites should have the same level of compliance?
• We need to ensure that all public sector sites achieve a level of accessibility that is achievable and where it is not unreasonable to apply sanctions (of whatever type) if an organisation fails to meet the required level. Currently, too many sites fail to achieve the required standard: is this a problem with the sites, or is it a problem with the standard against which they are measured?
• We need to ensure that public sector sites are not discriminating against people with disabilities: all sites should be required to have at least a basic level of accessibility.

Comparison against WCAG 1.0?

So, taking these three points as my starting criteria, and looking at WCAG 2.0, and comparing it to the previous mandated standard — WCAG 1.0 at the Double-A level — what do I notice?

Firstly, I notice that there are a different number of criteria. To achieve WCAG 1.0 at the most basic level, we need to pass 16 criteria. To achieve the same against WCAG 2.0, we must pass twenty-five. Does this mean WCAG 2.0 is more stringent, and tougher to pass? Well, that’s something we need to consider — although the Double-A level of WCAG 2.0 only has 13 criteria compared to 30 for WCAG 1.0. Could we argue that with 46 tests on one site and 38 on the other, the two are roughly equivalent?

Well no, not really. Unfortunately it’s not as simple as that. WCAG 2.0 represents such a significant culture shift from WCAG 1.0 that in attempting to determine a suitable conformance level it does not make any practical sense to include WCAG 1.0 as a comparison. Instead, we’ve just got to look at WCAG 2.0 and see what we think is appropriate.

Accessibility Supported

The idea of what is an accessibility supported technology could be one of the most problematic features of WCAG 2.0, but — if you’ll indulge me for a moment first — I hope to be able to come up with a relatively simple answer. First, it’s important to remember that you must only rely on accessibility supported technologies:

Accessibility Supported

Using a technology in a way that is accessibility supported means that it works with assistive technologies (AT) and the accessibility features of operating systems, browsers, and other user agents. Technology features can only be relied upon to conform to WCAG 2.0 success criteria if they are used in a way that is “accessibility supported”. Technology features can be used in ways that are not accessibility supported (do not work with assistive technologies, etc.) as long as they are not relied upon to conform to any success criterion

WCAG 2.0

Right. That’s the “quick and simple” definition. Of course, you’ll be wondering what the full explanation looks like, if that’s the quick and simple one. So here is the more complicated bit — how do we determine whether or not a technology counts as accessibility-supported.

To qualify as an accessibility-supported use of a Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):

1. The way that the Web content technology is used must be supported by users’ assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users’ assistive technology in the human language(s) of the content, AND
2. The Web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following four statements is true:
   1. The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS); OR
   2. The technology is supported in a widely-distributed plug-in that is also accessibility supported; OR
   3. The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported; OR
   4. The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:
      • does not cost a person with a disability any more than a person without a disability and
      • is as easy to find and obtain for a person with a disability as it is for a person without disabilities

Note 1: The WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported

WCAG 2.0: Accessibility Supported

Right-ho. This bit looks complicated, but let’s break it down. To qualify as an accessibility-supported technology, the technology must be freely available, and either free or the accessibility-supported agents don’t cost more than the standard ones, and that particular use of technology has been tested for accessibility support.

Note also the note: the W3C aren’t going to tell us which technologies count as accessibility supported, this is something we’re going to have to work out on our own. And it will change over time.

So where start? HTML and CSS, obviously. Javascript? We’ll come back to that one. Flash and PDFs? Well, I’d say so: assistive technology can handle these pretty well, just so long as they have been put together in an accessible manner. You can’t just slap it on the web and assume it’s fine. But if you build it properly, it should be.

So that’s HTML, CSS, Flash and PDF I’d allow. What the COI need to do is to state which technologies are appropriate for public sector sites. Someone needs to take on this responsibility for UK public sector sites, and I think the COI is yer man.

Is Javascript Accessibility Supported?

Well, some bits are. And some bits aren’t.

And now I’ll look at Javascript. For Javascript, I’d allow use of particular pieces of javascript, where that particular script/command has been checked and documented as being accessible. For this, I think it would be useful for someone (the COI again?) to keep a list of javascript commands and techniques which have been found to work with assistive technologies: if someone wants to do the testing for an additional bit, and make their documentation available to the COI, then it gets added.

I think the time has come to accept that Javascript does not necessarily make a site inaccessible, and that sites can rely on javascript and still meet accessibility requirements — provided that script has been tested as being accessible. The most obvious example of this for me is that javascript which is ubiquitous within .NET sites — the javascript postback.

When working for a Local Authority, I ended up in a discussion with Microsoft about this who seemed quite content that this technology was accessible (and my test case, which I got screen reader users to look at, seemed to confirm this), but that obviously Local Authorities couldn’t use it, because under the current rules they were not allowed to rely on javascript — despite this javascript being tested and accessible.

This is obviously nonsense. Which is why I think we need to take a more complex view with javascript: let’s record accessible uses of javascript, and then people can use these. If they want to use something not already recorded, they have to carry out the testing and prove that it’s accessible.

Conformance Claims

…are optional, but if you do want to include them, they need to be made in a very specific way. This is not a case of sticking one of those accessibility badges on your site. You’ve got to provide much more information than this. Indeed, if you do venture to stick an accessibility badge on your page then this is deemed a conformance claim, and it must be accompanied by all the other necessary information.

So I’d suggest that public sector organisations are discouraged from including conformance claims. If they want to include some sort of information, a description of what testing they have carried out (and who with) may be may appropriate, but I tend to think this sort of thing is of no benefit — it’s self congratulatory backslapping only: describing what you’ve done does not in itself make the site more accessible, and you ought to be doing it because it’s right, not because you want to claim some credit for it and feel smug or superior.

Success Criteria: Perceivable

Criteria in this section:

• Provide an equivalent text alternative for non-text content (Level A)
• Provide an alternative for pre-recorded audio or video except where the media is a media alternative to text. If the media is time-based, the time information must be associated with it.(Level A)
• Provide captions for pre-recorded audio, except where the audio is a media alternative to text (Level A)
• An alternative for time-based media or audio description of prerecorded video is provided for synchronized media, except when the media is a media alternative for text and is labeled as such (Level A)
• Information, structure, and relationships conveyed through presentation can be programmatically determined (use headers, lists and so on properly) (Level A)
• When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined (Level A)
• Instructions provided for understanding and operating content do not rely solely on sensory characteristics (don’t say “fill in the fields with a circle next to them”, “put your answer in the box to the left only”) (Level A)
• Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)
• If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)
• Captions are provided for all live audio content (Level AA)
• Audio description is provided for all prerecorded video content in synchronized media (Level AA)
• The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 (except logos, decoration etc) (Level AA)
• Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality (Level AA)
• If text can be used to supply the visual presentation of the information, text is used to supply the information, unless it’s essential to be presented in a particular way (e.g. a logo) or the image can be customised by the user (Level AA)

All perfectly reasonable (bar maybe one, but I’ll come to that). I’m also delighted to see that you can’t have constant jangling background audio (not that you tend to find that in the public sector, but it’s a personal bugbear of mine).

This “media alternative” is a key thing in this. Initially, these success criteria seem a little onerous: thou must providest captions and so on, but that isn’t really the case at all. The media alternative specifies that where the media provides no more information than is available in a standard text equivalent (transcript or so on), then that text equivalent is fine. So in many cases, you don’t need captions, audio descriptions or so on, provided that you have supplied a good enough text alternative to the media.

As regards level AA, I tend to think that if you’re sophisticated enough to have live streaming audio content, you ought to be sophisticated enough to put captions on it. This does however mean that you need to be careful when you’re considering putting video conferencing, or live council debates on your website — you have to have someone sticking captions on it.

The potential fly in the ointment is the second Double-A one: success criterion 1.2.5. This requires that any public sector organisation must provide audio description of video content even if all of the information that can be obtained from that video is also supplied in a text alternative.

I have to be totally honest here and accept that while having the information in text format is probably not quite as good as an audio equivalent, I feel that this puts an overly onerous burden on public sector sites to little practical benefit: the early success criterion demands that the text alternative contain all of the information in the video, and I would have thought that this should be sufficient.

For me, the accessibility standard ought to be set at a level where someone with a disability can carry out all of the tasks, and access all of the information on a site, but not at a level that requires public sector organisations to undertake specifically complex work for little benefit. The standard ought to be achievable and it ought to be reasonable. And for that reason, I would recommend that the COI do not include success criterion 1.2.5 as part of a level that is mandatory for public sector sites.

Other than this, I think the rest of the perceivability success criteria are perfectly reasonable and appropriate.

Success Criteria: Operable

And the operability criteria:

• All functionality of the content is operable through a keyboard interface (Level A)
• If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface (no keyboard trap) (Level A)
• For each time limit that is set by the content, it is either adjustable, extendable, switch-offable, essential to the activity, over 20 hours, or related to a real-time event (Level A)
• Moving, blinking, or auto-updating information that starts automatically can be stopped, paused, or otherwise adjusted (Level A)
• Pages do not contain anything that flashes more than three times in any one second, or flash below the general flash and red flash threshold (Level A)
• Provide a mechanism to skip navigation and similar repeated blocks (Level A)
• Use meaningful page titles (Level A)
• Focus order follows in a meaningful manner (Level A)
• The purpose of each link can be determined from the link plus surrounding context except where the purpose of the link is intended to be ambiguous to users in general. Like this one. (Level A)
• More than one way is available to locate a page except where it is the result of, or a step in, a process (i.e. provide navigation, search, site maps etc) (Level AA)
• Headings and labels describe topic or purpose (Level AA)
• Make the keyboard focus indicator is visible (in other words, use :active and :focus pseudoclasses as well as :hover) (Level AA)

“Public sector websites shouldn’t cause seizures” seems perfectly reasonable to me, as do the other criteria. I can’t see any reason why any public sector site should not be expected to achieve all of these things. Most of them are done anyway, and the ones which are not already standard across the public sector ought to be standard across the public sector.

The whole lot of these ought to be mandatory. None of them are difficult to achieve, all of them will impact on people with disabilities, there’s simply no excuse for non-compliance with this lot.

Success Criteria: Understandable

And the success criteria here…

• The default human language of each page can be programmatically determined. (Level A)
• When any component receives focus, it does not initiate a change of context. (Level A)
• Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component (Level A)
• If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)
• Labels or instructions are provided when content requires user input. (Level A)
• The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular (Level AA)
• Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated (Level AA)
• Components that have the same functionality within a set of pages are identified consistently (Level AA)
• If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)
• For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)
  • Submissions are reversible
  • Data entered by the user is checked for input errors and the user is provided an opportunity to correct them
  • A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission

There are a couple of things here which are worthy of note: I’ll skip over language as that’s easy enough to apply using the lang attribute or xml:lang depending on what and where you’re doing it, so instead I’ll stop at change of context. By this, it means that you shouldn’t change the on-screen content or send someone off to a new page unless they click a link or button or you’ve already told them this will happen.

A common example of this is drop-down lists which, upon selecting an option, immediately take you off to that selected option. The obvious problem with this is that if you’re using a screenreader, you may not know this is going to happen. For example, on the Redbridge i council site, if you change the drop-down selection in ‘view events of type’, it will automatically change the selection of events viewed underneath. This is done in a keyboard-accessible manner (it does change as you scroll through the list, which is a good start!) but obviously there is no on-screen warning that this will happen.

Again, it’s an easy enough fix: either provide specific instruction on what will happen, or add a submit type button.

Beyond this, the requirements are again fairly simple: provide meaningful error messages, give as much detail about the error as possible, and there’s also the key bit about submitting a page which performs some sort of update action. This is likely to be majorly beneficial to most users — it gives you a bit more confidence if you can double-check your details before you submit them — and is really not that difficult to achieve.

Again, there’s no real excuse for any public sector organisation not being able to hit these checkpoints. They don’t require anything special to achieve; they’ll benefit a wide variety of users and they should be considered good practice anyway.

Success Criteria: Robust

This is almost a little rump section: there’s not a great deal to it, as there are only two success criteria here…

• Markup parses successfully: elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique (Level A)
• For all user interface components the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A). This success criterion is primarily for authors who script their own components. Standard HTML controls already meet this success criterion when used according to specification.

As regards the second one, if you’re using HTML controls in the standard manner, you’re fine already. As regards the first, parsing isn’t exactly the same as validation — but anything which is valid HTML must parse ok. And as public sector organisations were previously expected to have valid code, successfully parsing code should already be in place.

Again, there’s no reason why any public sector sites shouldn’t be able to comply with these without any problem.

Success Criteria: Triple-A

So far, we’ve just looked at Single-A and Double-A success criteria, but are there also any Triple-A success criteria which we should expect to be mandatory for public sector sites?

No. There are a lot of different success criteria at the AAA level which would be useful to certain groups of people with disabilities, but these will generally only impact on smaller groups of users, will only be relevant in certain circumstances, or will add additional accessibility beyond the basic requirement.

For these reasons, I’d suggest that public sector organisations are encouraged to comply with as many of the AAA success criteria as is feasible for them to do so, but that these should not be mandatory.

However, there are certain things that I would particularly recommend, which I think are fairly easy to achieve and will generate real, practical benefit:

• Do not justify text
• Provide information about the users location within a set of pages (menus, breadcrumbs etc)
• Use section headings to organise the content
• Provide mechanisms for identifying unusual words, jargon, acronyms or abbreviations
• Use simple, plain English

In Summary, Then…

Other than 1.2.5 (provide audio description, irrespective of whether or not text equivalent is available), there are no success criteria at either level A or level AA which appear to be particularly difficult or unreasonable to expect them to be achieved. On this basis, I don’t feel that there is any need for different ‘levels’ of requirement depending upon the size of, or the resources available to, a specific public sector organisation.

I would therefore recommend that the COI set the required conformance level for WCAG 2.0 to be at the WCAG 2.0 Double-A level with the sole exception of 1.2.5, which I think may be unreasonable for some public sector organisations to achieve (this would still require equivalent text to be available with all of the information contained in the video, but it wouldn’t require a separate video with audio descriptions added). I think this would be a very reasonable, practical level of accessibility to expect, one which ought to be achievable for all public sector organisations, and one which should ensure that anyone who is disabled still has access to all of the information and functions provided.

I would be worried that any standard which required conformance against 1.2.5 would either see public sector sites ignoring the accessibility standard, or would see public sector sites simply choosing not to use video and multimedia, which is why I believe this, and this alone, needs to be removed from the requirement before we can set the rest of WCAG 2.0 at the Double-A level to be mandatory for the public sector.

I’d also recommend that the COI encourage compliance with Triple-A level success criteria, and in particular the ones I have listed above which I feel will provide the most benefit with the least effort, but let’s keep it simple, and just make these advisory only.