ThePickards
standards, accessibility, and ranting and general stuff by the web chemist

This is the final 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 design, my conclusions, and the issue of enforcement.

Design

Finally, the document goes on to give a number of specific items of guidance which should be considered in website design (some of which will already be covered in either WCAG 1.0 or 2.0), but pretty much all of which are useful nonetheless.

• Avoid jargon
• Don’t justify text
• Try not to use images for text
• Ensure text size is adjustable
• Try and create a large clickable area for links
• Use descriptive links (Bonus point! They specifically say to avoid the use of ‘click here’ which is a personal bugbear of mine)
• Use a sitemap
• Provide skip to content links — and make them visible when activated (at least)
• If you use accesskeys, just use numeric ones
• Ensure all function can be carried out using the keyboard
• Images can sometimes be used to improve comprehension of text
• Meaningful images should have meaningful alt text — don’t say “photo of…”
• Ensure colours can be changed in the browser, consider offering an alternative stylesheet
• Use VisCheck to test pages for colourblind users
• Do not rely on colour to convey information
• Use consistent design and use whitespace to clearly separate page elements
• Associate labels with form fields
• If you’re going to use CAPTCHAs, allow alternative ones — e.g. an audio one instead of just a visual one
• Mark up table headers properly
• Ensure animation can be paused or switched off
• Provide a text equivalent to audio/video content — not only beneficial to deaf/hard of hearing users but to those in a noisy environment (and one they didn’t think of — users in a quiet environment where they don’t want to disturb anyone else!)
• Provide accessible controls
• [some advice on how to make Flash accessible]
• Avoid lengthy non HTML documents except where they need to retain their original form (or, as in the case of the COI Delivering Inclusive Websites guidelines themselves, where it is available in more than one version — e.g. PDF, RTF, word doc, HTML pages); and if you do have to use them, advice on font types, sizes, layout etc.
• Use heading styles for headings
• Use print stylesheets to optimise HTML pages for printing
• PDF files can be made accessible [advice on what to do]
• When presenting slides, use concise ideas, try and use minimum size of 24 point
• Use ‘notes’ field if using powerpoint to clarify and content presented on the slides
• Follow the W3C’s Mobile Web Best Practises and use their machine-verifiable basic tests.

And there was one I would never have thought of:

It is important to allow sufficient space in form fields to allow users to enter the correct information. For example, using the Typetalk service from the Royal National Institute for the Deaf (RNID), textphone users may wish to add the prefix 18002 for a voice telephone user to be able to contact them.Delivering Inclusive Websites [6]

Okay, I would have preferred that they just said not to use Accesskeys as it appears that pretty much every study on them has shown that they cause more problems than they solve (because even though they can be of benefit to some users of assistive technologies that know about them, they can still cause problems for any user even if only numeric accesskeys are used, and in general users need to relearn the accesskeys for every site, and therefore they are just too much trouble to use), and they ought to have but more detail into the different requirements for images when they are being used as links (and to indicate that meaningful images which aren’t links can — and probably should — have an empty alt attribute if there is a caption or similar which provides the same information that would be in the alt attribute).

But, on the whole, sound advice. Whether the people who are likely to thoroughly read and understand this are sufficiently empowered to enact it may be the problem.

It also seems that a lot of their design guidelines seem to have been influenced either by WCAG 2.0 directly or by best practice information as some of they key points (like ‘ensure all functionality is available through the keyboard’) weren’t part of WCAG 1.0.

Conclusions

But the question is, do the guidelines meet their stated aim?

This document sets out the minimum standard of accessibility for public sector websites and contains practical guidance on how to achieve this.COI: Delivering Inclusive Websites

Yes, it does set out a minimum standard. It also contains practical guidance on how this is to be achieved. In addition, it also contains a lot of practical guidance on building accessible websites which has no real relevance to the current minimum standard (WCAG 1.0). In fact, the guidance given is more ‘WCAG 2.0-style’ in terms of being user-centric rather than technology-centric.

This is a good thing, and the advice in it for everything except the declared minimum accessibility standard is excellent. The continued use of WCAG 1.0 is… well, I think Foviance said it best:

WCAG 1.0 had become horrendously out of date, including misleading, irrelevant and obsolete guidelines that had become counterproductive, especially for developers and designers new to the concept of accessibility.Foviance Newsletter

Don’t get me wrong, I understand why the COI feel they need to stick with WCAG 1.0 for the time being (as WCAG 2.0 isn’t formally endorsed by the W3C yet, as it’s not a ‘Recommendation’), but I do feel this is a significant flaw in the advice as this is letting politics get in the way of offering better guidance.

If you ignore the bit about WCAG 1.0, then I think it’s a great document. Therefore I think that if and when the document is reviewed after the formal publication of WCAG 2.0 as a Recommendation, it will improve considerably. Until then, my honest feeling is that you could better suit your users by following the recommendations in the document except those related to WCAG 1.0 and pin your colours to the WCAG 2.0 mast instead.

But taking that aside, it’s a great document. It tells you how to set up an accessibility policy, how to test your site (with real users — and that’s the main thing). If you follow it, it will help you to deliver inclusive websites.

Enforcement

There is however something missing that was in the previous version: the suggestion that non-compliant sites will have their gov.uk status revoked. I’m presuming this is because there is no point having a threat of this nature if you’re not prepared to enforce it. And we already know this is an empty threat from Dan Champion’s FOI Enquiry which established that:

1. No website domain names have been withdrawn for failure to comply with disability legislation; and
2. No website domain names have been withdrawn for the other reasons set out in the conditions of use

COI FOI Response to Dan Champion

No sites ever had their gov.uk status revoked, so it was a pretty pointless threat. The question I’d put to the COI is: you’ve provided the means for those who want to build an accessible site to do so. What sort of stick — if any — will be used to encourage accessibility for those who don’t?

This entry was posted on Wednesday, June 11th, 2008 at 12:08 am and is filed under Accessibility, Public Sector, Standards. You can follow responses via my RSS 2.0 feed. You can skip to the end and leave a response. Pinging is not allowed.