The procurement dependency

To state the obvious, nearly every organization, public and private, is entrenched in the use of ICT in many aspects of their business activities. With few exceptions, organizations have neither the resources nor the impetus to create the ICT they use in the course of operating every aspect of their organizations. Therefore, organizations are compelled to look externally to purchase needed ICT products and services.  I call this the Procurement Dependency.

Unfortunately, the vast majority of the ICT used across the world today does not meet current accessibility standards, which limits or prohibits their use by people with disabilities This not only creates barriers for people within the organization and the community it serves, its a risky proposition most of this audience is familiar with, so I won’t go into detail about it in this post.

When engaging with vendors for the purpose of procuring ICT products and services, the topic of accessibility evokes many questions:

• How do I know how accessible an existing product is?
• What are development services vendors’ capabilities for producing accessible ICT?
• How is vendor commitment to future accessibility improvements gauged?
• How are accessibility levels validated? And by whom?

Documentation, documentation, documentation

The requirements for accessibility documentation should be based on the type of ICT or solution being procured. And criteria clearly stated in the solicitation language, SOW, or any other instrument used that requires an “official” response. By understanding what to ask for, and what a credible response is supposed to look like, the documentation can give you confidence or not as to the vendor’s knowledge of the accessibility levels of its offerings.

For commercial off the shelf (COTS) products, VPATs should be required. Note that just because a vendor provides VPATs in no way assumes that the product is accessible. (DON’T LAUGH! I hear about this happening all the time when accessibility professionals are not well engaged.) Many VPATs are not completed based on accessibility testing, and therefore may be inaccurate.

For ICT development services, or hybrid solutions, VPATs would not exist since the deliverable being procured (such as a new website or web application) does not yet exist. In such situations, what you need to include as documentation requirements in the solicitation language should gauge a vendor’s skills, abilities, processes, tools, and prior project examples. (I also go to the vendors home page and have a look at that.)

Accessibility testing by who? And how much?

I see a lot of time and energy spent by many organizations that perform detailed accessibility testing of vendors’ products and services. Here’s my take:

The burden of proof for accessibility / compliances belongs to the manufacturer or service providing vendor, as opposed to the customer.

This means that contract language needs to be in place that ultimately provide credible evidence of the accessibility levels for COTS offerings or a vendor’s ability to produce accessible services…with very little testing being performed by customers.

How can this be accomplished? The bottom line is that if the necessary steps have been taken to integrate proper accessibility and project management criteria into the contract language, customers can significantly reduce their own validation efforts based on credible, accurate vendor documentation.

Examples of such criteria are, but not limited to

• Specification of accessibility technical standards(s) (WCAG 2.0 for example)
• Inclusion of accessibility specific life cycle checkpoints (for development contracts)
• Requirements for accurate vendor testing and results documentation
• Corrective actions plans for addressing issues
• A statement of compliance for the final deliverable on or prior to delivery
• Accessibility specific warranties and remedies statements (if needed beyond the contract W&R)

Note: It is very important to ensure that customer accessibility professionals are engaged to monitor progress and assess vendor documentation.

In all fairness, I do not advocate total elimination of customer testing (or customer paid third party), but if the vendor’s test results are comprehensive and accurate, which can be assumed given all of the other checks and balances I’ve described, some customer “sniff” testing may still be performed at much less cost / time.

Helpful tools to assess vendor competence

At the Texas Department of Information Resources, we developed a special form, the Vendor Accessibility Development Services Information Request for vendors that offer development services. Vendors must complete this form as part of any solicitation where development services are being procured. It asks for qualitative information regarding a vendor’s accessibility policies, organization, tools, training, corrective actions, and examples of prior accessible work.

You may already be familiar with Policy Driven Adoption for Accessibility (PDAA), an ICT accessibility governance model developed by myself and my counterparts in Minnesota (Jay Wyant) and Massachusetts (Sarah Bourne) through the National Association of State CIOs (NASCIO). To read more about it go to nascio.org/pdaa to download the 2-part whitepaper authored by Meredith Ward (NASCIO), Jay, Sarah, and myself. PDAA includes a tool that can be given to vendors that measures the level of accessibility maturity within an overall organization.

For more on my views of ICT accessibility in procurement, see my main blog post on the topic here. Or my book Strategic IT Accessibility: Enabling the Organization.