Waypoints in the process of Accessible Procurement

Everyone knows that the process of procurement is complex and takes time. It is easy to overlook certain details, even with the best of intentions. Accessibility is one of those details. As with any other aspect of procurement hygiene, it is important to ensure that all stages of procurement incorporate your university’s commitment to a more accessible, and thereby equitable, place to work and study.

Ensure that accessibility is considered throughout the procurement process. It is not helpful if one stage is strong on requirements, while later in the process those same requirements are either forgotten about or relegated to a lesser status.

This document highlights some of the key stages of procurement and suggests ways to ensure that the requirements of digital accessibility are captured throughout.

It should be read in conjunction with the other documents in this guide, specifically those giving examples of text to include in various documents in the process, as well as questions to ask vendors and those reviewing responses from vendors.

Creating the necessary organisational support

Accessible procurement does not occur in isolation. Ideally, it is part of a wider approach to accessibility. Identify existing support mechanisms and policies at your institution, such as a Disability Action Plan or accessibility training.

Develop an Accessibility Policy. This provides the governance framework for what follows and enables those involved in procurement to point to the university’s public commitment to being an accessible place to work and study.

Get policy endorsement and buy-in from the Leadership Team or Executive. They need to understand that accessibility doesn’t mean more work, it’s an effective business practice.

A named person in that team should become the accessibility sponsor.

Create groups and roles that can assist with implementation, such as:

• A dedicated accessibility role responsible for guiding accessibility efforts across the organisation
• An Accessibility Steering Group to provide a strategic overview across the organisation
• A network of Accessibility Champions to carry the work forward on a day-to-day
• Consider establishing a group of staff and/or students to provide direct feedback on digital accessibility issues encountered.

In some institutions, it may be appropriate to use existing organisational structures around disability and accessibility if they are sufficiently developed and capable of absorbing these roles

People with lived experience of disability should be actively sought to fulfil roles in these structures where possible.

Add Accessibility to the planning process

Accessible procurement should be included within your organisation’s Disability Action Plan.

Disability Action Plans have the capacity to produce the systemic change which is required to eliminate disability discrimination whether it be direct, or unintentional and indirect. Action Plans may incorporate both broad goals:

“Adopt a human rights by design approach to the provision of digital services and facilities: from concept, research and design, testing and production through to implementation and use.”

and more specific actions.

“Embed accessibility requirements as standard for procurement of software, digital resources and platforms.”

Apply Accessibility to the procurement process

Once you have your organisational commitment and infrastructure taken care of, you can begin to apply it in real-world scenarios, such as in procurement.

Your institution will almost certainly already have a dedicated procurement policy.

Write accessibility into that procurement policy. See the ’ Clause Bank’ document for some suggested text to include in a procurement policy.

You might also consider a dedicated policy on accessible procurement. We have included good examples upon which such a policy could be based in the Resources document in this guide. However, even with a dedicated policy on accessible procurement in place, it is still advisable to include accessibility requirements explicitly in the main procurement policy so that they are seen as equal considerations alongside other criteria such as security and privacy.

Recognise that the average user does not exist except as a statistic, and so trying to obtain equipment for the average user is a fool’s errand which will result in more work, equipment not fit for purpose and more expense.

Determine the standards you want to work to: e.g., WCAG or AS EN 301 549. You will refer to these in all RFP and contracts.

WCAG, the Web Content accessibility Guidelines, is the standard that should be applied to all websites. This includes content as well as online services and applications with browser interfaces.

‘AS EN 301 549:2020 – Accessibility requirements for ICT products and services’ is an Australian Standard which provides functional performance statements and requirements for ICT products and services. It incorporates the Web Content Accessibility Guidelines (WCAG) 2.1 and applies the Guidelines to non-web documents and software. In addition, it includes requirements in relation to hardware, two-way voice communication, video, product documentation and support. Test procedures and evaluation methodology are provided for each accessibility requirement.

Assemble a procurement team which includes accessibility expertise. You’ll want their advice and input to the wording of RFPs, contracts etc, and to help evaluate the responses from vendors and negotiations for contracts. Make this a standard part of your procurement process.

Include accessibility requirements throughout the RFI, RFP or RFQ. Don’t leave accessibility out on its own. Including accessibility references throughout the document sends a message that you’re serious about accessibility and you expect the vendor to be, and that you will be paying close attention to how they respond.

Make sure you explain which standards you are expecting the vendor to meet; do not expect them to know. Your vendors may not know about accessibility – you may have to enlighten them.

Highlight your own organisation’s commitment to accessibility and to human rights by design so that your systems are inclusive and accessible to disabled people.

And of critical importance: walk the talk. Ensure that your own RFI/RFP/RFQ documentation is itself accessible. If it isn’t, you’re sending a clear message to the vendors that you’re not that serious.

Ensure accessibility-related criteria are clearly included in the Requirements section of your RFI/RFP/RFQ. Use one of the suggested samples of text in the ’ Clause Bank’ document to make your expectations clear.

Ensure that you clearly state that the accessibility criteria will be closely examined during the evaluation stage.

Use the suggested questions described elsewhere in this guide (see document entitled " Accessibility Procurement Questions") to ensure you get the responses you need to make an informed assessment of vendors’ approach to accessibility.

It is imperative that the responses made by vendors to questions concerning digital accessibility are appropriately evaluated by the procurement team. To that end, it is best practice to ensure that subject matter personnel are included and that vendors understand that this is the university’s practice.

Information from the vendor should include:

• Accessibility test results including automated and manual testing as well as usability testing.
• Documentation of features provided to help achieve accessibility and usability for persons with disability.
• Documentation of core functions that cannot be accessed by persons with disability.
• Documentation on how to install, activate and configure the ICT item to support accessibility.

When an ICT product is an authoring tool that generates content (including documents, reports, videos, multimedia productions, web content, etc.), the vendor should provide information on how the product enables the creation of accessible electronic content which itself conforms to WCAG or AS EN 301 549, including the range of accessible user interface elements the tool can create. An authoring tool also needs to be accessible to people creating the content and hence conform to the Authoring Tool Accessibility Guidelines (ATAG).

Prospective vendors should understand that, before final acceptance, the preferred vendor will be expected to provide a fully working demonstration of the completed ICT Item to validate conformance to the institution’s accessibility requirements. The demonstration should expose where such conformance is and is not achieved.

Roadmap to accessibility

It is quite possible that vendors will either not be, or will not yet be, able to provide a product which meets your accessibility requirements. While we would strongly urge that accessibility is an essential criteria when selecting a vendor, there will be times when the other business priorities mean that it may be advantageous to seek a roadmap by which the vendor intends to make their product compliant with your accessibility requirements. Requiring a roadmap also provides an opportunity to discuss with the vendor how temporary work-arounds will be put in place while the product is being made accessible. It will also ensure that the vendor stays true to any commitments they have made in order to win the contract. Ensure that a named person, maybe someone from the Steering Committee if your university has one, is given responsibility to confirm that commitments made by the vendor are followed up and implemented.

Remember this will also protect the institution. It will show that the institution continues to take its own commitments to accessibility seriously, and will provide it with documentary evidence that it is making efforts to bring ICT which it is procuring in line with accessibility standards.

Accessibility remediation involves several steps:

1. Conducting an audit of the product
2. Logging and tracking defects
3. Prioritise the defects of remediation

• This will depend on severity, impact and number of people affected

1. Establishing a remediation timeline
2. Identifying possible workarounds
3. Fixing the defects
4. Releasing updates

Each of these steps takes time. The fewer steps that a vendor has undertaken, the longer it will take to deliver an accessible product,

See Further reading for examples. There is an excellent example of an Accessibility Roadmap template at the California State University Accessible Technology Initiative.

Evaluation process

It is extremely important to evaluate vendors’ accessibility-related claims. This is because it is probable that the procurement team will not necessarily be accessibility experts. And the vendor may or may not have been accurate with their assessments. This could be because they genuinely do not have the expertise, or because they want to ‘over-egg their accessibility pudding’.

Assemble a team which includes digital accessibility subject matter experts. They should be capable of assessing the vendors’ Accessibility Conformance Report (if they have completed one, and you should ask them to do so in the RFP/RFQ process). You can also seek the advice of an external expert if you do not have sufficient expertise in-house.

Vendors who appear to have met digital accessibility requirements should be questioned the same way vendors are evaluated for security and privacy issues. Digital accessibility should be seen as part of digital hygiene in the same way as they are.

You need to satisfy yourself that they can demonstrate their product is accessible.

• On which tests and standards do they base their response?
• Will they share test results with you?

Pay close attention to the language they have used in Accessibility Conformance Reports (from VPATs).

It is important to read and understand what the vendor is saying in these documents. Take careful note how they answer specific questions. Providing an accessible online option is not the same as requiring a user to contact you by phone for example. If they are relying on alternative means, then they should say so.

A partially met criteria means that some aspect of the criteria has not been met, and you need to determine whether that is important to your institution in this instance.

Depending on the risk level and the responses you’ve received to your accessibility questions it could also be necessary to undertake in-house testing of the claims. This would likely be a technical accessibility audit against the appropriate standard and some usability testing with staff or students with disability that might be using the ICT product or service.

Digital Accessibility should be part of the Contract

Once a vendor is identified that can meet other criteria and deliver an accessible product, accessibility details should be clearly set down in the contract.

• State the accessibility standard (e.g., AS EN 301 549:2020 or WCAG 2.1 Level AA);
• State how and when the technology will be tested;
• Hold the vendor responsible if the product turns out not to be accessible by requiring the vendor to remediate problems or deliver a new product.
  • Part payment may be withheld until you are satisfied.
• Indicate the acceptable turn-around time for addressing any accessibility issues
• Ensure that the contract requires the vendor to remedy any accessibility issues which may be discovered within a reasonable period after signing. This is particularly important since it may be that some accessibility barriers may not be discovered immediately
• Ensure that specific people or roles in both parties are identified who will take responsibility for the implementation of accessibility once the contract has been signed.

What if the procured ICT isn’t fully accessible

Despite best efforts during the procurement process, there will be times when software is purchased that falls short of accessibility standards. In these cases, it is important that the purpose and limitations of the software are clearly articulated, along with alternative means of access for users.

An Equally Effective Alternate Access Plan, or Plan B, is a document that describes how information and services will be made available to individuals with disabilities until they can be made accessible. The plan does not require the person to have an identical experience but should offer an experience that can provide a similar service or body of knowledge and learning opportunity as that gained by people who do not have the affected disabilities.

An example of an Equally Effective Alternate Access Plan would be where installation of a two factor authentication app requires vision impaired users to scan a QR code with their phone. An alternate method of installing the app might be via the phone or in person via an IT support desk.

Benefits of Equally Effective Alternate Access Plans:

• Provide a well thought out solution, rather than an ad hoc workaround
• Focus on the barrier to access, rather than individual users
• Reduce frustration, by highlighting barriers to access up front
• Improve communication between users and support services
• Document defects so that they can be included in future planning

See the further reading for examples of Alternative Access Plans.

It is important to note that procuring ICT with known defects is not a way of ‘getting out’ of accessibility obligations. In many cases, the provision of alternate access will require just as much, or more, effort as implementing an accessible by default solution.

Ongoing accessibility

Once your product is purchased, the contract is in place and support processes are agreed with the vendor, you need to ensure that the product remains accessible, or that accessibility problems can be addressed quickly. ICT products receive updates many times during their lifetime. It is not unusual for such updates to unintentionally cause accessibility features to be turned off, or for the product not to be correctly configured. It is even possible that an update might stop an accessibility feature from working as it once did. Similarly, you will want to ensure that the product interacts accessibly with other ICT equipment in your institution, or that other such equipment does not prevent the accessible operations of this product.

• Ensure that users have an easily understood means of reporting such issues and that there is an efficient process in place to respond to such reports.
• Ensure that all team members understand the institution’s accessibility policy.
• Make sure that they know who to escalate any such report to if they cannot resolve the issue themselves.
• Ensure that any future updates can be rolled back easily if they introduce unacceptable accessibility issues.
• Normalise discussions about accessibility – ensure that everyone knows that your institution cares about accessibility and that it expects everyone, regardless of role or seniority to care as well.

Vendor management

It is important to view vendors as a partner in providing accessible software and services. Frequently, vendors will have done some accessibility testing on their product but won’t have considered a full range of guidelines. On many occasions, education institutions are more acutely aware of accessibility defects because they receive direct feedback from users.

The results of any accessibility audit undertaken by institutions should be shared with vendors. In response vendors should provide institutions with means of tracking known issues (e.g. Jira ticket numbers) and a timeline for remediation.

Contract renewal is a formal process in which software and services are reviewed to see if they are meeting expectations. It provides an excellent opportunity to revisit outstanding accessibility issues because:

1. accessibility defects may have emerged which weren’t considered or weren’t apparent during implementation;
2. you may have been paying for services that you haven’t received;
3. vendors are strongly motivated to resolving areas of dispute.

Further reading

Roadmaps

• Accessibility Roadmap Template (PDF) – California State University
• Building Accessibility into Your Procurement Process – US Section508
• Procurement and accessibility: Processes – National Disability Authority, Ireland

Evaluating an Accessibility Conformance Reports (or VPAT):

• How to Read a VPAT: Assessing Accessibility Conformance Reports – University of Washington
• How do I interpret a VPAT? – Sonoma State University
• Accessibility in Procurement: How to Read a VPAT – Northwest Higher Education Accessibility Technology Group
• Understanding the VPAT - National Center on Accessible Educational Materials for Learning at CAST
• Verifying Vendor Information – University of Oregon

Plan B – Equally Effective Alternative Access Plans

• Creating an Equally Effective Alternate Access Plan (EEAAP) – Harvard University
• Equally Effective Alternative Access Plan – University of Oregon

***Please note:*** *We view this as a living resource and welcome feedback. We are improving our website to ensure this content is fully accessible for all users. There is also a fully accessible version of the content available on the [ADCET website](https://www.adcet.edu.au/accessible-it-procurement/). We welcome feedback about the content and its accessibility as part of our ongoing process for improvement — email: [procurement@caudit.edu.au](mailto:procurement@caudit.edu.au).*