Accessible procurement checklist
A checklist for embedding accessibility into the procurement of web-based products, services or development work.
Not all parts of the checklist will apply to all situations, but it can be a useful way to identify where accessibility can be integrated into procurement.
Download the Accessible procurement checklist (CSV 8KB). For best results, open it in a spreadsheet viewer such as Microsoft Excel or Google Sheets.
Note: Where the checklist uses the word “product,” it means the product, service or web development work being procured.
Procurement phases
- Consult the users and buyers of the product
- Set clear requirements for accessibility up front
- Gather evidence of accessibility competence and standards compliance
- Evaluate suppliers
- Include appropriate contract clauses
- Review the product
- Supply documentation and training
- Provide feedback to shortlisted suppliers
- Monitor the product after deployment (contract management)
Phase 1: Consult the users and buyers of the product
Step |
Activity |
1.1 |
Start a discussion with a range of potential users of the product you are procuring, intentionally including disabled people in this discussion. Explain the purpose of the procurement activity, seek feedback, ideas or concerns, especially regarding accessibility. If your organisation has a dedicated accessibility expert, team, or disabled employee network, these may be ideal candidates to discuss the procurement activity with. |
1.2 |
Seek advice from other government organisations if they have experience with the same class of product you are procuring. Ask whether they have any advice or opinions about how accessible each product is, and whether disabled people find it easy to use. |
Phase 2: Set clear requirements for accessibility up front
Step |
Activity |
2.1 |
In the notice of procurement, ensure there’s a written requirement for the product to comply with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA as per the NZ Government Web Accessibility Standard. Examples of a notice of procurement include an Advanced Notice, Registration of Interest (ROI), Request for Proposals (RFP), and Request for Quotes (RFQ). |
Phase 3: Gather evidence of accessibility competence and standards compliance
Step |
Activity |
3.1 |
If an off-the-shelf product is being procured, ask each supplier for an accessibility conformance report (ACR), such as a Voluntary Product Assessment Template (VPAT®) or WCAG audit document that’s no older than 18 months. If the supplier does not have this evidence, ask the supplier to generate it. |
3.2 |
If an off-the-shelf product is being procured, ask each supplier for evidence of an accessibility roadmap that shows how the accessibility of the product is continually improved and maintained over time. Alternatively, ask each supplier for evidence of their organisation’s commitment to accessibility. |
3.3 |
Ask each supplier for evidence of the quality assurance (QA) processes they use to ensure web content is accessible and WCAG compliant. This could include evidence of user testing with disabled people, scheduled periodic audits, ACRs, or continual automated and manual accessibility testing processes. |
3.4 |
Ask each supplier what web accessibility training, if any, has been undertaken by the developers and testers who are likely to be involved in the development of the product. |
3.5 |
Ask each supplier how they provide opportunities for disabled people to test their products. |
Phase 4: Evaluate suppliers
Step |
Activity |
4.1 |
Ensure all the above checkpoints in Phase 3 are included as appropriately weighted and scored criteria when evaluating submissions from suppliers. |
4.2 |
For medium/high risk procurements, ensure the procurement panel includes a web accessibility expert who can evaluate the evidence provided by each supplier in Phases 3 to 6. Third party providers of web accessibility services may be helpful for this evaluation. See the web accessibility service providers on Marketplace. |
4.3 |
If the procurement panel includes a web accessibility expert, consider arranging demonstrations with suppliers, where the supplier must show the accessibility features of the product and answer any questions that arise. |
4.4 |
When reviewing the evidence provided in Phase 3 by suppliers, perform a risk assessment to decide if any of the accessibility issues identified are acceptable. Determine each issue's potential impact on the product's users, and feasible solutions, such as fixing the issue or providing alternative equivalent access. |
Phase 5: Include appropriate contract clauses
Step |
Activity |
5.1 |
In the contract and/or statement of work with the selected supplier, ensure there’s a written requirement for the product to comply with WCAG 2.1 at Level AA as per the NZ Government Web Accessibility Standard. |
5.2 |
If you are procuring an off-the-shelf subscription-based product, include in the contract and/or statement of work with the selected supplier a requirement that all future updates and changes to the product comply with WCAG 2.1 at Level AA as per the NZ Government Web Accessibility Standard. |
5.3 |
If you are procuring an off-the-shelf subscription-based product, consider including in the contract with the selected supplier a requirement for the product to comply with future versions of the NZ Government Web Accessibility Standard within reasonable timeframes. Future versions of the Web Accessibility Standard are likely to require future versions of WCAG. |
5.4 |
If you are procuring web development work, include in the contract and/or statement of work with the selected supplier a requirement that states at least one automated web accessibility testing method must be used throughout the development process. Ask for evidence of what specific automated testing tool will be used and how. |
5.5 |
If you are procuring web development work, include in the contract and/or statement of work with the selected supplier a requirement that states the supplier must utilise a range of manual web accessibility testing methods throughout the development process. Manual tests should complement automated tests to provide full coverage of WCAG 2.1 Level A and Level AA Success Criteria as per the NZ Government Web Accessibility Standard. |
Phase 6: Review the product
Step |
Activity |
6.1 |
If you are procuring web development work, ensure there’s a final comprehensive accessibility review performed by the supplier, and request evidence of this review. The review should accurately assess compliance with WCAG 2.1 at Level AA as per the NZ Government Web Accessibility Standard. If the supplier cannot provide an accessibility review, instruct them to subcontract the review to one of the web accessibility service providers on Marketplace. |
6.2 |
If there are identified accessibility issues in the product, ask the supplier to remedy the identified issues, or provide a reasonable plan to address the issues. |
6.3 |
If the product has not been user tested by disabled people, prior to deployment, consider purchasing disability user testing services through one of the web accessibility service providers on Marketplace. |
Phase 7: Supply documentation and training
Step |
Activity |
7.1 |
Ensure appropriate documentation and training is available to support disabled people to use the product. Some disabled people may require additional instruction or help to use new systems. |
Phase 8: Provide feedback to shortlisted suppliers
Step |
Activity |
8.1 |
As part of the feedback process to shortlisted suppliers (including the successful supplier), provide constructive feedback on how each supplier could improve their web accessibility practices. |
Phase 9: Monitor the product after deployment (contract management)
Step |
Activity |
9.1 |
Make sure there’s continual monitoring of the product to ensure it remains compliant with accessibility standards. |
9.2 |
Periodically seek feedback from disabled users of the product to understand if there are any accessibility barriers impacting users. |