I was recently asked what should be included in an accessibility statement on a web site. The following are my views based on my own experience and also reviewing a number of sites designed by Fortune Cookie. Fortune Cookie takes especial pride in designing accessible web solutions.

The page(s) containing the accessibility statement must be accessible from the home page with an easily discoverable link, preferably the first or second link in the tab sequence (this is part of my campaign that accessibility needs to be accessible); there is no point in having the accessibility link far down the tab chain as a screen-reader user will probably never find it. The pages should be accessible from all pages on the site but this may not be possible in the early stages of adding accessibility to an existing site.

The accessibility page should include:

• A brief description of the policy.
• How to report failures on the site.
• Details of the functions built-in to the site.
• Information on browser options.
• The standards used in the building of the site.
• The verification processes used.
• Links to further information.

The Policy
Two or three lines should describe the policy. An example from Lloyds TSB reads: ‘We recognise the importance of providing a website that is accessible by all users. As such we have made every effort to ensure that our site can be easily used by people with disabilities.'

This statement may need to include an explanation that not all pages on the site are yet accessible and that there is a plan to rectify the situation over time.

This section should avoid technical details such as mentioning the Web Accessibility Initiative (WAI).

If the organisation has a general policy on accessibility there should be a link to this as well.

Failure Reporting
There is nothing more frustrating than going to a web site, that claims to be accessible, finding a problem and then not having any way of reporting the problem. The accessibility page should link to a reporting page. To make this as easy to use as possible the reporting page should open up in a separate window so that the problem can be seen whilst the error is documented. Obviously the fact that a new window is being opened needs to be made clear to the user.

Accessibility Functions
This section should describe any specific features that have been developed to support accessibility. These may include accesskeys, alternative style sheets, or text to speech support such as Browsealoud.

The implementation of a search function should be included here as it can significantly improve the usability and accessibility of the site. An example is the Diabetes UK Charity site accessibility page.

Browser Options
Different browsers have different options and commands for enabling them. This section should describe the different versions or it could just be a link to an external site that explains these options such as the BBC My Web My Way.

Standards
A listing of the standards that are supported and how they are implemented. This section would include discussion of sizable text, alternate text, headers, WAI etc. This could include links to the main standards web sites.

Verification Process
An explanation of how the site is verified for compliance with the use of:

• Validation tools (such a SiteMorse or HiSoftware).
• User testing
• External validation (such as the RNIB and AbilityNet SeeItRight).
• Feedback from users.

Links
A list of useful links to further information, techniques and tools.

It need not be difficult
Great Sampford School is a primary school in Essex and it is worth visiting the web site as an example of how a small organisation can develop an excellent web site. In particular review the web accessibility page.

We can all learn from others so please add your comments and suggestions to this blog.