Validating Proposals

Hands-on testing is the most practical way of validating vendor claims of accessibility conformance.

Whereas many features of a vendor's product can only be tested after integration and customisation, accessibility can be evaluated using a demonstration version of the product.

Planning Tips

  • Most vendors have no difficulty providing access to a demonstration, or 'vanilla', version of their product.
  • The Request for Proposal should tell vendors that a demonstration system will be required in order to undertake accessibility testing.
  • Once vendors have been shortlisted, a follow-up email will ask them to provide a 5 working days within a 2 week window in which their product will be available.

Sample Request For Proposal Wording

Suppliers are required to provide access to a standard configured environment to enable the University to confirm compliance with accessibility requirements. The objective of this environment is for the University to confirm compliance with accessibility requirements in accordance with standard WCAG 2.1 Level AA. The environment will not be used to assess functionality, performance or any other aspect of the solution. If there are multiple modules, please provide access to all the modules.

Testing Timeline

  • In order to avoid delaying the procurement process, it is best to review products concurrently.

Example timeline for testing 3 products over 1 week

Example timeline for testing 5 products over 2 weeks

Auditing Tips

  • A good way of auditing for accessibility is to have an accessibility expert audit each product against WCAG 2.1.
  • Employing a screen reader user to undertake additional testing is a very good way of getting an overall impression of the software and identifying high impact defects.
  • If you have a chance, there is no reason why you can't include more opinions, for example from staff and students with disabilities.
Table estimating hours taken to test 3 demonstration web applications
Accessibility Expert Screen Reader User Staff MemberStudent
Vendor A 16* 3 1 1
Vendor B 16* 3 1 1
Vendor C 16* 3 1 1
Total Hours 48* 9 3 3

* Includes time spent reviewing product and time spent writing audit report

Low Cost Validation

Sometimes you don't have access to an accessibility expert or a users with disabilities to help with testing.

A low cost alternative to manual auditing is automated testing. Although automated testing picks up less accessibility defects, it can still offer some useful information, particularly where vendors have claimed that their product is fully WCAG 2.1 AA complaint.

Two of the best free checking tools are:

Validation objectives

  • Identify WCAG 2.1 AA Failures
  • Identify issues which are likely to have the highest impact on users
  • Identify which items are easily fixed. For example, insufficient contrast and missing form labels are both WCAG 2.1 AA failures. But contrast issues can normally be fixed by editing CSS, whereas problems with form labels tend to be replicated across the whole product and are time consuming to fix.
  • Assess the ability of the vendor to self identify defects. The first step towards making a product accessible is identifying that it has defects. If a vendor says in their RFP that they don't have any defects, but auditing reveals that they do, then they are a long way off achieving compliance.
  • Identify the accessibility capacity of the vendor, i.e. how much of an effort have they made to make their product accessible.

Next : Rating and Award Criteria

Contact Us

For assistance or to report accessibility problems please contact:

Andrew Normand
Web Accessibility Lead
Phone: +61 3 9035 4867