This is the second part of a three part series looking at the COI document Delivering Inclusive Websites which was published on 5th June 2008.

This section will look at planning, procurement and testing accessibility.

Planning

Public sector website owners must develop an accessibility policy according to section 6 of PAS 78Delivering Inclusive Websites [3]

It then goes on to explain what the accessibility policy must contain: information such as how disabled users will be involved in the design of the website, an analysis of user needs, and who users should contact if they encounter a problem.

I have no problem with any of this. An accessibility policy of this nature is sensible, and will be of benefit to a lot of people. It might possibly be a bit more resource-hungry, but I’m presuming public sector bodies will all find their funding increased to cater for additional testing and so on…

…no?

Oh well, it’s still the right thing to do, and you ought to have been doing it for your Disability Equality Duty anyway.

It also talks about accessibility statements and describes how these should be focussed on user needs: what, if any, parts of the site aren’t accessible yet, what the site is aiming for, and who the user should contact, rather than a list of CynthiaSays and Bobby Approved type logos…

It also suggests that sites should tell users how to configure their browsers (e.g. changing text size/colour) or at least should link to the BBC’s My Web, My Way. How easy public sector bodies will find it to link out to the Beeb when many don’t seem to like providing links to anywhere off site, I don’t know, but then again it probably is time for them to realise how the web works…

It then goes on with some information on how to develop a business case for accessibility.

Procurement

Fixing an inaccessible website after it has been completed can be difficult and costly and may not succeed in providing effective access. The best way to create an accessible website is to make sure that accessibility criteria are included throughout the project life cycle, starting with the procurement or commissioning stage.Delivering Inclusive Websites [4]

This extra expense incurred when accessibility is added later can be seen in the story of the DTI website on Blether, where it emerged the DTI were paying out more of our money because they’d not got a site which was met the standards they required it to meet in the first place…

So let’s not see that again, eh?

Instead, the COI tell us to follow the guidance given in PAS 78 when commissioning websites, which is … well … what people should really be doing in the first place, to be honest.

It also points out that where authoring tools fall short of the minimum level required (W3C ATAG), this should be documented and the likely impact for users assessed.

Measuring Accessibility

We are then told that an accessibility test plan is an essential component of the website accessibility policy that you’re supposed to have. And that…

The only way to find out if a website is accessible is to test it … Technical accessibility determines whether the site will work with a range of assistive technologies. Usable accessibility determines whether the site will be usable by disabled people.Delivering Inclusive Websites [5]

Frankly, it’s hardly rocket science. But on the other hand, it’s quite refreshing to see this sort of documentation presented (so far at least) with this degree of simple clarity, with the focus being placed on the actual users…

It then goes and looks at different sorts of testing in more detail, comparing the differences between automated testing, validation testing, user testing, expert review, conformance inspections, and some details of each.

It also goes on to suggest the setting up of user profiles of different sorts of user:

• Vision Impairment
  • Severe — users who rely on screen readers
  • Medium — users who use screen magnification
  • Mild — users who benefit from enlarged text
• Motor Difficulties
  • Severe — reliant on speech recognition or switch access
  • Medium — users who can only use a keyboard
  • Mild — users who find fine mouse control difficult
• Cognitive/Learning
  • Medium dyslexia — might want to change colours, text formatting or use TTS software
  • Mild to medium learning/cognitive disability — users who might use a symbol browser or rely on someone assisting them
• Deaf and Hard of Hearing
  • BSL users who might have problems with multimedia content
  • Non-signing deaf — benefit from captions/transcripts

They also talk about how some of these can affect older users. There is rather an elementary error here: if you’re going to have user profiles, you also need to consider people with colour blindness, particularly since around 5% of men and 0.5% of women suffer from it.

Now I think the intention was that this group should have been considered in the ‘mild vision impairment’ camp, but I think this should have been clearer, with more details on how these users will be affected. On the other hand, I don’t want to be too mean, because so far, I’m very impressed with the document, and I’m more than half-way through…

They then cover the assistive technologies used by various groups: screen readers, Braille displayes, screen magnifiers, speech recognition software, adaptive hardware and so on, how they work and some of the features/issues with each.

Again, this is all useful information, but in common with much of the stuff in this document, I suspect that not many people who don’t already know about accessibility will be reading this far — but that’s hardly the COI’s fault!