Validating Proposals

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

Objectives

  • To obtain a clearer picture of the accessibility of a product or service, by using an internationally accepted benchmark (WCAG 2.1 AA).
  • To assess the ability of the vendor to self identify 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.
  • To identify issues which are likely to have the highest impact on users.
  • To 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.
  • To identify the accessibility capacity of the vendor, i.e. how much of an effort have they made to make their product accessible.

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 Access to Demonstration Environment

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

  • Hands-on testing is the most practical way of validating vendor claims of accessibility conformance.
  • In order to avoid delaying the procurement process, it is best to review products concurrently.

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.

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:

Contact Us

For accessibility problems please contact:

Andrew Normand
Web Accessibility Lead
Email: anormand@unimelb.edu.au
Phone: +61 3 9035 4867

For all other enquiries contact: