Nordic Guidelines for Computer Accessibility

Nordic Guidelines Logo

Second Edition

This publication applies the approach of Design for All. It describes a set of accessibility features of a personal computer system, which facilitate access and use by people within the widest possible range of capabilities.

Nordic Guidelines for Computer Accessibility provides public and private procurers with accessibility requirements to be included in or referred to in calls-for-proposal for personal computer systems and similar systems. It also serves as a guidance to ICT strategists, ICT designers and ICT standardisation groups.

Nordic Cooperation on Disability is an organisation under the Nordic Council of Ministers, that is the governments of Denmark, Finland, Iceland, Norway and Sweden.

Nordic Cooperation on Disability
Nordiska samarbetsorganet fr handikappfrgor 1998
Editor Clas Thorén

Table of contents

Preface
Acknowledgements

Part I ICT Accessibility - For whom, What, Why?

1 ICT accessibility - its nature
1.1 Who needs accessible ICT?
1.2 What is accessibility?
1.3 What are the benefits of accessible ICT?
1.4 Include accessibility in ICT procurements!

2 Scope and field of application
2.1 Who is addressed by this publication?
2.2 Which products are addressed?
2.3 How should this publication be used?
2.4 Contradictory requirements

3 Basic principles
3.1 Accessibility of public systems
3.2 Accessibility of corporate systems
3.3 The need for open systems

Part II Guidelines

4 Introduction
4.1 Built-in accessibility
4.2 Connection of assistive devices

5 The technical platform

6 The system unit

7 Controls - finding, reaching, identifying and using

8 The perception of alarms, warnings, status signals, error messages

9 The use of a keyboard
9.1 Basic ergonomic qualities
9.2 The localisation of keys
9.3 The identification of keys
9.4 Hitting and pressing keys
10 The use of a pointing device

11 The perception of the contents of the display

12 The use of printers

13 Requirements of persons with hearing impairments

14 Application software
14.1 Procurement of standard application software packages
14.2 Procurement of business specific application software
14.3 Design of application software
14.4 Making accessible Web pages

15 Documentation

16 Security


Preface

The Information Society has to be for everyone. This basic statement is an essential element in many national plans, strategies and visions for the emerging Information Society. Its immediate consequence is that all companies, organisations, agencies etc., be they public or private, have to ensure that their ICT products, services and applications are accessible and usable for the broadest possible range of customers and users, including disabled and elderly people. This broad user group includes current and future employees, school pupils, citizens and consumers, regardless of their physical, sensory or cognitive abilities. The end users addressed by this publication are a widely defined group, but with "people with disabilities" as its kernel. To have a disability should be regarded as a natural element of the life cycle. Everyone must expect, during some period in life, to be affected by circumstances that makes the access to and use of ICT products, services or systems difficult.

Accessibility of ICT products and services needs to be addressed by both the supply side and the demand side of the ICT market. The intended users of this publication are ICT strategists, purchasers, standardisers, developers and manufacturers. They should design and require products and services that have a set of properties that are built in from the outset, enabling people within the widest range of abilities and circumstances as is commercially practical to access and use them.

This publication is divided into two parts. Part I describes what is meant by accessible information and communication technologies (ICT) and gives the rationale for inclusion of accessibility requirements in ICT procurement, ICT standardisation and ICT design. Part II presents a set of functional requirements which meets the need for accessibility of personal computer systems operated by the end user. Except for a section on the accessibility of web pages, the intention has been to keep this publication independent of applications, technologies and vendors. However, it could not be disregarded that PC:s with Microsoft Windows has a market leading position of today's desktop and portable systems.

This second edition of Nordic Guidelines for Computer Accessibility replaces the publikation with the same title issued by the former Nordic Committee on Disability in 1993.

NORDIC COOPERATION ON DISABILITY

Finn Petrn
Director

Acknowledgements

This publication is a revised version of The Nordic Guidelines for Computer Accessibility, originally issued 1993 by The Nordic Committee on Disability. The revision work has been followed by a reference group, which has contributed with many invaluable suggestions for improvements, for which the author owe the group many great thanks. The following people have participated:

Name Organization Location
Stig Becker Swedish Handicap Institute, Stockholm, Sweden
Kevin Cullen Work Research Centre Dublin, Ireland
Ingela Friman Swedish Handicap Institute Stockholm, Sweden
John Gjderum Centre for Accessibility rhus, Denmark
Sren Hansson Swedish Handicap Institute Stockholm, Sweden
Fredrik Larsson Young Visually Impaired Ass. Uppsala, Sweden
Makoto Noshiro Kitasati University Tokyo, Japan
Mike Paciello Yuri Rubinsky Insight Found. Nashua, New Hampshire, USA
Dave Poulson HUSAT Loughborough, UK
Mats Stagnell Swedish Post Stockholm, Sweden
Gregg C. Vanderheiden Trace Center Madison, Wisconsin, USA

Part I
ICT Accessibility -
For whom, What, Why?

1. ICT accessibility - its nature

1.1 Who needs accessible ICT?

People are different. We are short, tall, young, old, quick and slow. Our abilities to see, to hear, to react and to move vary in time and between people. Regardless of our physical, sensory or mental ability, we will come across a product, service or system of information and communication technology (ICT) as a part of school, work or everyday life. ICT products, services and systems in work life, schools and public services of various kinds are parts of society that should therefore be accessible and usable for people within a wide range of abilities. Otherwise, a fairly large portion of the popula-tion will be unable to participate effectively in these environ-ments.

This publication is based on the approach that a disability should be regarded as a natural element of an ordinary person's life cycle. Everyone must expect, during some period in life, to be affected by circumstances that makes the access to and use of ICT products, services or systems difficult. The following four categories of users are examples of such circumstances:

1.2 What is Accessibility?

In those life situations exemplified above, ICT users want products, services and systems to be accessible. Accessibility is here defined as a set of properties that are built into the product, service or system from the outset, enabling people within the widest range of abilities and circumstances as is commercially practical to access and use it (Sometimes the definition of accessibility includes compatibility with assistive technologies, where the definition used in this publication is referred to as direct accessibility.). Accessibility of computers, keyboards, displays, printers and other peripherals, operating systems, user interfaces and application software allows that information systems, constructed from such components, can be directly used, without assistive devices or modifications, by the widest possible range of people.

This approach is often referred to as the principle of Design for All or Universal Design. It is however not limited to designers.

In the Nordic countries, a basic political principle is that barriers presented to users with disabilities in the first place are to be dealt with in the sector where they arise. This principle is usually referred to as "the principle of sector responsibility". For the ICT field, it means that accessibility of ICT is a responsibility for the ICT business, not the social welfare system. This implies that all actors in the ICT field should take a broad variety of human abilities into account - developers and designers, manufacturers, value adders, retailers, purchasers, strategists and end users.

Can we really design for all? The answer is: no. Design for All can never satisfy all needs of all people. There will always be people who need some kind of assistive devices, i.e. specifically designed addon input and output devices that compensate for different kinds of disabilities. Such devices enable an individual to independently complete tasks that previously could not be performed without assistance, due to the disabling condition. Any ICT system should be designed to enable the user to attach an appropriate assistive device, perform the same tasks and achieve the same results as any other user.

1.3 What are the benefits of accessible ICT?

For all users

For users with disabilities

For the individual ICT vendor

For the industry at large

For the public sector

1.4 Include accessibility in ICT procurements!

The supply side and the demand side of the ICT business share the responsibility for making ICT systems accessible. Accessible systems will not be developed, manufactured and marketed, if the purchasers do not demand and buy them. Public and private enterprises and administrations need to include accessibility as an element in their ICT strategies, ICT plans and ICT procurements for systems for external as well as internal use.

Therefore, procurers should include requirements for accessibility in their call-for-proposals, evaluate the offered products against the requirements, give accessibility a weight in the decision on which tender to be awarded, and include, where necessary, accessibility clauses in the contract. Accessibility should become a bid qualifier.

2 Scope and field of application

2.1 Who is addressed by this publication?

Three main target groups are addressed.

a) One purpose is to provide purchasers with a reference document to be used in or referred to in the call-for-proposal, by providing criteria for the selection of the most accessible equipment. In addition, IT managers responsible for corporate policy-making and planning will be provided with a reference document for taking accessibility into consideration in their work.

b) A second target group is standardisers. The design of information technology is to a great extent determined by specifications, made by standards bodies, organisations and vendor associations with the purpose of establishing and maintaining official and de facto standards. It is of great importance that accessibility requirements are seriously taken into account in this work. Ideally, accessibility should be a feature that is permeated throughout all standards.

c) A third purpose is to encourage manufacturers and vendors of computer hardware and software to apply the accessibility requirements in the developmental process.

2.2 Which products are addressed?

This publication defines a set of functional requirements meeting the needs for accessibility of ICT equipment that is operated by the end user, e.g. personal computer, display, keyboard, mouse, printer, operating environment and application software. This equipment is henceforth in this document referred to as a workstation.

The concept of a workstation includes various kinds of display and keyboard-based equipment, such as desktop personal computers, portable personal computers and high-performance technical workstations. This publication addresses workstations in all sectors of society - work life, public services, schools and home.

It should be noted that the concept of Net PC:s, with no or a limited number of expansion slots and serial ports, may not be usable by people who need assistive devices.

2.3 How should this publication be used?

As a reference document in procurements, this publication presupposes that such basic qualities of the workstation, that are needed by all users, are expressed in the call-for-proposal, either explicitly or by referring to corporate reference documents, on its part referring to regulations, standards or other reference documents. Accessibility should be viewed in the same way as any other system requirements such as performance, security, communication capabilities, low maintenance cost, etc., and should be automatically considered in procurement, standardisation and design processes. It must be emphasised that accessibility must not be a feature that is added at the end when all other system requirements have been considered.

Accessibility requirements are different for, for example, people with hearing losses and visually impaired people. It would, however, be neither appropriate nor desirable if a manufacturer were to develop one version of the product specially designed for blind people and another version for deaf people. Instead, accessibility for all people should be a natural part of all information technology products. Hence, the requirements for a certain function are intended to be applied in their entirety where they are used in general situations, such as by procurers in corporate procurements, in standardisation work or by a manufacturer in the design process. It should furthermore be noted that, due to the rapid technological development, no attempt has been made to classify the requirements into categories such as mandatory, recommended or desirable. The verb "should" is used throughout the requirements.

2.4 Contradictory requirements

It may occur that a certain characteristic of a system that is advantageous for one disability is the opposite for another disability. Generally, the problem of conflict between accessibility requirements should be solved by provision of user selectable presentation modes. For example, graphical user interfaces are of great advantage for most users, but are in many cases inaccessible for blind people. Therefore, the workstation should allow the user to choose between different kinds of presentation forms - voice, visual graphics, visual text, or by attachment of assistive devices such as Braille displays.

3 Basic principles

3.1 Accessibility of public systems

For ICT systems intended for the public, such as an information kiosk or a terminal at a public library, the user is unknown and can be anyone. A public terminal can be adapted to the individual user only to the extent permitted by the system itself. There will be no possibility for a specific user to attach an assistive device other than by, for example, plugging in an earphone in a standard socket intended for the public user. Therefore, the accessibility of such a system need to be maximised in order to allow the widest range of consumers or citizens to use the system. In general, it is required that the service provider designs the systems to offer

3.2 Accessibility of corporate systems

Accessibility of internal corporate system means accessibility for employees. Any current or future employee may be or become affected by circumstances that makes the access to and use of ICT products, services and systems difficult. The employer should design the system to provide o basic accessibility of the input and output devices and of the user interface, allowing employees with disabilities to use the same applications and achieve the same results as other employees,

3.3 The need for open systems

Information, applications for information processing and the hardware and software needed to run the applications have life cycles of different length. The information stored in a data base may be valid for several years but the workstation used for accessing the data base may become upgraded or replaced with shorter intervals. An individual who needs to use assistive devices must be able to work continuously in such a variable environment and use the optimal assistive device according to the current state of the disabilities of the individual.

This implies that

The best way to achieve the above characteristics, is to apply the principle of open systems, i.e. hardware and software complying with international and de facto standards. Open systems give the user freedom of choice of products and suppliers, with preserved system structure, allowing applications to live on despite the rapid technical development. Assistive devices - hardware and software - should also comply to the principles of open systems. By that, a person who needs a particular assistive device will be able to use the application during its lifetime, and also exchange the device if the impairment changes.


Part II
Guidelines

4 Introduction

4.1 Built-in accessibility

This publication defines accessibility as a set of properties that are built into the product, service or system from the outset, enabling people within the widest range of abilities and circumstances as is commercially practical to access and use it. The accessibility of a specific ICT system is a combination of the accessibility of its components:

The accessibility of the system components is more or less equivalent to the accessibility of its user interface, i.e. how the user operates input devices, navigates by moving pointers and cursors, selects functions for subsequent interaction and activates hardware and software controls. The graphical layout of the user interface determines the accessibility with respect to how the user navigates among the system services, how the user finds the appropriate function and is how the user is able to perceive and understand the text, symbols and icons that are presented to the user. The customisation facilities of the user interface enable the user to tailor the interface according to his/her abilities and preferences.

ICT professionals often look upon the user interface as a shell, something that is added to functions of the system. For most end users, however, there is no practical difference between the functionality of the system and its user interface. The user interface is the system.

Part II presents a set of accessibility requirements on the workstation and its components. Most of the requirements are related to the user interface in a broad sense, i.e. the hardware and software tools that are operated by the end user.

4.2 Connection of assistive devices

Although direct accessibility of workstations is by far the best solution, the type or severity of some persons' impairments preclude their ability to use a workstation even if it has been designed to include as many access features as practically possible. These users need special assistive devices to access and use the workstation. In many cases, these devices can be used in parallel with standard input and output devices. The standard hardware and software should therefore be designed to facilitate the connection of, interaction with and use of assistive devices.

Examples of assistive devices are speech synthesizers, speech recognition devices, software for screen image magnification, keystroke control etc. Some devices have been developed specifically to compensate for a disability, such as enlarged keyboards, program control by sipping and puffing with a mouthpiece, and Braille printers. Most devices are controlled by a software package designed to be executed in the host computer.

Design and procurement of assistive devices is not covered in this publication. There are two reasons for this: First, the choice of assistive devices is dependent on the preferences and capabilities of the individual user and the tasks that the user performs. Second, the provision of assistive devices are organised in different ways in different countries. In the USA, the federal agencies are recommended to include requirements for assistive devices in their call-for-proposals. In some cases, the assistive device is a part of a package configured to meet the needs of specific employees. In other cases, the supplier needs to demonstrate or assure that the systems being delivered are compatible with relevant assistive technologies. In the Nordic countries there are separate systems for provision and financing of technical aids including assistive devices for ICT systems. These systems can be seen as a part of the health and welfare system.

The issue of expandability and flexibility, i.e. the ease of adding to the system the hardware and software components of the assistive device, is addressed in section 6.

5 The technical platform

ICT systems of today are usually built on a certain technical platform. By a technical platform is here meant a combination of components such as processor, operating system, network services, programming languages, database management etc., which are standardised or market leading. In this publication it is assumed that the choice of which technical platform to be used by a purchasing company is - for economic reasons and/or for the facilitation of information exchange and communication - an element of the corporate ICT strategy, not something that is decided in the individual purchase.

Within the next few years, ICT strategies will be more and more integrated with business strategies. Focus will be moved from ICT as a technology to ICT as an instrument for support of business and enabling better business opportunities. In the public sector, a corresponding development will take place. The process has started.

To maximise system accessibility, the platform should comply with the principles of open systems and allow that interoperable, compatible and portable standard application programs, company-specific application programs, and assistive software can be installed and executed. The platform should include as many features as possible which promote accessibility, thus providing the programmer with building blocks with intrinsic accessibility features. A special advantage is that this will facilitate development of assistive software with common user interface and behaviour, which promotes portability and compatibility. Assistive devices could easily be exchanged or upgraded when necessary.

The technical platform should support the following basic accessibility principles:

Customisable user interface

The key to enable the widest possible range of individuals to use a certain application is to allow them to tailor input, dialogue and output features to their specific capabilities and preferences. Examples of features that the user should be able to customise are: key repeat rate, fonts, graphic attributes such as line and shadow thickness, cursor size and shape, etc. Furthermore, the user should be enabled to easily define and save his/her user profile, i.e. set the preferred parameters both globally and within a particular window.

Keyboard access to all features

Many people cannot use, or feel uncomfortable with, the mouse. Furthermore, long work with a mouse has shown to give rise to musculoskeletal strain in the arm. Application programs should provide the ability to access all commands and options by using the keyboard. This could be provided by operating the arrow keys or by keyboard equivalents for all menu items.

Output redundancy: visuals and sounds

The rapidly increasing multimedia capabilities enable software developers to design applications that can be used both by visually and hearing impaired people. For example, information showed on the display can be supplemented by speech output for people with low vision. Sound output can be supplemented by captioning for hearing impaired people. Provision of both sounds and visuals allow the user to choose his/her preferred output. This is specially important in public environments, e.g. for public information kiosks.

Use system standards

Consistency, predictable layout and predictable behaviour within and between applications are also keys to good accessibility. Therefore, system standards and style guides issued by the platform provider or recognised otherwise should always be followed to the maximal extent. This makes it easier for all users to predict and understand how the software should be operated, where alerts and messages are to be found, and the meaning of different features. The functions would appear similarly in all applications, which would decrease the need for - and cost of - education.

Compatibility with assistive devices

Most special access software bases its interaction with the application program on the assumption that the standard convention for the system is followed. For example, application software that does not use system cursors, that obtains keystrokes from the keyboard in an unusual or nonstandard fashion (which may occur for example in terminal emulations), or writes directly to the screen rather than using standard screen drawing tools may cause problems for special access software. Thus, an important and easy way to make application software interoperable with assistive devices is to use the tools and conventions which have been established for the operating system, user interface, network manager and other parts of the technical platform.

One major accessibility problem remains to be solved satisfactorily. The transfer from character-based to graphical user interfaces imposes a serious barrier to visually impaired people, since most assistive devices - screen access systems - which translate screen text to speech output or Braille, are character oriented. New products for accessing graphics exist on the market and other are being developed. A study undertaken in Sweden (CESAR - Comparative Evaluation of Screen Alternatives for Reading (1997). The Swedish Handicap Institue and Swedish National Labour Market Board.) shows however that the current systems are still of insufficient quality.

Requirements:

5.1 The technical platform should comply with the principle of open systems.

5.2 The technical platform should include basic accessibility features:

- The user interface should be customisable.
- Users should have keyboard access to all commands and options.
- Users should be enabled to select the output mode of the information according to his/her abilities and preferences.
- The platform should allow application developers to enable the user to have keyboard access to all commands and options.
- The platform should allow application developers to provide the user with the capability to select the output mode of the information according to his/her abilities and preferences.
- The tools and conventions of the platform should support the application developer in producing accessible software.
- The platform should enable assistive devices to operate concurrently with all other system functions, yet be transparent to those functions.
- The tools and conventions of the platform should support developers of assistive devices.

6 The system unit

Requirements:

6.1 Serial and parallel interface connectors, data buses, keyboard connectors and other data transfer mechanisms such as infrared technology or radio, should follow existing standards or de facto standards.

6.2 A system purchased with the expectation that it will now or in the future be used by a user who needs an assistive device should have the maximum number of serial ports, parallel ports and expansion slots.

7 Controls - finding, reaching, identifying and using

Requirements:

7.1 The surface of the controls should not contain chromium, nickel or other material which may cause allergy.

7.2 Controls should be placed so they could easily be reached by, for example, a short person or a person sitting in a wheelchair.

7.3 Controls should be placed separate from each other, to be easy to grasp and to avoid confusion.

7.4 Controls should be placed so that they are not activated by mistake.

7.5 Controls should be marked so that the control setting can be easily identified by touch.

7.6 The adjustment settings should be easily perceived.

7.7 The size, shape and surface of controls should be designed so that they are easily grasped when they are used as intended.

7.8 No operation of a control should require more power than 2 Newton.

7.9 Mechanisms for opening up and shutting by latches (for example laptop computers) should not require simultaneous use of two hands.

7.10 Mechanisms for inserting and removal of diskettes, CD discs and similar storage media should require a minimum of muscular strength, range of motion, reach and movement precision. Twist lock mechanisms should be avoided.

7.11 Diskette units should pop out the diskette so that it can be easily grasped. It is desirable that this can be controlled by the software.

8 The perception of alarms, warnings, status signals, error messages

Requirements:

8.1 Signals from the basic system (apart from the application program), such as alarms, warnings, status lamps and error messages, should have the following characteristics:

- Alternative forms - auditory, visual or tactile - should be available, allowing both visually and hearing impaired persons to adapt the signalling to their perceptive characteristics.
- The volume, and if possible also the pitch and frequency, of auditory output should be adjustable.
- Visual signals should be placed where they are easily perceived.

8.2 Warnings and similar alert messages must remain stable for a sufficiently long time to be discovered by the user. A way of avoiding problems is to let the message remain until dismissed by the user.

9 The use of a keyboard

9.1 Basic ergonomic qualities

It is presupposed that basic ergonomic qualities, needed by all end-users, are stated in other reference documents. For convenience, requirements for such qualities are included here.

Requirements:

9.1.1 It is essential that the keyboard well satisfies basic general ergonomic requirements, such as

- the keyboard should be detachable and have a sufficiently long cable (appr. 1.5 m), so that it can be placed according to the user's needs;
- the keyboard should be of a low-profile type, i.e. the height of the key-row beginning with A-S should be not greater than 30 mm;
- good friction between the keyboard and the desktop;
- the colour of the keytops should be matt and pale;
- the surface of the keytops should be concave;
- the user should receive a tactile and audible feedback when pressing a key. It should be possible to adjust and switch off the audible feedback.

9.2 The localisation of keys

Requirements:

9.2.1 Groups of keys (alphanumeric, numeric, function keys) should be separated by distinct spaces, with a distance of at least half a key. (This requirement is not applicable on laptops.)

9.2.2 Groups of keys should be distinguished by different colours on the key tops, but in a way that colour-blind persons may discern the colours.

9.2.3 The F and J keys on the alphanumeric keyboard, and the 5 key on the numeric keyboard, should be marked with a tactile identification, preferably in the form of a ridge on the keytop edge nearest to the user.

9.2.4 Frequently used keys, such as ENTER, SHIFT, ESCAPE, CTRL, BACKSPACE etc., should be placed and have a shape that differ from other keys so that they are easy to find.

9.3 The identification of keys

Requirements:

9.3.1 The contrast between the colours of the characters and the background of the keytop should be the best possible.

9.3.2 The height of the characters of the alphanumeric and numeric keys should not be less than 4 mm.

9.3.3 The height of the characters of the other keys should not be less than 4 mm, if there is available space.

9.3.4 The text on the keys should be printed in sans-serif characters, which is considered to be more easy to read than other typefaces.

9.3.5 No text should be printed in red or green colour.

9.4 Hitting and pressing keys

Several problems are associated with the typing itself, i.e. the hitting and pressing of the keys.

Major technical platforms allow the user to customise the keyboard with respect to features such as repeat rate, key activation delay, delay between acceptance of two consecutive key presses, minimum time for pressing a key before the key repeat begins, and serial instead of multiple simultaneous keystrokes etc. For other platforms, there are software packages available from third-party vendors with the same functions.

Requirements:

9.4.1 The user should be allowed to customise the keyboard with respect to features such as repeat rate, key activation delay, delay between acceptance of two consecutive key presses, minimum time for pressing a key before the key repeat begins, and serial instead of multiple simultaneous keystrokes etc.

9.4.2 If sufficient space is available, shift keys (upper and lower case, ctrl, alt etc.) should be duplicated, one on each side of the keyboard, and be placed symmetrically.

9.4.3 The keyboard should be designed to provide sufficient space to allow the user to mount a keyguard.

9.4.4 The system should allow the connection of two keyboards, which could be used simultaneously, for instruction purposes.

9.4.5 The power needed to press a key should be between 0.3 and 0.6 Newton. Preferably, the required power should be adjustable.

10 The use of a pointing device

The latter technology is more reliable and cheaper. The capacitive technology can be used only by a finger; people with prosthesises can not use them, nor can people wearing gloves.

Requirements:

10.1 The user should be allowed to execute pointing functions from the keyboard.

10.2 The operation of a pointing device should not require two simultaneous hand movements.

10.3 The power needed to operate the pointing device should be between 0.3 and 0.6 Newton. Preferably, the required power should be adjustable.

10.4 Touchscreens should be operable by use of a fingertip as well as a tool.

11 The perception of the contents of the display

People with low vision may have difficulties to perceive the information displayed on the screen. Most accessibility problems associated with screen output are software related. However, most technical platforms and application software provide a rich variety of customisation features which can mitigate many of these problems, such as selection of an appropriate colour of the background and the text, a different font or a larger character size.

For more severe visual impairments, screen enlargement systems exist on the market, providing individuals with a capability to magnify the screen image, which eliminates or reduces their problems.

For people with low vision, the ergonomic quality of the display unit is very important.

Requirements:

11.1 It is essential that the display well satisfies basic general ergonomic requirements, such as in ISO 9241 or in specifications such as TCO'95. Examples of basic ergonomic requirements are:

- no flicker or other forms of instability;
- non-glare surface;
- the contrast and brightness should be easily adjustable and adaptable to the user's needs and the work environment;
- the emission of electric, electromagnetic and electrostatic fields should be minimised;
- the monitor should be easily adjustable vertically and horizontally (tilted and turned).

12 The use of printers

Requirements:

12.1 The controls of the printer should, where applicable, satisfy the requirements stated in section 7.

12.2 Signals emitted by the printer should, where applicable, satisfy the requirements stated in section 8.

12.3 Alarms from the printer should appear on the display of the workstation.

13 Requirements of persons with hearing impairments

Requirements:

13.1 The electromagnetic characteristics of the equipment should not generate interferences for a user with a hearing aid where the induction pickup coil is activated.

13.2 The noise from the fan, the harddisc, or the printer should be minimised, since it may be annoying for a hearing impaired person, since it interferes with the conversation in the room.

14 Application software

14.1 Procurement of standard application software packages

Standard application software packages such as web browsers, word processors etc., are today not usually purchased by elaborating call-for-proposals with detailed requirements on functions and performance. Instead, the choice is more based on factors such as communication with customers and other external organisations, investment in competence, price, vendor credibility etc. Accessibility should be included in this list of decisive factors.

In this publication the decision of which standard application software packages to be used in a purchasing company is assumed to usually be an element of the corporate ICT strategy, resulting in a choice of software packages that are intended to be used companywide.

The best way to maximise the probability that an application program comply to at least the basic principles indicated in section 5, is to choose a program from a vendor who is committed to include accessibility features in his products. The vendor could be committed by having established a corporate policy including a statement that the products should adhere to an internal accessibility guideline or external, widely recognised one.

If the purchaser can not find a software vendor whose product meets the total set of requirements and has not adopted an accessibility policy, the second best alternative is to choose a program that has awarded a certification for meeting basic accessibility standards. For example, Microsoft has established a "Logo program", where independent software vendors who participate in this program earn the right to use the Logo on their marketing materials.

Many standard application software packages provide customisation facilities which meet many of the basic accessibility requirements outlined above. However, the richness of features that modern software contain makes it difficult for an ordinary user to find out the appropriate features and how they could be utilised. This is an issue of installation and training. It is essential that the individual user has access to internal or external expertise on which facilities the software package can provide and how to install the software and set the appropriate parameters. Furthermore, training providers should offer courses on application software where accessibility features are included in the curriculum.

Requirements:

14.1.1 Accessibility should be included in the factors which determine the choice of standard application software packages. The purchaser should request vendors of application software packages to declare if they have a corporate policy on accessibility. If so, the policy should be presented in the tender.

14.1.2 Application software packages should comply with a recognised guidelines document on software accessibility.

14.2 Procurement of business specific application software

For more business specific applications, such as sales support, CAD/CAM etc., the business software requirements may be satisfied by a standard software package available on the marketplace. Regarding accessibility, the same approach as in the previous section should be applied in this case.

Where a suitable business application program can not be found, and thus need to be developed, this will be made by internal employees or by external consultants. In both cases, it should be required that the developers follow established and widely recognised accessibility guidelines. The purchaser should, however, refrain from requesting that a specific guideline will be used, except for cases where the developer has not adopted one. The reason is that accessibility should be regarded as an added value, thus a factor of competition. Consequently, it is the responsibility of the vendor to find the best solution to maximise the accessibility.

Requirements:

14.2.1 The purchaser should request vendors of application software packages to declare if they have a corporate policy on accessibility. If so, the policy should be presented in the tender.

14.2.2 Application software developers should be requested to declare which accessibility guideline they have adopted as a basis for their products. Only if the developer does not have one, the purchaser may suggest an appropriate guideline.

14.2.3 Application software packages should comply with a recognised guidelines document on software accessibility.

14.3 Design of application software

At present (December 1997) there is no established European or global standard for software accessibility, applicable across different platforms. ISO 9241 (Ergonomic requirements for office work with visual display terminals) is the most comprehensive standard on human-computer interaction, but it does not cover accessibility.

For software developers, a number of design guidelines are available, which provide detailed recommendations, advice and explanatory information on how different system features could be designed in order to maximise the accessibility. Some are dedicated guidelines for software accessibility. Others are more general and include a section on software accessibility. Examples are:

Further information can be found at the web site of the INCLUDE project (Telematics Applications Programme, Support Action SU1109), the URL of which is http://www.stakes.fi/include.

Examples of features covered in such guidelines are:

The structure, content and detail level of the guidelines differ to some extent. They have, however, many basic recommendations in common.

14.4 Making accessible Web pages

The emergence of the World Wide Web has made it possible for individuals with appropriate computer and telecommunications equipment to interact and access information as never before. Information and service providers can freely combine graphics, audio, video and text to attract customers and present information efficiently. But these powerful tools can also present barriers:

Making the World Wide Web accessible is to a great extent an issue of structuring the information. The information should be presented in more than one form and should be organised in a way that supports the underlying meaning and structure of the information. Text information needs the capability to be viewed as text, speech or Braille. Pictures and movies need text description annotations. A user of speech output would benefit from knowing if the current text is labelled as a header or a paragraph.

A number of general style guides exist, aimed for anyone who wants to publish documents and other information on the Web. These provide codes of good practice, such as consistency within and between documents, device independence, keeping documents to a manageable length, improve navigation by having meaningful links, etc. Examples of general WWW design guidelines:

These style guides provide the basic usability qualities that facilitate use of WWW by all end-users. But they do not necessarily ensure that accessibility issues are addressed to a sufficient extent. For that purposes, a number of Accessibility Guidelines have been developed, addressing the needs of not only users with disabilities but also general users who may be using text based browsers, have slow modem connections, poor or no audio capabilities or computers and monitors with low performance.

Trace Center at the University of Wisconsin has published a lot of material on making the web and web sites accessible. This information can be found at http://trace.wisc.edu.

The World Wide Web Consortium (W3C) has also launched a Web Accessibility Initiative. This organisation has brought together the efforts of the Trace Center and many others to create new worldwide standards for web accessibility. These can be found at http://www.w3.org/wai.

Other documents and the corresponding URL:s:

Some examples of Good Accessibility Practice for Web page designers:

Requirements:

14.4.1 Web page designers should be requested to adopt or consult existing guidelines for making accessible Web pages.

15 Documentation

Requirements:

15.1 Help text and other documentation should be provided online. It should comply with the same recommendations as are given in accessibility guidelines for the application itself.

15.2 The binding of the printed documentation should allow the user to place the documentation open on the table and turn the pages with one hand.

15.3 The documentation should be available in an accessible format such as ASCII, to allow Braille or speech output and to allow printing in alternative fonts.

16 Security

Requirements:

16.1 In the authorisation process, allowing the user access to programs and data, different technical solutions for identification and identity verification should be allowed.

16.2 The technical solution of the security system must not require modification of the standard input/output devices of the workstation.

16.3 Card systems should be easy to use for people with reduced visual or mobility abilities. Swipe readers should be avoided. Preferably, contactless systems should be used.


trace.wisc.edu
This document is hosted on the Trace R&D Center Web site. Please visit our home page for the latest information about Designing a More Usable World - for All.