Skills needed by procurers
- Why do you need skills?
- What skills do you need?
- What skills do you need?
- How do you build skills?
- End-user involvement
It is not only the suppliers of IT solutions that need to know about accessibility. As a procurer, you also need enough knowledge of accessibility to know what is possible, what requirements you should ask for and whether the delivered solutions meet the stated requirements. You also need to hold an informed dialogue with suppliers in cases where the best approach is unclear or where accessibility requirements clash with other considerations.
Why do you need skills?
Suppliers may lack competence
Unfortunately, accessibility is often not a core competence for a lot of IT suppliers. If it is left entirely up to them to specify, interpret, implement and measure against the accessibility requirements, the results may not meet your customers’ or employees’ needs. Inaccurate claims of IT accessibility are not unusual. This is not necessarily a question of procurers being knowingly undersold. It is just that often neither the supplier nor the procurer have sufficient expertise to realise that they have not achieved the level of accessibility intended.
Accessibility conformance ratings
Conformance logos from the Web Accessibility Initiative (WAI) are commonly used on websites that are designed to be accessible. However these conformance rating claims are made voluntarily and are not checked by the WAI. The 2005 SocITM Better Connected survey by the Royal National Institute of the Blind found that nearly one if four of the subset of 468 UK Council websites that display a WAI logo did not reach that level of accessibility. It is important therefore to ensure that any conformance claims being made by a supplier for an IT product or service are confirmed by an accessibility expert.
You will need to work with the supplier to resolve certain issues
Since you have direct responsibility for meeting your customers’ and employees’ access needs, you should be prepared and able to drive the accessibility work. During the course of the work, decisions often have to be made on pragmatic issues where strict compliance with the accessibility guidelines may not seem possible, so you will need to decide which way to go. For example, the design may have to balance accessibility and guidelines compliance against security considerations, such as access control and timeouts. This is not a decision the supplier should be making and, although they will be able to make recommendations, you will need to understand the implications of the trade-off enough to make the decision.
Basic awareness for all
Universal Design primarily comes from a mindset. It requires an understanding of what it is like for people with diverse abilities and limitations to use IT products and services. Because the issues are essentially person-centred rather than technology-centred, it is important to be able to see things from the perspective of users with disabilities and become aware of how access barriers arise and what the human consequences are.
This goes for everyone involved. It is important that accessibility is embraced and understood by all those who are in any way involved in the procurement and operation of the product or service including:
- senior level management;
- project managers;
- designers and developers;
- system administrators;
- content creators (e.g. for websites and intranets); and
- help desk operatives.
Fulfilling accessibility requirements often involves confronting technical issues. If your project manager does not have sufficient technical expertise, he or she may need the support of someone who does, such as the IT manager.
If the necessary expertise does not exist within your procurement team and cannot easily be generated, it may be necessary to engage the help of an independent accessibility expert to provide assistance with the assessing of candidates and tenders and the evaluation of deliverables. This process is similar to that commonly employed in the procuring of building works where clients frequently employ outside experts in the form of an architect, engineer, quantity surveyor, etc. to validate what is delivered. Good suppliers will often welcome the idea of a third-party expert auditor evaluating and providing constructive feedback on the accessibility of their work.
An effective procurement team should have the capacity and authority to finalise all the procurement decisions within the team. Having to seek approval from outside of the team may delay the procurement and development process. If decisions need to be changed later because of this, costs increase and the design may ultimately suffer.
It is important that the supplier is able to work with people within your organisation who have the ability and authority to carry out quality assurance and make changes. A typical problem that can occur is that certain aspects of the design, such as colour schemes, have been predefined by the marketing department and the project manager does not have the authority to change it when it is found to cause readability problems. Other issues can occur during operation if, for example, the project manager does not have sufficient authority to ensure that inaccessible content (for example, inaccessible PDFs produced by the press office) are published to the site. An accessibility policy will help ensure that these issues can be dealt with effectively and with a minimum of disruption.
How do you build skills?
Reading the principles of accessible procurement will help you some way towards developing the right basic awareness. Talking to accessibility experts can also help you raise your level of knowledge considerably. However, to build an in-depth understanding of accessibility. It is essential also to interact with real users.
It is likely that most of the people in your procurement and development team have never actually met users with disabilities. Although many of them will have met people with disabilities in other walks of life, they may not have any knowledge of them as IT users. Experience shows that when service providers or IT developers meet, talk to and observe users with disabilities, they gain a far better understanding of what accessibility really means. Designing and implementing appropriate solutions then becomes far easier, more natural and intuitive. Bringing in users for consultation groups or user tests is one of the best things you can do to generate interest, acceptance and understanding amongst your team.
End users with disabilities should always be represented, preferably by direct involvement but at least by your access officer. The access officer should be included in decisions at all stages of the procurement, from requirements specification, to tender assessment, through design and implementation. Involving users with disabilities will not only help you ensure that your IT solution is accessible in practice but will also generate goodwill and a feeling of inclusion amongst people with disabilities and their representatives.
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. The first stage of this is gathering information about the users. This may be done by the supplier as part of their own requirements gathering work. It will also be very useful for you to talk to people with disabilities to get a sense of their needs and preferences. One effective way to do this is to convene a consultation group. If you are unsure how to proceed, a good first step is to ask people with disabilities how they feel they should be included and consulted. The NDA has published the "Ask Me" guidelines on how to consult with people with disabilities. If you are a local authority, you will have a community forum that should include people with disabilities. This might be a good consultation group for IT procurements. Advocacy groups or organisations representing people with disabilities can also be consulted.
One of the best ways to find out whether an IT product or service is accessible is to run a user test. User tests are realistic tests in which real users attempt to carry out real tasks. Observing the users and talking to them about their experiences reveals a lot about the practical barriers that arise when people try to use the product or service for its intended purpose. In particular, user testing will reveal issues where the IT may be technically accessible but the design makes it so confusing or time consuming for disabled people that it is in practice unusable. If the user testing reveals that all is well, you will have the confidence of having seen it for yourself.
User testing is not just something that is done at the end of the design, when you have a finished product. One of the principles of accessibility is that it should be considered from the start since it is often costly to modify a design that is found to have fundamental accessibility flaws. Users with disabilities can be involved in testing evolving ideas and prototypes throughout the design, development and implementation process. A good way to do this is to build a relationship with a few individual users who can become part of the team, testing things informally “on the fly” as and when needed. This can save a lot of effort and cost by catching issues before they are developed into solutions that do not work.
User testing is complementary to expert accessibility auditing. The technical scope of a user test is nowhere near that of an audit. A lot of technical problems won’t arise in a user test unless you employ hundreds of users, which would be prohibitively costly. But even a small user test can reveal a lot of important usability issues that real users will face but which even expert auditors may not have predicted.
Read more about user testing