- Use accessibility standards and guidelines
- Specify a process, but not too rigidly
- Target specific users when necessary
- Take a wide view
- Consider maintenance and training
- New content
- Look for evidence of real understanding or commitment to accessibility by the suppliers
- Issues with subcontracting for larger projects
- Make documentation accessible
Use accessibility standards and guidelines
You will need to state the accessibility requirements as precisely as possible. Where possible, the requirements should reference appropriate accessibility standards or guidelines that suppliers can be instructed to adhere to. The toolkit provides sample texts describing the appropriate guidelines for different technology types.
Standards and guidelines are not always clear cut, however. They are often open to interpretation, sometimes inconsistent or incomplete and adherence may not even be fully achievable in certain situations. It may prove difficult to say categorically whether or not a product meets a standard. In some cases, there may simply be no products available that fully meet the appropriate standard. You should therefore try to adhere to the spirit of standards and guidelines. Follow them and measure against them where possible, but be prepared to use your judgement and do the best you can in your situation.
Specify a process, but not too rigidly
For bespoke software, hardware or other IT systems that are designed or configured to suit the purchaser's needs, it is not enough just to refer to functional or technical standards or guidelines. You should also request that an appropriate inclusive process be followed for the design and implementation. This may involve activities such as consultation with end users with disabilities, accessibility auditing and user testing.
You can either prescribe a specific process to be followed or ask suppliers to describe how their development process will ensure accessibility (or, in the case of off-the-shelf products, did ensure accessibility). If a competitive process is being used to assess suppliers, you should make sure all bidders cover accessibility in their presentations.
The best approach may be to suggest the required elements of a process but without being too rigid about it. If you are too rigid, you may constrain suppliers to taking an approach that would not work well for them or which they would have reasonable arguments against. For example, suppose you were to say that you want the supplied product to be evaluated by a user test with at least 12 users. A supplier with a lot of relevant experience might have good reason to suggest that a better approach for them would be to adopt an iterative process, involving a number of tests at intervals with fewer users in each. This would be a modification of your suggested process that you should consider. Remember that with design and development there are usually many possible routes to the same destination. The best route is often the one that fits best with the supplier’s unique expertise and experience.
Read more about a suitable user centred design and implementation process
Target specific users when necessary
As a general rule, Universal Design means considering all users equally, not designing for specific disabilities or specific assistive technologies. However, in some cases, where the target user group is restricted, it may be possible to specify a restricted set of accessibility requirements for example, where a product is being purchased for specific staff members to use and will not likely be used by others. In this case, the contract might specify those individuals’ abilities, the assistive devices that the application should be compatible with or features that need to be customisable. This approach will restrict the flexibility of the solution but may well reduce the cost of procurement.
Take a wide view
You should try to consider where accessibility issues arise in a wider sense, so that you don’t restrict what can be achieved or expect too much. Problems can arise if the parts of a service that make a difference from an accessibility point of view are out of scope of the procurement. For example, suppose a procurement is for the design of an accessible website to work with an existing content management system (CMS). There may be a fundamental problem in the CMS that prevents accessible content being produced. If so, no matter how good the website design is, the resulting website will not be accessible because the content produced by the CMS is not accessible.
A large system will consist of many parts, including database, back-end processing software, communications infrastructure and multiple hardware and software front ends for end users, administrators and content authors. Accessibility issues can arise in all these components. The system will require adherence to standards for multiple technologies, such as database content, Java I/O classes, HTML, terminal hardware, printed outputs, etc. If accessibility is overlooked in any single component, issues may permeate through the rest of the system.
Problems can also arise if the real accessibility requirements span several cost centres, such as consultancy, development and training, but the procurement only encompasses one of these.
Consider maintenance and training
It may not be sufficient to simply procure a solution that meets the accessibility standards on delivery. Content may change, technologies may change and users’ needs may change, so you will also need to consider how you are going to maintain the accessibility level that has been achieved.
This may mean a regular inspection and maintenance contract and/or staff training. Training may also be required for technical staff involved in the maintenance of the resource, content providers and helpdesk personnel. Consider adding training and monitoring to the requirements.
Content is an area where training and maintenance is particularly important and you will need to consider how the content production process will work with the procured solution.
Information systems, such as most websites, essentially deliver information ‘content’ to users. Not only does the delivery system have to be accessible (the hardware and software ‘user interface’), but the content also has to be accessible. This is often overlooked and content is written in a way that users cannot read or understand. Typical problems are jargon, lack of structural markup and missing or inadequate text alternatives. Sectors such as government often have their own ‘language’ that is familiar to people who work in that environment but may be impenetrable to outsiders. If content is written using insider jargon and phraseology, then the information it contains may be completely inaccessible to many users. Users of assistive technologies rely on correct structural markup of content (headings, subheadings, lists, etc.) to enable them to efficiently scan and navigate through large amounts of information. Blind users rely on alternative text descriptions being added to images that they cannot see.
The problem of content being inaccessible often lies in the content production process. Content is constantly being added, modified or replaced. Modern technologies make it easy for anyone within an organisation to produce content that can be added directly into the information system without the intervention of a trained production team. For example, web content is often written using desktop office software, such as Microsoft Word, and uploaded directly to the website using a content management system. If the content author does not have a good understanding of accessibility, problems may arise, such as images missing alternative text or having poor alternatives and missing or incorrect structural markup. There is a clear need for content authors to be trained in accessibility or at least placed under the editorial control of someone who is trained in accessibility.
Look for evidence of real understanding or commitment to accessibility by the suppliers
Although some suppliers have accessibility expertise, many do not, particularly in areas of technology where accessibility has not generally been considered. You cannot assume understanding or commitment to accessibility on the part of suppliers. The RFT should highlight the importance of accessibility and spell out the reasons for it as well as stating the precise requirements.
Issues with subcontracting for larger projects
Larger projects may involve more than one solutions provider. If some of these are subcontracted by one of the main contractors, then that subcontractor may have to deal to some extent with the specification and assessment of accessibility.
Make documentation accessible
The RFT, all contract documents and application forms should be accessible. This means using standard non-proprietary formats such as HTML, plain text and rich text (RTF), in place of or in addition to inaccessible formats such as PDF and Excel. Online forms should be in accessible HTML. Alternative formats, such as Braille, large print and audio can be made available on request, although accessible electronic documents ought to be sufficient.