Testing, QA, and Procurement: Integrating them in Public Procurement

It used to be common to see ICT accessibility requirements in procurement contracts expressed as a simple one liner:

“The new website will conform to the Standard ‘Accessibility requirements suitable for public procurement of ICT products and services in Europe (EN 301 549)’”.

The practical follow-up question is “How do you know you have achieved conformance?”. By itself, the one line is open to interpretation by both parties. Does the vendor really know what conformance means? Did they systematically test their product, or did they wave a magic wand? How does the customer know? In the US we have the ‘Voluntary Product Accessibility Template’ (VPAT) which is used to list assertions by vendors that they conform to US federal requirements. Without providing test results attached to these VPATs, these are just assertions open to interpretation by both contract parties.

In recent years there has been expansion in the field of ICT Accessibility Testing. There are now a number of published test processes for ascertaining whether a particular technology conforms to a published standard. This now affords us a new opportunity, including published test processes as a leverage point in procurement contracts:

“The new website will conform to the standard… as measured by the following published test process…”.

“The vendor also will provide a VPAT with test results attached.”

By following a published test process, the vendor and the customer can share a common understanding of what constitutes ‘conformant’. This concept is addressed in a short article and free archived webinar referenced in the new Buy ICT 4 All Portal, ‘Tying Procurement Language to IT Accessibility Measurement’.

Naturally, there are advantages and disadvantages to the various types of available test process. A recent article from the Accessibility Switchboard project lists the pros and cons of different types of test process. Potentially of interest to the technology teams of both vendors and customers, one of the key points made in this article addresses the question of when testing should occur during the development process. Is accessibility tested only at the end of development, as a Quality Control (QC) check? Only doing QC is inefficient and has also proven, over time, to be quite ineffective. Instead, there are testing processes available that allow accessibility to be assessed throughout development as a Quality Assurance (QA) tool. To be effective, QC relies on efficient QA, and efficient QA relies on finding accessibility test processes that are appropriate to your given circumstances and needs.

Test methods, as well as the management of testing for QA and QC in systems development, are the subject of a new event in the US, the Annual ICT Accessibility Testing Symposium. The event represents the convergence of science and practice in the field of accessibility testing. The second annual event will take place in Washington, DC, at the end of October 2017. You wouldn’t buy a new car without knowing it was crash tested. Why would you buy ICT without knowing it was accessibility tested?