Public access terminals

This page describes the relevant accessibility standards for public access terminals (pats) and gives sample text that you can cut and paste into an RFT. This text is designed to be used in conjunction with the sample texts describing general accessibility targets, an appropriate development process, how tenders will be evaluated, etc. These sample texts are given on the writing an RFT page.

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 applicationssection.

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

Accessibility targets

<the terminal> hardware and software should be designed and installed in accordance with the nda it accessibility guidelines for public access terminals. It should meet at least all the priority 1 guidelines and all appropriate and achievable priority 2 guidelines. Where a supplier considers any guidelines to be inappropriate or unachievable for some component of the hardware or software, this must be stated explicitly in the tender, together with an explanatory rationale.

Prior to tendering, suppliers should be satisfied that they can meet these guidelines, which are listed and clearly explained on the ndait accessibility guidelines website (http://accessit.nda.Ie/it-accessibility-guidelines/public-access-terminals/guidelines). The deliverables will be assessed against the checklist athttp://accessit.nda.Ie/it-accessibility-guidelines/public-access-terminals/checklist-public-access-terminals-accessibility.

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

Accessibility targets

Where <the terminal> presents information and interaction in the form of web pages, the software user interface should meet all appropriate and achievable checkpoints from all priority levels (1, 2 and 3) of the User Agent Accessibility Guidelines (UAAG) 1.0 from the Web Accessibility Initiative (WAI).

Prior to tendering, suppliers should be satisfied that they can meet these guidelines. A checklist is available fromhttp://www.w3.Org/tr/uaag10/uaag10-chklist.Html. The deliverables will be assessed against this checklist.

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.