In December 2010 the British standards Institute (BSi) published "Web accessibility - Code of practice (BS 8878:2010)" http://shop.bsigroup.com/en/ProductDetail/?pid=000000000030180388; this document is based on, and replaces, "PAS 78: Guide to good practices in commissioning accessible websites". It extends, updates and improves on its predecessor and is therefore essential reading for anyone intending to create or update a web product.

This new document, like its predecessor, concentrates on the processes, procedures and practices required to create an accessible web product; it does not discuss coding or technical issues but does provide references to relevant standards, guidelines and practices; so there is no conflict between this standard and the guidelines produced by the W3C Web Accessibility Initiative (WAI).

Jonathan Hassell, from the BBC, who lead the development of the standard says "Most web product managers know accessibility is important, but need a guide to the decisions they make during product development which can impact disabled and elderly users of the types of multi-platform, interaction-rich products they are creating. BS8878 is that guide, and encompasses the best advice and experience from many experts from all round the world on how to make products that include these people.".

Firstly it describes the policies and structures that an organisation needs to have in place to support accessibility.

Secondly it describes a series of steps required to create an accessible web product. The steps are summarised in the document as follows:

• Research and understand the requirements for the web product;
• Make strategic choices based on that research;
• Decide whether to create or procure the web product in-house or contract out externally;
• Produce the web product;
• Evaluate the web product;
• Launch the new product;
• Post-launch maintenance.

The document describes the specific accessibility issues that should be considered at each step. At first sight this may look like a lot of new work but in reality nearly all of the steps are considered good practice for any web product development.

This is followed by an introduction to the existing guidelines for developing accessible web products as well as discussion of accessibility of non-browser interfaces and special consideration when developing for older users.

Finally there is a detailed section on "Assuring Accessibility throughout the web product's lifecycle", which identifies and discusses the various methods of accessibility validation.

Graeme Whippy, of Lloyds Banking Group, one of the authors of the standard, said "Lloyds Banking Group is committed to best practice in accessibility and sees significant business benefits in making our websites as accessible as possible".

The standard is about 90 pages long and the second half is made up of fifteen extremely useful annexes. These cover areas such as definitions, laws, standards, responsibilities, challenges, examples of web accessibility policies and statements, guides to testing and a comprehensive bibliography.

I have read the standard and found the information in it clear, concise, insightful and pragmatic. It is laid out in such a way that it can be read in small chunks as required by different audiences and steps of a project. It provides all the parties involved in the creation of web products the information they need to understand the issues, decide how to proceed towards an accessible product and, importantly, how to deal with real world conflicts between ultimate accessibility and other market forces.

It provides a single source for accessibility best practice and information on the law and standards regarding accessibility.

The only criticism I have is that it does not discuss in sufficient detail the importance of ensuring that new content added to the web product after launch is accessible. It hints and implies that this is essential but does not highlight the issue.

Having seen the document, Gail Bradbrook of Fix the Web, an organisation set up to help people with disabilities report web accessibility issues and get them fixed, said "if every web product used the standard then we would not be needed and could close down; unfortunately that is not the case yet and we are very busy and need more volunteers (see http://www.fixtheweb.net )."

To ensure the maximum benefit is obtained from the standard there is a need for a community to be built up around the standard that can add to and refine the standard based on new experiences, technologies and opportunities and I expect some organisation will step up provide the platform for this community.

The standard is an essential purchase for anyone creating web products, as it provides:

• Pre-digested research into accessibility and best practice;
• A roadmap showing how to ensure accessibility is built into web products;
• A template for recording the decisions made about accessibility which will help to show good intentions if complaints are made.

Its cost should be recouped within a few days of starting any significant web product development and it will continue paying dividends throughout the whole life-cycle. It should be used by all commissioners and developers of web products.