A good corporate IT strategy will include a policy about accessibility in software procurement, guiding purchasers on how they must take account of accessibility during a procurement project. These are some of the factors to consider when putting together an accessibility policy for procurement.
Accessibility in procurement projects
Accessibility must feature in almost every aspect of a procurement project:
The specification of requirements:
-
Tender documentation
-
Selection of supplier
-
Contract documents
-
The functional specification
-
Investigation of user requirements
-
Configuration to meet organisation requirements and business processes
-
Change control, impact assessment and risk management
-
User Acceptance Testing
-
Implementation and rollout
-
User training and training material
-
User manuals
-
Post implementation review
-
Support and maintenance contracts
-
The helpdesk and support functions
-
Upgrades and updates.
The project team
To ensure that accessibility has appropriate emphasis in a procurement project, it is essential that the leaders of the project understand why inclusive design is important. They also need to know what the impact of this will be throughout the procurement and project lifecycle. Without commitment at the highest level of the project steering group, efforts towards accessibility will fail.
This doesn't mean that accessibility has a greater priority than other business requirements. A judgement should be made on factors such as the importance of the software and the impact on users. If it is intended for use by cardiac surgeons in the operating theatre, then certain aspects of accessibility will have a lower priority. This would not be the case if it is intended to be used by the general public to book an appointment with a GP.
Hardware and the operating platform
The accessibility of a particular IT system being considered is a combination of the features provided by the hardware, the operating system or technical platform and the application software.
We tend to focus on the application software, but the hardware and technical platform should not restrict any aspects of accessibility either.
For example, speech or braille output will certainly not be possible if a terminal has no means of generating sound and no ports to connect a synthesizer, speaker or braille display. An operating system or other platform that does not offer a working screen reader or other access technology is similarly unsuitable in most situations.
The right standards
A policy for accessible software procurement must reference a suitable set of inclusive design standards or guidelines. There is currently no universally accepted global standard for comprehensive software accessibility and usability.
At RNIB we base our procurement policy on an international standard ISO 9241-171, but we pick out the specific statements that are relevant to the project in hand.
Further information on
Software accessibility standards.
COTS (Commercial off-the-shelf) software
Many commercial software products on the market already offer an accessible and usable interface. However, there are still some that do not, and this can create significant difficulties for disabled users.
Problems can also arise where commercial off-the-shelf products or systems are altered, tailored or upgraded to meet a specific business requirement. In this instance existing accessibility features and technical compatibilities may be compromised. The process of tailoring COTS products to business requirements must include consideration of the accessibility and usability of the resulting interface.
Bespoke software and software development
In some cases the option of developing a software solution from scratch is justified, whether using in-house capacity or external contractors. When procuring a supplier for software development, the supplier must demonstrate that they are capable of developing an accessible and usable application.
A user-centred design approach is recommended, and
a baseline of inclusive design guidelines or standards is essential right from the start. It cannot be assumed that suppliers know how to interpret standards or test for accessibility, and some expert input is likely to be needed until such knowledge becomes commonplace in the software development community.
Further information on
Software design and development.
It's not just the IT
Documentation, end user training or guidance, the helpdesk, system support and maintenance are also critical requirements.
The procuring organisation may need to take over support and maintenance of the product throughout its lifespan. Any accessibility adjustments that have been carried out during procurement will need to be documented, incorporated into user training, and sustained when any development is carried out. Procedures and maintenance contracts for updates and upgrades to systems must also include consideration of accessibility, so that standards do not degrade over time.
It's easy to forget about the end users during a complex procurement project, or to concentrate on users with one particular impairment, such as blindness. Particularly for public-facing systems, there will be users with all types of requirements and abilities. If steps have been taken to make a system accessible and usable that aren't obvious - special shortcut keystrokes for example - it may be necessary to point these out to users.
The way that users are introduced to new systems and given training can have a huge effect. If users feel that their needs have been considered and that the interface is intuitive, consistent and easy to use, then acceptance and productivity will be high.