A Universal Design Process

Specify measurable accessibility targets.
Specify how the service is going to be tested for compliance.
Plan for maintenance and expansion.
Follow an inclusive, user-centred design process.
Test with real users.

These guidelines provide a precise definition of accessibility requirements for services delivered through various it channels. They also provide explanation and practical advice on techniques for implementation and testing. However, it is not enough just to have guidelines and advice. To create accessible services within time and resource budgets, developers need to follow an effective and efficient development process. This section outlines a suitable process.

This process can be followed even if there are no specific guidelines available for the technology being used. For example, there are not yet any specific guidelines for emerging technologies such as interactive television or mobile devices. In this case, accessibility requirements have to be defined and agreed at the start. This section outlines an inclusive design process that can be applied to any technology.

Specify measurable accessibility targets

First, you have to define the accessibility targets that should be met. These can be documented as part of the requirements. For projects that are being put out to tender, this will be done by the service provider in the request for tenders (RTF). The developer organisation can then incorporate these targets into their designers' brief. For in-house projects, an analyst will usually define the accessibility requirements.

If the delivery technology is specifically covered by these guidelines, the accessibility targets are given here. All you have to do is choose the priority level that needs to be met. The priority 1 guidelines are considered to be the minimum level for accessibility and must always be included. In the case of the web, priority 2 guidelines should also be included if at all possible. The lowest priority guidelines are considered additional and you can pick and choose from these as appropriate for your particular project.

In some cases, the delivery technology may not be specifically covered by these guidelines. Or it may include aspects of more than one technology. However, it should be possible to define suitable requirements by borrowing from the existing guidelines. For example, interactive television is not the same thing as the web. Neither is it desktop software, public access terminals or telecoms. But it has a lot in common with these other technologies. The user interface is likely to use similar interaction methods and users are likely to face similar challenges.

If there are features that are unique to your technology, specific accessibility requirements can be devised from the universal accessibility principles:

All users should be able to perceive and understand the controls, instructions and outputs
All users should be able to reach and manipulate the controls, inputs and outputs
The user interface should be consistent across functions, devices and repeated use
For users who still cannot use the service, an equivalent alternative service should be available

These principles are explained in the Introduction to Accessibility.

Specify how the service is going to be tested for compliance

The requirements should also specify how accessibility is going to be measured. That is, how the resulting design is going to be assessed for compliance with the guidelines. This may be the job of a specialised testing or quality assurance team. Specifying an appropriate set of tests in advance has a number of benefits.

First, it gives the design and development teams guidance on how to check progress as they go. They can run the tests themselves during the development process so that they know they are achieving the objectives.

Secondly, it enables you to begin preparing for in depth user testing, which will involve recruiting representative users with impairments. To do this, you may have to consult with organisations that represent people with impairments and choose a suitable test environment. This may take time.

Thirdly, specifying real tests with representative users highlights the importance of the user and the tasks they will be using the system for. This helps designers understand what they are designing for.

Lastly, writing a test plan reveals how clear, objective and precise the requirements are. As far as possible the guidelines should be objective. However, this may not always be possible. For example, one of the web guidelines states "for data tables, identify row and column headers". This is objectively measurable since it is possible to say for sure whether it has or has not been met. But the guideline "use the clearest and simplest language appropriate" is more subjective. It requires an agreement about what is "clear" and "appropriate". In cases like this, you should try to ensure that the development and assessment teams agree on what is being asked for. It may be useful to add clarification to describe more precisely what this means in your particular situation. For example, you could state the level of literacy and knowledge of the subject area that can be assumed of the user population. Writing a precise test plan focuses attention on exactly what requirements you are measuring against.

Plan for maintenance and expansion

The process outlined here will help you achieve accessibility when the product or service is released. However, it is equally important that it remains accessible throughout its lifetime.

Very few services remain static. The information they provide, the customers' needs and the technology available to meet them constantly changes. Most services therefore undergo frequent modifications or additions to content and functionality. For example, a tourist information kiosk must have its content updated weekly or monthly as theatre and cinema programs change or new tourist attractions open. A bank cash machine might be expanded to provide new services such as bill paying. The new content and functionality must be as accessible as the old.

Achieving this involves planning. You will need to ask questions like:

Who will create the new content or functionality?
What accessibility training or knowledge will they have?
What tools or assistance will they be using to guarantee accessibility?

Often, the people who create new content or functionality are not the same people who created the initial content or functionality. They therefore require training, tools or assistance. The kind of tools and assistance that can help guarantee accessibility are templates, content management systems, style guides, review procedures and testing.

These tools often require that the system is built in a particular way, or using particular technologies. For example, a content management system for a website requires that the site is built with a database driven architecture. So it is vital that these issues are addressed at the beginning of the project, before decisions have been made that will make it difficult to implement a particular maintenance approach.

Follow an inclusive, user-centred design process

A user-centred design process is one that puts an emphasis on users and the tasks they want to perform using the service. It involves user consultation from the onset and throughout the project. It generally proceeds through rapid iterations of design, testing and redesign. This will require the participation of users who are representative of the target audience. To ensure the accessibility requirements are met, you should include people with a range of impairments.

This process will not only deliver a more usable product, it will also save time and money in the long run. It is significantly more costly and time consuming to fix a product in order to make it accessible than to develop an accessible product from scratch. Changes made late in the development process are far more costly than changes made early. The majority of these costs are not due to bugs but to unforeseen or unmet user requirements.

Test with real users

To be sure that a design is accessible, it is essential to test it with real users carrying out representative tasks in a representative environment. Tests can be carried out at any stage, from early designs, through prototypes to finished implementations. Preferably, this should be done by a dedicated user testing team. Alternatively, there are organisations that specialise in user testing it products and services.