Public access terminals

Public access terminals include (but are not limited to):

• Atms (automated teller machines);
• Information kiosks;
• Ticket vending machines;
• Information displays (e.g. flight information);
• Point-of-sale customer card payment systems; and
• Card door entry systems.

For an introduction to the accessibility issues that arise with public access terminals, read the section about public access terminals accessibility in the NDA IT Accessibility Guidelines.

Which targets should you prescribe?

All public access terminals should meet the NDA it accessibility guidelines for public access terminals.

If the terminal is going to access a website, web application or set of HTML pages, it should also meet the user agent accessibility guidelines.

If the procurement also covers the content of that website, web application or set of HTML pages, the content should meet the targets specified in the websites and web applications section.

NDA IT accessibility guidelines for public access terminals

The NDA guidelines for public access terminals (pats) cover both the hardware and the software user interface. All pats should conform to these guidelines.

Suggested text for an RFT

About the NDA guidelines for public access terminals

The NDA pats guidelines are presented as a number of high level user-oriented functional goals, not as precise technical specifications. The main guidelines are as follows:

• Ensure that all operable parts are reachable by people of all
  heights and people sitting in a wheelchair or buggy;
• Ensure that displays are within sight of people of all heights
  and people sitting in a wheelchair or buggy;
• Ensure that controls are adequately sized and sufficiently
  spaced to be operated by people with limited dexterity;
• Ensure that operation requires minimal strength, grip and
  wrist twisting;
• Ensure that the terminal can be operated using only one
  hand;
• If using a touchscreen or contact-sensitive controls, do not
  require that it is touched by a body part;
• Ensure that users with restricted or no vision can use all
  functions of the terminal;
• Ensure that all outputs can be perceived by users with
  restricted or no vision;
• Ensure that all outputs can be perceived by users with
  restricted or no hearing;
• Use the simplest language possible for instructions, prompts
  and outputs and, where possible, supplement it with pictorial information or
  spoken language;
• If using cards, ensure that the card can be inserted into the
  card reader in its correct orientation without requiring vision;
• If using biometric identification, provide an alternative
  access security mechanism for users who do not possess the required biological
  characteristic;
• Do not cause the screen to flash at a frequency above
  2hz;
• When installing the terminal, ensure that users can get to it
  along an unobstructed path and operate it from a stable position;
• Ensure that an equivalent service is available through an
  accessible channel for users who cannot use the terminal.

For each of these guidelines, more specific design guidance is provided, such as “clearly define the edges of buttons and keys using a ridged border which is darker or lighter than the control itself”. However, this is intended as guidance, not mandatory properties that must be adhered to. The NDA resource also gives the rationale and suggested testing methods for each guideline.

The NDA pats guidelines are divided into 2 priority levels. Priority 1 covers the basic requirements to allow people to reach and operate controls and to perceive outputs. Meeting all the priority 1 guidelines will ensure that the terminal can be used by most people with impaired mobility, vision, hearing, cognition and language understanding. Priority 2 introduces guidelines concerning understandability and allowing users to remain in control. Meeting all the priority 2 guidelines in addition to priority 1 will make it easier to use and will include more people with cognitive impairments or multiple disabilities. However, security and cost issues are more likely to impact on the feasibility of meeting priority 2 although, in many cases, clever flexible designs will be able to get around these issues.

If you are procuring a pat, you should specify the NDA pats guidelines as a reference and expect that at least all the priority 1 guidelines should be met and preferably priority 2 as well.

For more information, see the NDA it accessibility guidelines for public access terminals.

User Agent Accessibility Guidelines (UAAG)

This standard covers web browsers, such as Internet Explorer or Firefox, and other types of software that retrieve and render web content. If the software user interface of the pat includes an embedded web browser or similar, this should be designed in accordance with UAAG.

Suggested text for an RFT

About UAAG 1.0

UAAG 1.0 covers web browsers, such as Internet Explorer or Firefox, and other types of software that retrieve and render web content. It describes the requirements that these ‘user agents’ should meet in order to enable users to access web content and display it in a way that meets their needs.

UAAG is divided into 12 guidelines:

• 1. Support input and output device-independence;
• 2. Ensure user access to all content;
• 3. Allow configuration not to render some content that may reduce accessibility;
• 4. Ensure user control of rendering;
• 5. Ensure user control of user interface behavior;
• 6. Implement interoperable application programming interfaces;
• 7. Observe operating environment conventions;
• 8. Implement specifications that benefit accessibility;
• 9. Provide navigation mechanisms;
• 10. Orient the user;
• 11. Allow configuration and customisation;
• 12. Provide accessible user agent documentation and help.

Each guideline contains a number of checkpoints and each checkpoint is assigned one of 3 priority levels, with priority 1 being the most important. These relate to the 3 compliance levels: a, aa and aaa. Satisfying all the priority 1 checkpoints for a user agent means the agent achieves level a compliance. Satisfying all the priority 2 checkpoints in addition to the priority 1 checkpoints means aa compliance. Satisfying the checkpoints of all 3 priorities means aaa compliance. In a nutshell:

Priority 1 = a (termed “basic requirements”);

Priority 1 & 2 = aa (removing “significant barriers”);

Priority 1, 2 & 3 = aaa (making it “easier to access the web”).

User agents' compliance with uaag is often quite poor. Also, atag 1.0 was written with pc-based user agents in mind and it may be difficult and, in some cases, inappropriate to provide the same functionality in a pat that someone would expect in a pc application. For example, browsers such as Internet Explorer or Firefox provide users with a degree of control over browser settings, such as being able to change the text size and switch off support for javascript or css. When a browser is embedded in a pat, there is usually no access to these functions. The user cannot access the browser menus and the toolbars are removed. Pats are usually designed to be very simple devices that do a restricted job securely. They allow access to a restricted type of information. They have to be simple enough for users with little pc experience to understand and robust enough that individual users cannot change the settings in a way that causes problems for other users. However most of the uaag checkpoints are still valid in some way, since some users may still need a way to configure text colours (checkpoint 4.3) or slow down animations and multimedia (checkpoint 4.4).

Consider the needs of your users and the nature of the technology platform to be used and be prepared to be flexible with the requirements of uaag 1.0.

For more information, go to the user agent accessibility guidelines (uaag) website.