3. Development and Implementation

For bespoke software, hardware or other IT systems that are designed or configured to suit the purchaser's needs, the procurement will involve a significant development and implementation phase. The award of the contract will have been made on the basis of a tender assessment process that should have included accessibility as a key consideration. The chosen supplier should therefore undertake the development and implementation phase with a clear understanding of the accessibility requirements and the appropriate user-centred inclusive development process. For guidance on a suitable process, read the principles of accessible procurement or the general accessibility process described in the NDA IT Accessibility Guidelines.

You will have your own procedures for monitoring and assisting with the development and implementation. Whatever these are, you should make sure that accessibility issues are covered. For example, accessibility should be an age NDA item in any regular meetings you have with the supplier.

Your input into design and evaluation

Gathering information about users

If the contract involves designing a new system with new user interfaces, it will be important to follow a user-centred design and development process. This will require you to participate by providing information about the users. You may need to identify key stakeholders for the supplier to consult with during the development process. The developers will need to know such things as:

  • Who will be using the new system?
  • In what circumstances?
  • What tasks will they be trying to perform?
  • Which are the most frequent or critical tasks?

You will be using the system to provide a service to your staff or customers and are best placed to provide this type of information. This is one of the most important roles you will play in the development and implementation of the service.
Unforeseen or unmet user requirements are one of the major causes of failure for large ITprojects. Accessibility requirements are an important part of user requirements so you should stress these. For example, if any of the following or similar statements are true for you, you should make sure to point them out to the supplier:

  • Many of the users will be older people;
  • Many of the users will have low levels of literacy in English;
  • The system is intended to be used by all members of the
    public;
  • Many of the users are likely to access this service via a
    dial-up connection;
  • Many of the users will not be familiar or comfortable
    with this type of technology.

The supplier may employ various techniques to capture and define user requirements. These may include, for example, focus groups and design personas. In a focus group, a number of representative users are invited to engage in a mediated discussion about their needs and the merits of various proposed solutions. If this technique is going to be used, you should ensure that the group includes members with access issues, such as older people or people with disabilities. Design personas are fictitious archetypal users who are given names, descriptions and personalities. They are often used to help designers focus on the users as real people rather than on abstract system functionality. If personas are being used, you should try to ensure that these include impairments that are likely to be found among your user population.

Read about a general consultation process

User Testing

User testing is an area where you can have a big input by providing representative users to test prototypes and delivered systems. At its simplest, user testing may consist of informal arrangements where a few individuals agree to come in on an ad-hoc basis whenever needed to “try out the new developments”. This, whilst not necessarily ‘scientific’, can provide very useful insight for a minimal outlay. Alternatively, user tests can be run in a more formal way, where a carefully chosen group of representative users who have not yet seen the system are asked to run through a prepared set of tasks in a more ‘laboratory style’ setting. This may be appropriate for evaluating the final delivery against the accessibility requirements set out in the RFT (see Evaluating Deliverables for more on this).

Formal user testing is a skilled job that should usually be left to the supplier or to a specialist user testing consultancy. The less formal method may be something you can do yourself. In any case, it may be very useful for you to build relationships with a few individuals with disabilities who can come in at various stages during the development and implementation process. This will give your development team a chance to meet with real users with disabilities. The insights they may gain from this can be invaluable.

Read more about involving users.

Anticipating Changes

Changes in systems and working practices can have significant consequences for accessibility. For example, individual adaptations and assistive technologies that enable staff to work within the current system may no longer work when the system is changed or the technology upgraded. This will have to be anticipated and planned for. Particular attention should be paid to situations where off-the-shelf products or systems need to be altered, tailored or upgraded to meet a specific business requirement. Existing accessibility features and technical compatibilities may be compromised by these changes.