Guidelines for Procurement of Accessible Personal Computer Systems - ACCENT PROJECT Deliverable 3.1 September, 1998
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Guidelines for Procurement of
Accessible Personal Computer Systems
ACCENT PROJECT
Deliverable 3.1
September, 1998This report constitutes Deliverable 3.1 of the ACCENT project. ACCENT is part-funded
under the EU’s SPRITE-S2 programme (Contract no. 97/501152) and by the Nordic
Development Centre for Rehabilitation Technology.
The participants in ACCENT are:
Clas Thorén Consulting (CTC), Sweden (Co-ordinator),
Work Research Centre Ltd. (WRC), Ireland,
Centre for Accessibility (Danish Centre), Denmark,
Statskontoret (STAKO), Sweden.
The Report was compiled by:
Clas Thorén (CTC)
with contributions from:
Kevin Cullen, Ciaran Dolphin (WRC)
John Gjøderum, Bodil Fogh Hansen (Danish Centre)
Rolf Bengtsson (STAKO)
© The participants in ACCENT
For further information contact:
Clas Thorén or Kevin Cullen
Clas Thorén Consulting Work Research Centre Ltd.
Knalleborgsvägen 8E 1 Greenlea Drive
S-178 35 Ekerö Dublin 6W
Sweden Ireland
Tel/Fax: +46-8-560 355 05 Tel: +353-1-4927042
e-mail: clas.thoren@ctconsult.se Fax: +353-1-4927046
e-mail: k.cullen@wrc-research.ie
Disclaimer
This project is partly funded by the European Commission in the framework of the
SPRITE-S² pilot action. The content of this publication is the sole responsibility of the
publisher, and represent in no way the views of the Commission. The European Communities
and/or their institutions cannot be held liable for the information contained in the present
publication or for any use of the information provided.
This project is partly funded by the Nordic Development Centre for Rehabilitation
Technology (NUH). The content of this publication is the sole responsibility of the publisher,
and represent in no way the views of NUH. NUH cannot be held liable for the information
contained in the present publication or for any use of the information provided.Table of Contents 1 Introduction 1 1.1 What is accessibility 1 1.2 Equipment and services for use by general public 1 1.3 Equipment and services for use by staff 1 1.4 Fulfilling wider public policy goals 3 1.5 About this guideline 3 2 Accessibility in procurements of PCs 4 3 Software accessibility 6 3.1 Usability 6 3.2 Accessibility 7 3.3 Accessibility in procurements of basic application software 8 3.4 Accessibility in procurements of business specific standard application software 9 3.5 Accessibility in procurements of software development 10 4 Accessibility of services connected to a PC system 12 4.1 Training 12 4.2 Documentation 13 4.3 Support 13 5 Requirements on the supplier 15 5.1 Competence and organisation 15 5.2 Selection of tenderers 15 5.3 The tendering process 16 5.4 Quality assurance systems 16 Appendix 1 Basic hardware requirements 18 Appendix 2 Software requirements 20 Appendix 3 Standards related to usability and user-centred design 22
1. Introduction
The aim of this guideline is to help public sector organisations to take account of accessibility
requirements, both of their employees and of the users of their public information services, when they
(the public sector organisations) are purchasing Information and Communication Technology (ICT)
equipment, systems and services. Accessibility requirements arise as a result of the temporary or
permanent disabilities that we may all experience during the course of our lives, as well as from more
general changes in functioning and ability that arise as people get older. The guidelines identify the
features of ICT products and services that make them “accessible” and show how to include these
features as requirements in procurements. They are intended primarily as a tool for “procurers”
themselves, although they should also be taken into account by the various other decision-makers (such
as those involved in the preparation of IT Strategies) that may have a role to play in the overall
procurement process in “customer” organisations.1
1.1 What is accessibility?
“Accessible” ICT products and services are those that are designed and implemented in a way that
allows disabled people or older people to use them in the same way as anyone else, irrespective of their
disabilities or age-related changes. From a procurement point of view, two main requirements need to
be addressed in order to ensure the accessibility of the ICT being purchased:
· “design for all” (where the product or service is designed to take as wide a range of users and
circumstances as possible into account)
· “connectability” (where the product or service includes a capability of being connected to the
assistive devices that may be needed by some disabled people or older people in order to use them).
These two approaches include accessibility as part of any procurement of ICT intended for general use
by employees or the public, and are the main way to address accessibility in public procurement of ICT.
1.2 Equipment and services for use by the general public
In Europe today a large and growing percentage of the population (about 20% or almost 80 million
people) are aged 65 years or older, have a disability, or both. Any public sector organisation that
provides ICT-based services aimed at the general public has a duty to ensure that such services are
accessible to all citizens. Sometimes such services are delivered via equipment (e.g. public
information kiosks) that has been procured and provided by the organisation itself. The design,
development or delivery of the service may also involve the procurement of services (e.g. Web site
design) from suppliers. In these cases the customer has a duty to ensure that the procured equipment
and/or services are accessible to all. This can only be achieved by including accessibility requirements
within the specifications for the equipment or services being procured.
1.3 Equipment and services for use by staff
The first point to note is that many staff - in fact, many more than the organisation is likely to be aware
of - will have accessibility requirements at any given point in time. Procurers may traditionally have
taken a quite restricted view of what accessibility entails, viewing it as something that applies only to
people who have very obvious visual, hearing or mobility impairments. However, the proportion of the
workforce with accessibility requirements covers a much wider range than this and, in fact, some level
1
The terms “customer” and “procurer” are used throughout this document as follows:
• customer refers to the organisation procuring the ICT systems and services
• procurer refers to the person or team within the customer organisation who is responsible for, and
carries out the specific procurement in question.
1of disability can be expected as a natural element of almost everyone’s life cycle. This includes older
workers who may experience changes in their sensory, motor and cognitive abilities, people with
temporary impairments such as having broken an arm or having forgotten one’s spectacles, and anyone
who happens to be in certain situations which may cause transient difficulties, such as noisy
environments.
First, there are employees with obvious disabilities and who are (usually) part of the group classified as
“disabled” in official statistics, such as people who are blind, deaf or use wheelchairs. Recent estimates
indicate that people classified as disabled make up about 7% of the total working age population.
Therefore, in a fair employment market this percentage of the public sector workforce might be
expected to belong to this category of disabled people.
Second, there are the many employees with less obvious disabilities and who are (usually) not classified
as “disabled” in official statistics, many of whom also have accessibility requirements. These include
the many older workers who are experiencing the visual, hearing and other changes associated with
ageing, many younger workers who also have relatively minor and often invisible impairments, and
people with temporary disabilities due to accident, illness or circumstances.
Third, certain work environments will cause accessibility difficulties for all workers who are subjected
to them. Visual and auditory signals and information can be masked by the surrounding environment
and in difficult performance conditions. Many employees in hands busy, eyes busy, or noisy
environments can benefit from the more flexible, user-friendly interface alternatives that have already
been adopted by people with disabilities. Where critical task information is at stake, such as in air
traffic control, detailed consideration is already being given to ensuring maximum accessibility. In less
critical environments, such as routine office work, accessibility is no less important. It improves task
performance, reduces fatigue and strain injuries, and allows all age groups to perform to their best
capabilities.
Although reliable statistics are hard to find, it is probably reasonable (if a little conservative) to suggest
that somewhere between 10% and 15% of public sector employees are likely to have some level of
accessibility requirements at any point in time. In fact, these figures are likely to increase in the future
as a result of demographic and labour market trends. The rapid ageing of the European population will
significantly increase the number of older workers and, due to labour market shortages, is also likely to
increase the number of disabled people at work.
Including accessibility from the start is most cost-effective
The most cost-effective way to address the needs of the groups of people mentioned above is to take as
many of them as possible into account in all general procurements of ICT. In this way it can be ensured
that all workstations and ICT systems and services used by staff have, from the start, the accessibility
features that may be needed by any member of staff who is confronted with a disability for whatever
reason. Otherwise, there will be a need to re-configure and possibly to upgrade a significant percentage
of workstations on a frequent basis. When accessibility is built-in, accessibility features are not extras
to be costed or procured as extras.
Taken in the context of the Total Cost of Ownership of PCs and other equipment, this approach makes
sound financial sense. It means that staff with accessibility requirements can move from workstation to
workstation, without the need for upgrades or new add-ons, and with little or no re-configuration. In
concrete terms, it means that addressing accessibility requirements whenever they arise will not add to
the usually 60% or more of the Total Cost of Ownership of a PC that goes to internal and external
support. Typically, organisations seek to minimise these costs by introducing corporate standards that
specify what equipment is to be used by staff. They do this to reduce the variety of end-user equipment
and the high support costs that this gives rise to. In the same way, the need for special add-on
equipment should be minimised by including as many accessibility features as possible in the ICT
systems when they are initially purchased.
Of course, it may sometimes be the case that the initial outlay for workstations or other equipment with
built-in accessibility features may be a little higher than what would otherwise be the case. This is more
2likely where the purchasing policy has traditionally focused primarily on performance/price criteria and
paid little attention to ergonomics. However, even this relatively limited cost increase might not
materialise. It can be argued that the current pricing of particular PC configurations, for example, bears
little direct relationship to the actual cost of at least some of the constituent elements (such as the
number of expansion slots and ports). If a large scale public purchaser specified enough slots and ports
to meet the connectability requirements of accessibility to be their minimum specification it is hard to
envisage them being unable to encourage suppliers to deliver these at a competitive price. In the same
way, higher ergonomic specifications could be expected to become more standard and more
competitively priced if they were to become the minimum specification for big purchasers.
Other benefits
There are also a number of hidden savings associated with the approach of ensuring built-in
accessibility in all ICT equipment and services. For example, more user-friendly interfaces improve
work performance and efficiency all round, but particularly in groups at risk of being hampered by
major or minor disabilities. Generalised accessibility of equipment also facilitates programmes for
active disability management aimed at promoting labour-force retention and reducing the costs of
compensation, retraining and absenteeism.
A proactive accessibility approach can build on existing health and safety, human resource, and
occupational health programmes by ensuring co-ordination of existing elements. Procurement of ICT
with built-in accessibility should be part of this. It can contribute to better usability and ergonomics for
all and help to reduce occupational injuries such as Repetitive Strain Injury (RSI) and the associated
disability compensation costs, and human resource costs in recruitment, retraining and lower job
satisfaction.
1.4 Fulfilling wider public policy goals
Apart from their own immediate interests and their direct public service/mission, public sector
organisations also have a role and responsibility in contributing to wider public policy goals and
objectives. In this regard, either directly or indirectly, accessibility of ICT is gaining a prominent
position in a number of policy areas.
The European Commission has now begun to focus attention on how these and other areas of public
policy can be supported through public procurement; the rationale for this being the considerable
influence that public procurement can wield in the market place through its purchasing power. In the
near future the Commission plans to clarify how such broader public policy goals can be pursued in
actual procurement practice.
1.5 About this guideline
This guideline is intended primarily for use in procurements of PC systems to be used internally in
public (and private) organisations. The end-user target group is mainly employees, but the guideline is
equally applicable for students in schools and universities. It provides recommendations on mandatory
and desirable accessibility requirements for those products and services of PC-based systems that the
end-users operate or use, i.e.:
• PCs;
• standard basic application software (word processor, spread sheet, web browser etc);
• standard packages of business specific software (payroll systems, sales support systems, CAD/CAM
etc.);
• development of software tailored for the customer;
• training, documentation and support; and
• the capacity of the supplier.
The requirements are intended to be reasonably balanced between
• the need for a more user-friendly information society;
3• end-user requirements for accessibility, as stated in current design guidelines for accessible ICT
equipment;
• procurers’ and suppliers’ need for easy-to-use tools, including requirements that are easy to
understand and evaluate;
• the economic objective of public procurement; and
• the need to avoid distorting competition.
2. Accessibility in procurement of PCs
ICT systems of today are based on what is called a technical platform, i.e. a set of interoperable system
components such as processor, bus, operating system, database management, programming language
etc., manufactured by different suppliers and complying to open formal or de facto standards. Today,
PC compatible personal computers with Microsoft Windows as the operating system is the prevalent
platform in the public sector for desktop computer equipment.
This guideline is based on an assumption that the major part of the personal computer procurements of
the foreseeable future will be about PCs with Windows. The requirements and recommendations stated
in this guideline are, however, applicable also for procurements of personal computers or terminals for
other platforms.
The accessibility of a particular ICT system is a combination of the accessibility features provided by
the hardware, the technical platform and the application software. The platform should include as many
features as possible which promote accessibility. This is of benefit both for the end-user and for the
application developer. The end-user will get a user interface with accessibility features common to
many applications, while application software manufacturers will not need to build these features
repeatedly in each application program.
PCs today represent a homogeneous market segment and a well standardised product group. They are
interchangeable commodities and many are assembled out of standard third party components rather
than being manufactured. In general, any software developed to run under Windows can be executed on
any PC-compatible computer. The currently prevalent versions of Windows have a number of built-in
accessibility features, a design issue which leaves a certain amount of freedom for competition and
supplier characteristics. Evaluations of PCs carried out in Sweden over the last few years show that the
accessibility quality of PCs with Windows has improved increasingly. Today, most major PC models
satisfy basic accessibility hardware requirements. However rapid turnover of staff with developed skills
and local assembling imply that it can not be presumed that this situation will remain permanently.
Therefore it is necessary to include basic accessibility requirements in the call-for-proposal.
Accessibility guidelines, with requirements on how to design accessible ICT hardware and software, are
developed and published by a number of organisations in the disability community. Usually the
guidelines emphasise that the requirements are beneficial to a much wider group of users. For the PC
market, ACCENT has identified two guidelines which have come into use in the ICT business:
• Nordic Guidelines for Computer Accessibility (1998), Second Edition, produced and published by
Nordic Cooperation on Disability2. The intended users are ICT strategists, purchasers, standardisers,
developers and manufacturers. The publication is divided into two parts. Part I describes what is
meant by accessible 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 meet the need for accessibility of personal computer systems operated by the end-user. The
requirements of the first edition (1993) have been included in procurements for framework
agreements on personal computers for the Swedish public administrations, carried out by the
Swedish Agency for Administrative Development.
• “PC98 System Design Guide, Version 1.0 September 5 1997”, a guide co-authored by Microsoft
Corporation and Intel Corporation, is aimed at those who intend to manufacture personal computers,
2
The publication is available at http://www.nsh.se/in_english/publications.htm.
4expansion cards and peripheral devices to be used with the Microsoft Windows 98 and Windows
NT version 5.0 operating systems. Appendix C of PC98 is a guide with recommended accessibility
features supported by the Windows family of operating systems. These guidelines were developed
in consultation with the Trace Research and Development Center at the University of Wisconsin,
USA, and were based on research funded by the National Institute for Disability and Rehabilitation
Research (NIDRR). Equivalent recommendations are included in the corresponding PC97 for
adherence to Windows 95 and Windows NT. The guidelines are recommendations and will not be
made mandatory.
2. Recommendations on PC procurement
2.1 ACCENT recommends the procurers to include the requirements in Appendix 1 as mandatory.
2.2 For PCs, ACCENT recommends the procurers to include the following requirements as desirable:
• The system components should, where the product is covered by the guide, follow the requirements
and recommendations given in PC98 System Design Guide, version 1.0, September 5 1997
Intel&Microsoft
http://www.microsoft.com/hwdev/pc98.htm ) and, where relevant, subsequent revisions.
• The PC hardware on offer should comply with the entirety of Appendix C of the PC 98 System
design Guide or Nordic Guidelines for Computer Accessibility (1998), Second Edition, published
and produced by Nordic Cooperation on Disability.
2.3 For personal workstations other than PCs, ACCENT recommends that procurers include the
following requirements as desirable:
• The system components should comply with existing standards and follow the requirements and
recommendations issued by the provider(s) of the technical platform.
• The PC hardware on offer should comply with the entirety of Nordic Guidelines for Computer
Accessibility (1998), Second Edition, published and produced by Nordic Cooperation on Disability.
2.4 Where a system is purchased with the expectation that it will now or in the future be used by a user
who needs an assistive device, ACCENT recommends the procurer to purchase a system with
several conventional serial ports, parallel ports, Universal Serial Bus ports and expansion slots.
2.5 The procurer is recommended to consult section 4 for requirements on training, documentation and
support.
2.6 The procurer is recommended to consult section 5 for requirements on the supplier.
In Appendix 1 to this publication, ACCENT provides, with the permission of Nordic Cooperation on
Disability, a set of requirements primarily based on the Nordic Guidelines for Computer Accessibility.
Evaluations in Sweden have shown that these requirements are satisfied by an adequate number of
suppliers, and therefore do not distort competition. They are not imposing any additional costs and, in
the evaluation phase, can be verified by use of basic knowledge of ergonomics - profound expertise is
not necessary.
Some procuring entities prefer to purchase components and assemble them as ready-to-use systems in-
house. Others prefer to purchase packages which are installed by the supplier and configured into a
turnkey system. In other words, the system integrator could be internal or external. The system
integrator has a key role for the overall accessibility of the system. The components need to be
interoperable with respect to accessibility, in particular, for users who need an assistive device.
Therefore, system components should stringently comply with existing standards and follow the
recommendations issued by the platform provider(s). Most assistive devices and software base their
interaction with the system on the assumption that the conventions for the technical platform are
followed.
53. Software accessibility
3.1 Usability
There are many quality aspects of software. ISO/IEC 9126:1991 (Information Technology - Software
Production Evaluation - Quality Characteristics and Guidelines for their use) defines six desirable
product quality characteristics: functionality, reliability, usability, efficiency, maintainability and
portability.
Most of these characteristics are related to business needs, while one in particular - usability - is related
to end-user needs. Usability is defined as "The extent to which a product can be used by specified users
to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”
(ISO 9241 Ergonomics requirements for office work with VDTs Part 11 - Guidance on usability
specification and measures). Effectiveness is the accuracy and completeness with which users achieve
specific goals. Efficiency is the resources expended in relation to the accuracy and completeness with
which users achieve goals. Satisfaction is the comfort and acceptability of use.
The usability of a system is context dependent. It is determined by:
- the user interface, including documentation, online-help, user support etc;
- user knowledge, experiences and way of thinking;
- work task and organisational context.
Accessibility and the concept of "Design for All" are strongly linked to the concept of usability in that
the implementation of accessibility requirements and principles requires proper consideration of
usability and therefore shares methods and tools with usability engineering. Furthermore, all three
aspects of usability are relevant for accessibility.
Usability is increasingly considered as an essential factor for improving the productivity of work with
ICT systems. Products with good usability are found to be more efficient, easier to learn, less
complicated to operate, and are less likely to be under-used or misused. Good usability reduces hidden
costs such as looking for help, need for support, effects of IT-related stress, etc.
The concept of usability is closely related to the concept of user-centred design. User-centred design is
an approach to design in which a high level of usability of the end product is an important objective.
User-centred design normally involves a number of key activities throughout development, including
user involvement, obtaining feedback on the design and use of the system, providing prototypes for
users to try out and re-designing as a result of user feedback.
A number of methods, tools and standards can be applied by software developers in order to ensure
good usability, including accessibility, provided that the specified users include "all" users, i.e. users
within the widest possible range of abilities and preferences. Appendix 3 of this publication lists a
number of standards that are related to usability and user-centred design. A network of organisations,
European Usability Support Centres, has been established for the information engineering industry.
These centres provide state-of-the-art usability services to support the development of systems which
meet users’ needs. Some of the centres are active in the accessibility field and may be approached for
provision of expertise. For more information, the reader is referred to the web site at
http://www.npl.co.uk/inuse.
Due to the context-dependent nature of the concept of usability, there is no list of generic, measurable
usability requirements suitable for direct application or referral to in procurements of existing products.
However, where end-user acceptance is a prerequisite for a successful choice of product, the procurer
may state a requirement on an accessibility goal and specify the usability assessment tool with which
the satisfaction of the goal will be measured. Examples of accessibility goals are:
• 95% of users should be able to perform task X at the first attempt.
• A blind user, using a Braille Display, should be able to perform task X.
• Not more than 2% of the users should need to call the helpdesk for support.
6ACCENT has not found it possible to recommend one method over another. Procurers should be aware
that many usability assessment tools need the involvement of usability experts for interpretation of
results.
3.2 Accessibility
The methods and tools developed for usability engineering provide basic usability qualities that
facilitate the use of software by all end-users. But they do not necessarily address accessibility issues to
a sufficient extent. For that purpose, a number of accessibility guidelines have been developed to assist
the software developer in producing accessible software, satisfying the two complementary components
of the concept of accessibility, which are:
• to design a product so that it is as usable as possible to the greatest number of people - without
requiring them to use special adaptive software or hardware.
• to design a product in such a way that it will work with special access features built into the
operating system or attached to it by users who require them.
Most of the guidelines provide a set of basic principles and a comprehensive set of detailed
recommendations, divided either by functions of the software or by various kinds of disabilities.
Examples of guidelines are:
• Microsoft Windows Guidelines for Accessible Software Design
(http://www.microsoft.com/enable/dev/guidelines.htm)
• Eric Bergman, Sun Software and Earl Johnson, Sun Microsystems Laboratories, Towards
Accessible Human-Computer Interaction (http://www.sun.com/tech/access/updt.HCI.advance.html)
• Vanderheiden, G. C., (1991). Making software more accessible to people with disabilities.
University of Wisconsin-Madison, Trace Research and Development Center (http://trace.wisc.edu)
• US Department of Education (http://gcs.ed.gov/coninfo/clibrary/software.htm).
• IBM Corporation (1998) IBM Guidelines for Writing Accessible Applications Using 100% Pure
Javatm (http://www.austin.ibm.com/sns/access.html)
At present, there are no formal or de facto standards specifically addressing software accessibility. In
ANSI, the American National Standards Institute, work is in progress for a section on software
accessibility to be included in a larger multipart standard on human-computer interaction. The entire
standard is intended to apply across different systems and technologies, primarily focusing on office
computing software.
The basic accessibility requirements recommended by ACCENT to be used in calls-for-proposal for
application software is based on a specification issued by a user, the US Department of Education. The
specification provides the minimum accessibility requirements that application software must meet in
order to be used by all Department employees and customers. The Department states that "These
requirements are offered to demonstrate the accessibility needs that must be considered when designing
and developing software for the Department of Education. They address proven techniques for the
design of universally accessible software that can be used by individuals with or without a disability.
Software considered for use by the Department must execute in the standard operating environment at
the time of offering and be compatible with the accessibility tools, both hardware and software, in use
by the individuals with disabilities at the Department."
Appendix 2 is a reproduction of the US Department of Education accessibility requirements, slightly
rephrased in order to be directly applicable in a procurement.
3.3 Accessibility in procurements of basic application software
This section discusses how to ensure the accessibility of the basic application software, i.e. the word
processor, web browser, spreadsheet program, etc., selected for use throughout the organisation.
7During the last few years, the concept of Total Cost of Ownership (TCO) has come into focus. The
TCO model developed by the Gartner Group is frequently referred to. This model identifies four main
cost areas: capital costs, technical support, administration and end-user operations. Based on this
model, it is estimated that the investment of hardware and software is less than 30% of the total annual
cost, while more than 70% is spent on work-related costs, e.g. the time where end-users attend training
courses, call helpdesks, discuss with and help colleagues.
One frequently used way of reducing the end-user costs is to standardise the hardware and software to
be used throughout the organisation, i.e. all employees who use a personal computer should have the
same basic application software. Measures are often taken to prevent users from installing other
versions or additional hardware and software. The unification of equipment, and the increasing mobility
of office workers due to new flexible work patterns, re-emphasises the need for inclusion of
accessibility requirements. Individual needs for adaptations due to lack of accessibility will otherwise
incur increased ownership costs.
The choice of basic application software is based not only on functional and performance but more on
criteria such as compliance with standards for effective communication and information exchange with
customers and subcontractors, investment in competence, price, supplier credibility, etc. The purchase
of basic application software will therefore be influenced only marginally by the technical requirements
of functions and performance.
Since basic application software is an essential work tool for the employees, accessibility should be
included in the criteria for choice of supplier. If the choice is made by a complete call-for-proposal, the
requirements given in Appendix 2 should be included in the requirement specification. If the choice is
made based on an established corporate technical framework, accessibility should be included in the set
of criteria for suitable software selection. The requirements in Appendix 2 could then be used as a
checklist for evaluating what the suppliers offer in terms of accessibility.
A more quick-fire approach, which only provides a certain probability that a chosen program satisfies
basic accessibility requirements, is to choose a program from a supplier committed to the inclusion of
accessibility features in their products. Suppliers may have adopted a corporate accessibility policy
and/or use a certain guideline for software accessibility in their software development process.
83.3 Recommendations on basic application software procurement
Comment: The accessibility of work tools such as basic application software that are universal to the
customer, is vital for the productivity of the staff. ACCENT however recognises that the choice of basic
application software is often made beforehand, i.e. in a corporate ICT policy. The purpose of a
procurement will in this case be to find the best supplier. ACCENT recommends the customer to
include the requirements stated in Appendix 2 in the process of elaborating the ICT policy.
3.3.1 Where the purpose of the procurement is to select both a brand and a supplier, ACCENT
recommends the procurer to include the requirements stated in Appendix 2 as mandatory.
3.3.2 Where the purpose of the procurement is to select both a brand and a supplier, it is in principle
desirable that the software fully complies with what is stated in a software accessibility design
guideline. However, the existing design guidelines (see section 3.2) are not written in a way that
makes them directly applicable in procurements. The emerging ANSI standard may become a
more directly applicable alternative. At present, ACCENT recommends the procurer to consult a
design guideline and, where possible, include the following requirement as desirable:
• The product should be designed according to the advice given in an established accessibility design
guideline, e.g. . The supplier should state whether this or another guideline
was used in the development of the product.
3.3.3 Where end-user satisfaction and acceptance is a crucial factor, ACCENT recommends the
procurer to consider the inclusion of the following statement:
”In the evaluation of proposals, a test panel may be established for giving subjective assessment
of the overall accessibility of the product. The accessibility goal will be , and the assessment will be made by use of the usability assessment
tool specified in ”.
3.3.4 The procurer is recommended to consult section 4 for requirements on training, documentation
and support.
3.3.5 The procurer is recommended to consult section 5 for requirements on the supplier.
3.4 Accessibility in procurements of business specific standard application software
There are many specific business applications, common for many organisations, and supported by
standard software packages available on the market. Examples are accounting, payroll systems, sales
support, CAD/CAM, information retrieval, etc. Such application software must be chosen to be well
adapted to the specific business and user requirements of the organisation. The choice is usually based
on internal factors, and the result of a complete call-for-proposal procurement. It is essential to consider
whether the requirements could be satisfied by a product already available on the market or a specific,
tailored software need to be developed. Many organisations have adopted a strategy to initially acquire
off-the-shelf application software to avoid the costs and risks associated with the development of
entirely new software solutions.
Accessibility should be included in the criteria for selecting suppliers of business specific software. The
requirements given in Appendix 2 should be included in the requirement specification.
Adaptations and additions to standard software packages, for example an "accessibility shell", are
disadvantageous, in that they may aggravate maintenance and upgrading to new versions. Suppliers
usually require that the customer upgrades the software, in order to ensure maintainability. The
9customer will have to pay for the subsequent upgrading of the adaptation or added software, and cannot
require the supplier to include the adaptation in the standard software even if it is not customer-specific.
Consequently, it is preferable that accessibility features are included in the initial purchase.
3.4 Recommendations on procurement of business-specific standard application software
3.4.1 ACCENT recommends the procurers to include the accessibility requirements stated in Appendix
2 as mandatory.
3.4.2 It is in principle desirable that the software fully complies with what is stated in a software
accessibility design guideline. However, the existing design guidelines (see section 3.2) are not
written in a way that makes them directly applicable in procurements. The emerging ANSI
standard may become a more directly applicable alternative. At present, ACCENT recommends
the procurer to consult a design guideline and, where possible, include the following requirement
as desirable:
• The product should be designed according to the advice given in an established accessibility design
guideline, e.g. . The supplier should state whether this or another guideline
was used in the development of the product.
3.4.3 Where end-user satisfaction and acceptance is a crucial factor, ACCENT recommends the
procurer to consider the inclusion of the following statement:
”In the evaluation of proposals, a test panel may be established for giving subjective assessment
of the overall accessibility of the product. The accessibility goal will be , and the assessment will be made by use of the usability assessment
tool specified in .”
3.4.4 The procurer is recommended to consult section 4 for requirements on training, documentation
and support.
3.4.5 The procurer is recommended to consult section 5 for requirements on the supplier.
3.5 Accessibility in procurements of software development
In some cases the option of developing a tailored software solution is justified, and there are limited or
no resources to develop it in-house. The key issue of the procurement of a supplier for this development
is to evaluate the supplier’s capabilities to meet the stated business and end-user needs. Accessibility is
one of the needs that the supplier must be able to take into account in the development process. To
ensure this a user-centred design approach and a usability assessment tool could be used.
The supplier should be required to have at his disposal, either in-house or externally, the capability to
apply
• a software development approach that involves the end-user as a stakeholder, i.e a user-centred
design approach;
• current standards, methods and tools for usability and user-centred design. of software;
• current guidelines for design of accessible software.
The developers should be encouraged to use the accessibility guidelines in their entirety, thus
maximising the accessibility of the software to be produced. It costs little or nothing to include
accessibility features from the outset, while adding features or modifying a completed software program
subsequently is costly and inappropriate. Thus, accessibility requirements should be included in the
early phases of the software development, where all the requirements are to be determined.
103.5 Recommendations on software development procurement
Standards, guidelines and informative documents on usability provide methods and tools for making
accessible software, while guidelines and informative documents on accessibility provide the attributes
of accessible software.
3.5.1 ACCENT recommends the procurers to include the following requirements as mandatory:
• The supplier shall apply a User Centred Design approach, such as the one given in ISO 13407.
• The supplier shall apply relevant existing standards related to software ergonomics, such as ISO
9241, ISO 9126, ISO 14598-5.
• The supplier shall apply a design guideline on software accessibility, for example
- Microsoft Windows Guidelines for Accessible Software Design
(http://www.microsoft.com/enable/dev/guidelines.htm)
- Eric Bergman, Sun Software and Earl Johnson, Sun Microsystems Laboratories, Towards
Accessible Human-Computer Interaction
(http://www.sun.com/tech/access/updt.HCI.advance.html)
- Vanderheiden, G. C., (1991). Making software more accessible to people with disabilities.
University of Wisconsin-Madison, Trace Research and Development Center
(http://trace.wisc.edu).
• The supplier shall make use of the accessibility features and tools that are provided by the platform
provider.
• The software to be developed shall, as a minimum, comply with the requirements stated in
Appendix 2.
3.5.2 ACCENT recommends the procurers to include the following requirements as desirable:
• The supplier should provide assistance to the user regarding installation and set-up of the developed
software to ensure full benefit of the built-in accessibility features.
• The supplier should give one or more references, where the supplier has applied a user-centred
design approach.
3.5.3 The procurer is recommended to consult section 5 for further requirements on the supplier.
Furthermore, the software developer should make use of the application programming interfaces
("hooks") provided by the platform provider which facilitate third party manufacturers of assistive
technologies to develop assistive software and hardware. For example, Microsoft’s Active Accessibility
is a set of conventions for how applications can communicate with assistive software and hardware,
using a set of files that are installed on the computer and extend the operating system. Active
Accessibility enables object-oriented applications to send information to the assistive aid about where
the onscreen location of object and its purpose or role. This information is standardised, which enables
assistive products to work with any application that supports Active Accessibility.
Another example is a set of Java software development kits produced by IBM Corporation and Sun
Microsystems Inc., allowing application objects to export accessibility information about themselves to
assistive technologies. IBM and Sun have jointly developed an application programming interface for
accessibility features. This interface is implemented on their Java Foundation Classes, which are the
building blocks for Java developers. Also included is a mechanism which allows developers of
application software and assistive products to add alternative user interfaces such as audio output and
voice input. Webpages to be consulted are:
11• http://www.microsoft.com/enable/ and subsequent pages
• http://www.sun.com/tech/access/ and subsequent pages
• http://www.apple.com/disability/ and subsequent pages
• http://www.austin.ibm.com/sns/access.html
4. Accessibility of services connected to a PC system
4.1 Training
Many application software suppliers provide videotapes or other multi-media training material. In
addition, training courses are provided for major software products, either by the supplier or by third
party training providers.
The complexity of modern software makes training an essential element for efficient use of the
software, and training providers should be strongly encouraged to make their training material and
courses accessible, including provision of physical access to the course premises. The training material
for end-users must be accessible, i.e. it must be designed for end-users within the widest possible range
of abilities. Videotapes with open or closed captions, and separate audio tracks where actions taking
place on the screen are described, are possible ways of making the training material accessible for
people with reduced hearing or visual abilities.
4.1 Recommendations on training procurement
4.1.1 ACCENT recommends the procurers to include the following requirements as mandatory:
• The supplier shall demonstrate the extent to which his training material and training courses for the
products on offer are accessible for end-users within the widest possible range of abilities.
4.1.2 ACCENT recommends the procurers to include the following requirements as desirable:
• The training materials and training courses should be provided in different forms, enabling trainees
to access the training material and attend the courses according to the abilities and preferences of
the trainee.
• The supplier should provide, or refer to third party suppliers for, training courses which include the
accessibility features of the offered products.
124.2 Documentation
The complexity of today’s software makes documentation essential for the user’s productivity. On-line
documentation is today prevalent in application software, and it is of course necessary that the on-line
documentation is not less accessible than the application itself. The same accessibility requirements
should therefore be made for the on-line documentation as for the application software. The user
interface should be consistent with that of the application, i.e. the same technique for navigation, object
operation and selection of functions should be used.
Printed documentation will still be needed, as it in many ways complements the on-line documentation.
The text should be available in ASCII, which enables output in other fonts and sizes as well as in other
modes such as speech or Braille.
4.2 Recommendations on documentation procurement
4.2.1 ACCENT recommends the procurers to include the following requirements as mandatory:
• On-line documentation giving instructions, help, explanatory information and advice shall be
provided.
4.2.2 ACCENT recommends the procurers to include the following requirements as desirable:
• The on-line documentation should satisfy the accessibility requirements in Appendix 2.
• The printed documentation should have a binding that allows the book to lie open and flat on the
desktop.
• The text of the printed documentation should be available electronically in ASCII.
• Text descriptions of graphical information should be provided.
4.3 Support
Any end-user is an expert on his/her own abilities, preferences and needs for accessibility features.
However, not all individual end-users can be experts on those facilities of the system that may meet
their needs and preferences and compensate for reduction of some ability. The end-users need support.
This could be provided by in-house experts, by the supplier of the particular system, or be procured
from a third party supplier. This section mainly discusses primarily situations where either the system
supplier or a third party supplier provides the support.
Support is needed in two respects. The first regards the accessibility features that are built as standard
features into the products on offer. To fully benefit from these features, they must be known to the user,
the appropriate options should be selected and certain parameters properly set. This is done at the
installation of the system and ideally the supplier should be able to assist each individual in this phase.
If the documentation is complete and easy to understand, the user may well be able to select the right
options and set the parameters without assistance. For long-term contracts, the supplier should be
required to provide ongoing support, to monitor the development of ICT accessibility and be able to
implement new features and technologies.
The second concerns assistive devices and software. There are countless examples where these are
incompatible with one version of an application software but co-operates well with another. A study by
the Swedish Handicap Institute on screen readers for graphical user interfaces3 showed many product
deficiencies. (A screen reader is a device which transforms the information presented on the visual
3
CESAR - Comparative Evaluation of Screen Alternatives for Reading. The Swedish Handicap
Institute and The Swedish National Labour Market Board, 1996
13display to speech or Braille.) The issue of compatibility between an assistive device and its environment
is to be tackled both within the complex organisational implications that follow from migration of
legacy systems, and the task of keeping a system coherent and balanced as technology and user needs
change. Ideally, the supplier of the system should have a broad and deep expertise in interoperability
issues for the most common types of assistive devices. This is however not realistic, since there are too
many specific individual cases.
There are a number of support tasks that should be covered in the call-for-proposal:
• Support at the installation phase: Operating systems and application software packages often
provide customisation facilities which meet many basic accessibility requirements. However, the
richness of features that modern software contain makes it difficult for an ordinary end-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 end-user has access to a support facility which can give
advice on how to install the software and how to set the appropriate parameters. Internal expertise
must have access to comprehensive support by the supplier.
• Current support: For a more complex system, it is likely that continuous access to a support
facility, e.g. a help-desk, will be required. The support facility should be able to tackle accessibility
issues throughout the life expectancy of the system, i.e. to assist by explaining how to operate
accessibility features and how to solve accessibility problems which may arise in cases of new
software releases, upgrading of hardware etc.
• Monitoring the technical development: New technologies may emerge which could enhance the
accessibility of a particular system. It is important that the supplier keeps abreast of the current
development in the field of ICT accessibility, in order to be able to implement new accessibility
features and offer them to the customer.
In the PC market, the support is often structured in three levels: the retailer, the national subsidiary of
the supplier, and the supplier. Some suppliers sell directly to end customers; the discussion below is
then applicable in relevant parts, as is the case where the supplier is domestic.
4.3 Recommendations on support procurement
4.3.1 ACCENT recommends the procurers to include the following requirements as desirable:
• The supplier should provide assistance service to the user regarding installation and set-up of the
system to ensure full benefit of the built-in accessibility features.
• The supplier should provide a facility, e.g. a help desk, for support on accessibility issues. The
facility should be easily accessible by end-users.
• The supplier should follow the development of technology and accessibility, implement new
features for enhancement of the system’s accessibility and offer these features to the customer.
• Where applicable, the supplier should have a support programme for retailers of the offered
products, regarding accessibility features of the products. The programme should include training
material or courses on accessibility, and a staff member assigned responsibility for accessibility
issues, so the retailer can refer problems that he is unable to solve.
• Where applicable, the supplier should acquire knowledge of the accessibility policy of the parent
company and establish a contact with the accessibility officer (if any) at the headquarter.
The first level, the retailer, is the customer’s partner and is therefore responsible for solving the
customer’s problems, including accessibility problems. Since the life cycle of modern on-the-shelf PC
hardware and software is rather short, the retailer cannot be required to have more than a basic
knowledge of the accessibility features of the current products. The retailer should be aware of the
concept of accessibility, aware of efforts made by the suppliers to make their products accessible and
14assess his capacity to solve the customer’s problem correctly. The retailer should also have full
knowledge on how to forward the problem upstream in the support chain.
The second level, the national subsidiary of the supplier, is responsible for training the retailers on his
products, including their accessibility features. One member of the supplier staff should be assigned
responsibility for accessibility issues, in the same way that staff are assigned to security and
environmental issues. This person should have direct contact with accessibility expertise at the third
level, the headquarters.
5. Requirements on the supplier
5.1 Competence and organisation.
Accessibility is one of the issues that the supplier and the customer need to tackle during the life cycle
of the system. Problems may occur both at the general and the individual level and most suppliers and
customers have come across desktop systems where adaptations for individual disabled end-users have
been made. However the knowledge of and ability to deal with accessibility as a generally desirable
characteristic of ICT systems is limited at present, both on the side of the supplier and the purchaser.
Due to US legislation on accessibility, some US-based world-wide companies have nevertheless an
organisation unit or staff assigned to accessibility issues, for example IBM, Microsoft, Sun and Apple.
Consequently, European subsidiaries of these companies have access to expertise on accessibility.
Accessibility should become a profession in the ICT field, like other horizontal ICT areas such as
security, ergonomics and environmental protection. It is essential that the procurer
• rewards those suppliers who have a record of achievements on accessibility,
• encourages suppliers without a record to put accessibility on their agenda, and
• attempts to assess the accessibility knowledge and capabilities of the potential suppliers.
These issues may appear both in the selection of tenderers, prior to the invitation to tender, and in the
tendering process (the call-for-proposal and the in-depth evaluation of the received proposals).
5.2 Selection of tenderers
A public procurer may choose a restricted procurement procedure, under which only selected suppliers
may submit tenders for a contract. The selection of suppliers may be based, inter alia, on their technical
capacity, i.e. if they are adequately organised and skilled to perform the tasks to be contracted and if
their track record is satisfactory.
The EC rules and corresponding national laws on public procurement stipulate the means which may be
used for furnishing of evidence of technical capacity. The procurer shall specify, in the notice on
intention to procure, which references he wishes to receive.
ACCENT recommends the procurer to include, in all notices on intention to procure, accessibility in the
criteria for awarding.
For the procurement involving the selection of tenderers, i.e. procurements for a purchase sum
exceeding the EU thresholds, the procurer may request the supplier to submit
• a statement detaling his practical experience in providing accessible products and/or services,
• a track record on achievements on accessibility for previous customers,
• evidence and experience of relevant staff training.
5.3 The tendering process
In procurements above and below the thresholds, the procurer may request the supplier to assess
himself using take-up of accessibility as a gauge, for example the following, based on a study of how
15usability methods are used by Swedish IT system development companies (Katzeff, Cecilia; Svärd, Per-
Olof: Användbarhet i praktiken, en enkätstudie, SISU Publikation 95:20, November 1995):
Table 1. Alternatives for supplier approaches to accessibility.
1) The supplier has not come across accessibility issues and has no particular knowledge of
accessibility issues.
2) The supplier is aware of the need for accessibility, but the issue is not on the agenda. The supplier
has not found sufficient customer demand to establish a readiness for action. If an accessibility problem
arises, it will be solved from scratch.
3) The supplier is aware of the accessibility issue at large and is to some extent prepared for action. The
actions will, however, be taken on an ad hoc basis. The supplier may know of or have contact with
accessibility expertise externally or upstream in the company.
4) The supplier has competence and an organisation unit at its disposal, either internally or externally.
There is a commitment by the top management level to promote accessibility. One or more staff
members may be assigned to monitor the field of accessibility and have basic knowledge of the field.
Access to further expertise may exist upstream in the company, or the supplier may have an agreement
with an external expert who can act as a subcontractor.
5) Accessibility is one of the activities of the supplier. A corporate policy on accessibility is established,
enforced and well-known by the staff. A competent organisation unit is established in-house.
For alternatives 3, 4 and 5, the supplier should be required to provide evidence for his assessment by
describing, where applicable, the approach taken, the policy or commitment, the organisation, partners
and external experts.
For procurements of systems where a significant number of end-users can be expected to be dependent
on a high accessibility standard of the system, a supplier with an accessibility approach of level 3
should be a minimum requirement.
Outsourcing of an ICT-based activity to a third party supplier normally means that the responsibility for
the accessibility of the system and the services provided by the system stays with the organisation, but
the methods of how to provide accessibility is to be decided by the supplier. This requires that the
supplier has an approach to accessibility corresponding to at least level 4.
5.4 Quality assurance systems
Many suppliers have adopted a quality assurance system. Some are certified according to a standard,
e.g. ISO 9000. A quality assurance system is used to decribe all the planning, preparation, work,
checking and recording actions that are necessary to achieve the standard of product or service that the
customer needs. These actions are largely common-sense and good business and management practice.
Software developers in particular are often required to have a quality assurance system, to ensure that
the final product meets the specified requirements. A number of methods exist for quality management
and quality assurance of the different phases of software development. Examples are:
• ISO/IEC9000-3:1997 Quality management and quality assurance standards - Part 3: Guidelines for
the application of ISO9001:1994 to the design, development, supply, installation and maintenance
of computer software.
• ISO/IEC TR 15504: 1998 Information Technology - Software Process Assessment, a standard
which provides customers and suppliers with a single source for process definition and assessment.
• TickIT, a quality management system based on ISO9000-3. TickIT is the basis for certification of
software producers, and is implemented in the UK, Sweden and Norway among other countries.
16You can also read
