Accessibility will not only need to be taken into account at the procurement stage but throughout the lifetime of the product. This includes during implementation, support and potentially within future upgrades. This needs to be made clear in the contract.
Myth: the cost of inclusive design
It is very likely that software designers and developers won't know about inclusive design principles and best practice guidelines. They will need help in understanding and applying the standards. The supplier is also likely to assume that inclusive design will significantly increase their development costs. But we know that fixing a poorly designed interface costs significantly more than designing inclusively from the start.
For example, some years ago the Department of Work and Pensions (DWP) in the UK introduced a new IT system without specifying that it should be accessible to access technology users. The head of the DWP's Accessibility Solutions Team says: "If accessibility for people using various kinds of access technology had been considered while the system was being designed, it would have saved a great deal of expense and time. What's more, an inclusively designed system would have been more accessible to and usable by all staff, not just those with disabilities."
On the other hand, if a supplier or customer has been assured by the software developer that their product is accessible, and this turns out not to be the case, then significant costs may well be incurred in trying to put the situation right.
Creating a Functional Specification
A Functional Specification is often created at this stage by the supplier's software analysts, who talk to users and to IT staff. This forms the basis for a more detailed description of the required functionality of the system, formalised in the contract. It is very important that the analysts speak both to accessibility experts and to users with non-standard access requirements.
Getting the standards right
Let us assume that a few high priority accessibility standards were included in the Requirements Specification for the procurement project. These statements will be the minimum requirements for an accessible system. We would always work towards a higher level of software accessibility and usability than would be achieved by applying only these minimum standards.
Published standards are difficult to interpret and apply, especially for those who are new to software accessibility. It is important for the purchaser to work with the supplier to agree on a tailored subset of accessibility statements, that both are happy to work with and adhere to.
Within RNIB, we base our procurement accessibility requirements on ISO 9241-171. However, we will always work with suppliers in every project to interpret, clarify and agree on the standards that are relevant to the project.
We always assign a priority level to every statement. Priorities are essential to allow the developers to work hardest on the most important standards and areas of the software.
What if accessibility can't be achieved?
It is possible that a product or service is not going to be fully accessible at the outset but has to be selected for other over-riding business reasons. Bidders should be invited to submit proposals for how accessibility is to be achieved.
If they cannot or do not wish to do this, consideration should be given to letting additional contracts for the provision of specific accessibility-related work. It would have to be made explicit to suppliers that they must allow access to the coding of their product, and to suitable test environments, to allow a different supplier to develop accessibility solutions.
Buyer beware
Lastly, beware of assurances that products 'are fully customisable' or 'will be fully accessible' without evidence to back this up. Treat accessibility as you would data security - would you simply accept a supplier's word that systems are secure from attack by unauthorised users or viruses, without suitable proof?