Accessible Procurement Flowchart

The following flowchart can be used to identify risk and apply accessibility ratings.

Project Initiation

The business case for a new service is established.

If the service is not being delivered via the web, we can proceed with procurement without any web accessibility checks.

Service Access Risk

If the service is to be delivered via the web, there is a risk that some users won't be able to access it, unless accessibility is ensured.

Not all services have the same risk. If a web site that is available to only 10 people in a department, it is possible that somebody might have difficulty accessing it. But if the web site is available to a large user group, e.g. all students or all staff, then it is almost certain that someone won't be able to access it, if accessibility is not considered.

The initial assessment of service access risk should be carried out by procurement officers by considering risk indicators. If a service is classified as low risk, then accessibility will need to verified via:

  • Inclusion of accessibility requirements in Request for Proposal (RFP)
  • Satisfactory written response from vendor that gives procurement staff confidence
  • Inclusion of accessibility requirements in contract

If procurement officers classify a service access risk as high, then verification will be accompanied by validation, by:

  • Inclusion of accessibility requirements in the RFP
  • Web Accessibility Lead to test vendor claims of conformity against a demonstration version of the product
  • The Web Accessibility Lead will then provide a report back to the procurement team
  • Inclusion of accessibility requirements in contract

Low Risk Indicators

  • Low number of users
  • Small project budget, e.g. under $50,000
  • Not required for student coursework
  • Low degree of educational benefits
  • Used by staff on a 6 monthly basis
  • Alternative means of access are easily identifiable
  • The vendor provides written information about accessibility which gives purchasing staff confidence

High risk indicators

  • Large number of users.
  • Larger project budget, e.g. over $400,000.
  • Required for course work.
  • High degree of education benefits.
  • Used by staff on a daily basis.
  • No easily identifiable alternative.
  • Vendor doesn't have convincing information about the accessibility of their product.

Rating Proposals

After assessing service risk, each product should be assigned a rating out of high, medium or low.

High rating indicators

  • The product meets the WCAG criteria.
  • The vendor includes accessibility in it's quality procedures.
  • The vendor includes users with disabilities in it's testing.
  • Accessibility has been validated via an accessibility review.

Medium rating indicators

  • The product fails only a few WCAG 2.1. AA checkpoints.
  • Many pages are defect free
  • Defects can be easily addressed.
  • The product has been developed with accessibility in mind.
  • The vendor has acknowledged that their product has defects.
  • The vendor has established a timeline for fixing defects.

Low rating indicators

  • The product fails at least 6 WCAG 2.1 AA checkpoints.
  • Most pages have defects.
  • Defects are difficult to address.
  • Developers don't appear to have considered accessibility.
  • Vendor hadn't acknowledged their product defects.
  • The vendor does not have a timeline for fixing defects.

Report and recommend

After rating the products, a report summarizing each product, providing ratings and recommendations, will be provided to the review RFP panel. The review panel will weigh accessibility against other considerations, such as cost.

Contract negotiation

After a preferred product is chosen, a contract negotiation will commence with the successful vendor. This is an appropriate time to provide a copy of the accessibility audit to the vendor. A timeline for addressing the defects should be sought.


After the contract is signed a prototype will typically be developed. It is important that an accessibility audit be conducted at the same time as User Acceptance Testing (UAT) to make sure that customisations are accessible.

If the service has known accessibility issues, a procedure for providing alternative access to the service should also be established.