Testing, assessment & Quality Assurance

Task: user test a design or prototype

For general guidance on user testing, read the section about user testing.

In addition, specific guidance on how to test for compliance is provided with the individual guidelines. Each guideline has a link to a full explanation and help, which may include suggested test methods and advice on user testing.go to the guidelines.

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 looking at the HTML code. 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, read about 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.

It is unlikely that a terminal that does not follow at least all of the priority 1 guidelines could be considered to be accessible in a broad sense. Above this basic level, you will have to decide which priority 2 guidelines the terminal should also meet. This will depend on its purpose, the kind of content and services delivered and the project context. Questions like the following may help determine which guidelines are appropriate.

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 include 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 including 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 include 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 include 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?.