BS 8878 Web accessibility — Building accessible experiences for disabled people — Code of Practice has been published. While this is a little bit of a mouthful, it is basically the first draft of an official British Standard for web accessibility.

It’s important to note that it is not necessarily the final version: it has now been available for review on www.bsigroup.com/drafts until the end of January 2009, at which point the comments will be considered by the technical committee responsible for drafting the standard.

The first point I noted was that I was slightly disappointed that the bsigroup site required you to register before you could view and contribute to the drafts. This is a shame as it is a hurdle that some people won’t be willing — or able — to jump before contributing, and even if this is a small group, why exclude them?

Then we get to view all of the current British Standards which are open for review. It is somewhat revealing to see how many British Standards there are, and what they are about. There was one about the inclusion of glass in tables and trolleys for domestic use, and another one specifying respiratory protective devices for use against chemical, biological, radiological and nuclear agents. I was tempted to comment on these, but I thought I’d restrict myself to the web accessibility one.

The BSI Experience

I am immediately struck by two things that the BSI have done well. Firstly, the document is broken down by section, and you are asked to post comments — along with suggested improvements — in the relevant section, which means the document is a little less scary overall. Secondly, other people’s comments are visible and can be seen, although (presumably in the interests of privacy) you can’t see who has made each comment.

It just goes to show that you can’t please everyone, as the first comment complains that the document is broken down into sections, and ends by suggesting that the whole affair should be abandoned as a complete waste of time.

There are also a number of comments suggesting that the BSI’s review site is not in itself accessible enough. I would be minded to agree with many of these, but also acknowledge that they have to start somewhere, so maybe once people have actually agreed a standard they can then look to bring their site up to meet it.

A number of people also make a point along the lines of “when the accessibility experience within BSI is so bad, how can they tell other people what they should be doing?”. There’s a simple answer to this. The people responsible for the document are not the people responsible for the BSI website. I would agree that the BSI have a moral imperative to improve their site as soon as is practical, but this does not mean the advice is bad. However, I can understand the argument…

Who Is It For?

The document specifies it’s audience as being:

• business owners;
• marketing managers;
• public relations officers;
• web managers;
• HR managers;
• heads of IT;

It therefore seems to me to run the standard risk for this sort of document. If it is of sufficiently high-level for IT heads or HR managers to be able to follow and understand it, then it will in all likelihood not contain the depth and breadth of technical information to allow those actually involved in building the websites to make them accessible. On the other hand, if it does contain alll that technical information, then the chances of it being grasped, understood and taken on by those public relations officers may be significantly less.

It’s also interesting that anyone claiming conformance with the British Standard must indicate whether this is certificated (presumably by some agency authorised by the BSI?), self-assessed or assessed by a third party. What isn’t so clear is the idea of certification: who will be able to offer certification, under what circumstances, and how much is it likely to cost?

General Principles

It is suggested that the Managing Director or equivalent should identify a specific member of staff to ensure compliance. What is missing is that this member of staff must have the requisite authority. I know from experience that as the ‘person who kept banging on about accessibility’, accessibility-related things (departmental standards etc) were frequently given to me, only I didn’t have the authority to actually enforce them, and so those people who didn’t follow standards were allowed to continue, because no-one actually checked their work or stopped it going live.

Whoever is responsible must have the authority to pull stuff off the website, or prevent it from going on in the first place if it does not comply.

Then you have what appears to be a misunderstanding of the DDA. The document states that:

In the absence of county court case law it is not yet possible to make recommendations that guarantee compliance with the DDA…BS 8878 (Draft)

Now, one of the reasons that people have had difficulty in understanding exactly what is required of them by the DDA is that it requires reasonable adjustments. What adjustments are deemed “reasonable” by a court would presumably depend upon the knowledge and resources available to the company in question, and therefore unless there were a whole swathe of county cases illustrating companies and organisations of myriad sizes and types, it would be foolish to make a generalisation that what applies in one case will necessarily apply to all.

However, I am not a legal expert in the Disability Discrimination Act, so it’s always possible someone may wish to correct me on this…

And then you are asked to ensure that disabled people get an equal user experience. Hunh? I had understood this to be about equivalence; you cannot give a blind person an equal experience of a picture to someone who has seen it. However, if you provide the relevant information in text, you can give them an equivalent experience.

Similarly, if someone doesn’t support javascript, they may not get your whizz-bang version. They’ll get the one where they type in their full address and press submit, as opposed to the full address being automatically populated from the street number and postcode. That’s not an equal experience, but it’s an equivalent one: both parties can submit their address details.

You are also required to use an authoring tool which is capable of producing accessible content, which seems like a rather basic starting point, but is obviously necessary.

The Guidelines

The first sentence of this managed to annoy me:

This draft was released for public comment on 1 December 2008, at which time the Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines 2.0 (WCAG 2.0) is a “candidate recommendation”. It is not possible to include reference to guidelines that have not reached full “recommendation” stage. BS 8878 (Draft)

Why? If you are going to say something is barred from being included in the document because it is not a full recommendation, you really ought to at least say on what basis this is being done.

In practice, I imagine it is because they worry that it might change before it reaches the final stage. But there’s a simple enough answer: reference a specific version. Keeping out all reference to WCAG 2.0 where it is appropriate to be referenced simply because it is not yet a full recommendation runs the risk of the British Standard becoming outdated before it is finalised — or within weeks of being finalised, depending on when WCAG 2.0 reaches that stage.

After all, I can’t find any reference to PAS 78 being a “full recommendation”, and yet they’ve quite happily included references to that. I think it’s probably the ‘draft’ status scaring them off, but whether or not thie is a BSI policy, what is the purpose of this? If something is relevant, appropriate and correct, does it matter whether it’s in draft?

If the BSI could maybe ensure that the document references whichever is the latest recommendation, I could live with that: WCAG 1.0′s not great but if we knew the reference was to change to WCAG 2.0 when that makes it to a formal recommendation (irrespective of whether or not this is before the end of the comment period), then that would be a compromise I could live with.

However, that’s about it for this section. There’s a reference to WCAG; there are references to the user agent accessibility guidelines and the authoring tools accessibility guidelines — both of which are surely outside the scope of this document, as this is about building accessible websites, not telling people which browsers or developer tools they should be using. That’s it.

No actual recommendations made. No advice on what you should do; simply a reference to two sets of guidelines which aren’t relevant and one which is so out of date that it can be considered potentially harmful.

The document therefore avoids getting too technical by simply pointing you across to the relevant standards published by the W3C. That’s not in itself a bad thing; it’s just that I think only the Web Content Accessibility Guidelines relate well to the scope.

And that’s it for today. Tomorrow I’ll work my way through the rest of the document and look in detail at some more of the problems…