Planning & procurement

Task: Assess a design concept or prototype

Designs can be assessed for accessibility at any stage, from the initial design concepts through successively more functional prototypes.

Step 1. Consider the following high-level questions.

These questions will help you identify many of the potential accessibility issues without using the terminal. This can be done even at the earliest stage, when the design is still only drawings.

Question: Is everything within reach and sight?
Are all the controls, slots and displays in a compact arrangement on the front of the terminal?

Question: Are the controls simple and easy to operate?
Are any controls likely to require strength, dexterity or twisting movements?

Question: Is the purpose and organisation clear?
If you had never seen the terminal before, how would you know what it was for, what you could do and how you would use it?

Question: Are style and operation consistent?
Are the overall arrangements of screen elements consistent? Do different screens share common features? Do controls behave consistently?

Question: Is content simple enough?
Is there any jargon, terminology or concepts which make sense to you but could confuse users? Are there complex sentences or big blocks of text that could be broken down?

Question: Is the colour, texture and contrast okay?
If someone has difficulty perceiving colour, will they see the controls and information? Are there any patterned backgrounds that reduce text legibility?

Question: Could a blind or partially sighted person operate the terminal?
If you closed your eyes, how would you know what to do, which controls you should use and what outputs are produced? If not at first, could you learn to use it without looking?

Step 2. Apply the NDA public access terminal accessibility guidelines

The above questions will cover the major accessibility issues. This may be enough at an early design stage. However, if the design has advanced to a prototype stage, particularly if it has been partially implemented as a working terminal, you can go further by assessing it against all the NDA accessibility guidelines.

The steps you should go through are described in the Assess a current terminal for accessibility task.

Task: Assess a current offering for accessibility

Step 1. Determine the required level of compliance.

Accessibility requirements for the terminal may be written into the design specification. This may reference the NDA guidelines, saying something like "The terminal should meet all priority 1 NDA accessibility guidelines for public access terminals". If so, these will be your target and you can proceed to step 2.

If there is no design specification, or if the specification does not state accessibility requirements in terms of the NDA guidelines, you will have to decide now which of the guidelines the terminal should meet. The steps you should go through are described in the Scope accessibility requirements task.

Step 2. Use the accessibility checklist.

This is the NDA accessibility guidelines, presented in the form of a printable checklist. When you are satisfied that the terminal meets a specific guideline, you can tick it off the checklist.Go to the checklist.

Step 3. Consult the test methods for each guideline

Many of the guidelines include suggested test methods that can be performed by an assessor. Consider carrying out these tests as part of your assessment.

Step 4. Test with real users, where appropriate

The suggested test methods for each guideline may include user testing. For a description of user testing, readAbout User Testing.

Task: Scope accessibility requirements

Step 1. Consult users or user advocates.

The first stage of scoping requirements is to build up a picture of the user population. You should aim to find out who will be using the terminal and in what situations. This information can best be gathered by talking to users themselves and will prove invaluable when it comes to deciding what accessibility features are needed. Requirements definition is described in more detail in How to Create Accessible Products and Services.

Step 2. Decide which of the NDA guidelines the terminal should meet

When you are sure of the user requirements, refer to the guidelines themselves to determine which should be met. The guidelines are divided into two priority levels.

• Following priority 1 will ensure that the terminal can be used by most people with impaired mobility, vision, hearing, cognition and language understanding.
• Also following priority 2 will make it easier to use for these people and will include more people with cognitive impairments or multiple disabilities.

However, in order to assess whether a terminal is "accessible", you will have to decide how accessible it should be.

• Should it meet priority 1 only?
• Should it meet both priority 1 and priority 2?
• Should it perhaps meet a selection from priority 1 and 2?

This is a decision for whoever decides the requirements for the terminal, and the NDA guidelines are not intended to state accessibility requirements for any given terminal, whether public sector or private. Although they may be referenced in a public body's policy, the NDA guidelines are not themselves policy. Although they may be referenced by the requirements specification for a terminal, they are not a requirements specification for any given terminal.

So, it is up to the persons who are responsible for setting the requirements for the terminal to decide what level of accessibility is appropriate. The NDA guidelines are provided to help with that decision by stating what makes a terminal usable by people with impairments. They are accompanied by detailed descriptions and rationale which explain the motivation and justification for each guideline. They also give guidance on how to achieve compliance.

A terminal that does not follow at least all of the priority 1 guidelines cannot considered to be accessible. You must therefore aim for at least priority 1. Above this basic level, you will have to decide which priority 2 guidelines the terminal should also meet. Within priority 2, some guidelines will be more or less important, depending on the terminal's purpose, the kind of content and services delivered and the project context. Questions like the following may help determine which guidelines are the most important.

Question: Will users have support or help available to them when they use the service, or is it up to them to learn the interface?
Whilst information kiosks are sometimes installed inside buildings where staff are on hand, many terminals are used in a place where support and help is not readily available or convenient. With things like cash dispensers, asking for assistance from members of the public may compromise the user's security. However, some users will be unable to use the terminal without some initial training. In this case, it will be important to ensure that the installation follows guideline 2.7 "Provide training for new users".

Question: How sensitive is the information being input and output?
For things like railway ticket machines, privacy is not likely to be an issue. It does not matter whether other members of the public can see which ticket is being purchased. However, for things like bank cash dispensers, privacy is an important issue because the user's PIN number and account details have to be kept secret. In situations like this, you may decide to stress guideline 2.8 "Ensure privacy & security".

Question: Are many of the users elderly?
Elderly people in particular may have multiple impairments. They may have reduced vision, hearing and movement all at the same time. If there are likely to be many elderly users, consider stressing guideline 2.6 "Provide for users with multiple impairments".Question: Are individual users likely to need to use more than one terminal?
In some cases, a user will have to use many different terminals offering the same service. For example, ticket machines at rail stations. A user will have to use a different one at each station where they buy a ticket. If this is the case, it will be more important that the terminals have a similar user interface, so you may decide to stress guideline 2.4 "When deploying more than one version of a terminal, ensure that the user interfaces are similar".

Question: How extensive or complex is the content and functionality?
Terminals that offer more complex functionality or a larger body of information that is frequently updated are generally more difficult for users to comprehend and navigate. You may therefore decide to stress guideline 2.3 "Ensure that the user interface and task flow is similar across different functions and remains the same across repeated visits".

For more information about the importance of the context of use, see What is Accessibility?.

Task: Write a design brief or a Request For Tenders (RFT)

When you write accessibility requirements into an RFT or a design brief, you should carry out the following five steps.

Step 1. Scope the accessibility requirements for the project.

The procedure for doing this is explained in the Scope accessibility requirements task. If you are unsure about the level of accessibility that should be demanded, it can be useful to include suppliers in the scoping exercise. Suppliers are often aware of issues which affect feasibility and timescales.

The scoping exercise will result in a list of the specific NDA guidelines the design should meet.

Step 2. Write these requirements into the RFT, giving them a weighting.

Include your accessibility requirements in the section stating the criteria for award of tender. Provide a weighting for accessibility and use this when you assess project proposals. Specify the minimum requirements, e.g. "all priority 1 NDA accessibility guidelines for public access terminals" plus any additional preferred criteria. Always reference the version number of these guidelines when you write them into an RFT.

Step 3. Encourage an inclusive user-centred design process.

An inclusive user-centred design process will not only deliver a more accessible product, it will also save time and money in the long run. The nature and benefits of this are described in How to Create Accessible Products and Services.

Step 4. State the testing requirements.

Many of the NDA guidelines come with recommended test methods, included to facilitate quality assurance. Direct the developers to carry out these tests and consider carrying out your own independent tests on the deliverables. If you intend to include user testing, state this as a requirement.About User Testing.

Step 5. Plan for maintenance.

It is all too easy to create an accessible terminal and then add new inaccessible content and features over time. Encourage the developers to plan for maintenance and to provide mechanisms for it. Direct them to create solutions that will allow content to be added without compromising accessibility in the longer term.