We continue our discussion on procurement in our series of accessibility conversations around the 8 Key Elements for Creating a Culture of Accessibility with Jeff Kline. We dive deeper into categories of Information and Communication Technology (ICT), tools for purchasing departments, and the roles of vendors and purchasers during the proposal and review process.
Benefits of Addressing Accessibility When Making ICT Purchases
Sanjay Nasta: Why is considering accessibility in purchasing Information and Communication Technology (ICT) important?
Jeff Kline: Almost every organization, both public and private, depends on using technology in lots of different ways to run their enterprises. Almost no organization has the resources or desire to create all the technology they use. So instead, they must purchase what they need from other places.
Unfortunately, most ICT that is used around the world today does not meet accessibility standards. This means that people with disabilities are unable to use it. This inequitable situation creates barriers to entry for people with disabilities that want/need to interact with ICT and creates liability for the organizations that own and deploy it. Ensuring ICT accessibility criteria are incorporated into procurement as deeply as possible is critical.
Sanjay Nasta: Paying attention to accessibility during the procurement process can result in tremendous gains for accessibility within your organization.
Jeff Kline: Based on what I’ve seen in my 20-something years of experience in accessibility, the purchasing process can have a significant impact on accessibility for both internal and external stakeholders. Customers, clients, and the general public will be exposed to the ICT goods an organization purchases.
Sanjay Nasta: Most of the impact accessibility can make is on the broad range of hardware, software, internet and other products that fall under the Information and Communication Technology (ICT) umbrella. What are the major categories for ICT procurements?
Jeff Kline: One of the ways I like to think about (categories) is the degree of impact and, thus, the degree of accessibility risk a particular technology has for the organization.
For instance, for an organization’s public website, you have tens of thousands or even millions of people coming to the website to look for information they need or to perform critical tasks, and the site is not accessible (compliance to accessibility standards such as WCAG 2.X AA then its exposure is going to be high.
On the other hand, for internal applications that you run within your organization that have a low number of users, the risk of disenfranchising somebody will be much smaller–but it ain’t zero.
One of the scenarios in my book talks about a very small accounting department that has been using a green screen application for years. It’s been going well, and a screen reader user (blind) has successfully been using the application and is a very high productivity worker. The organization transitions to a new application with a graphical interface that has not been made accessible. Now you have a disenfranchised employee and perhaps a complaint under the ADA. This can be a big problem that could have been prevented in the purchasing process with the integration of accessibility requirements in the solicitation and award process, but not so easy to mitigate after purchase/deployment.
When procuring technology, consider the exposure risk and adjust your processes accordingly.
Tools for Purchasing Departments
Sanjay Nasta: What tools can purchasing departments use to improve the accessibility of the purchasing process?
Jeff Kline: There are several things that a purchasing department can use to include accessibility in the purchase process. The first is accessibility training for purchasers to understand the elements of accessibility and how to ascertain the levels of accessibility in the products or services they’re considering for purchase.
Commercial off-the-shelf products document their levels of accessibility by using a standard template known as a VPAT (called the Accessibility Conformance Report (ACR) when the VPAT is completed). It’s difficult for someone without accessibility training to figure out what that ACR is saying and then make judgments about whether to accept the VPAT or seek further information from vendors or remove a vendor from considerations based on what they’ve presented.
It gets more complicated when you buy services rather than products because you cannot ask for an ACR. For example, if you contract with a company to develop a website or an application, how do you ensure that a company can produce an accessible deliverable?
That gets a little bit tricky. You must include accessibility criteria and requirements throughout the solicitation process and into the contract life cycle to ensure that you get an accessible deliverable. If you wait until the end of development and realize that the vendor didn’t know what they were doing, you will have spent all this money and time. You have an inaccessible deliverable or a contract breach assuming the requirements and contract language were implemented correctly.
Comparing Off-The-Shelf vs. Custom Development
Sanjay Nasta: Another interesting division is purchasing an off-the-shelf product versus purchasing services to develop ICT. Purchasing an off-the-shelf seems a little easier regarding testing and standardized reporting. When purchasing services, it seems important to set a strong set of accessibility standards and requirements upfront and include them in the contract.
Jeff Kline: Yes, including standards and requirements in the solicitation can help. But, before you get to the step of awarding a contract, you must be confident that the reporting on that product is as accurate as possible, meaning that if it’s a commercial off-the-shelf product (COTS), the company or the manufacturer that produces it has tested it for accessibility. Across the thousands of VPATs I’ve reviewed, many companies have never tested their product in a way that gave me confidence in the data provided on their VPAT.
For services, it’s a bit more difficult because no product exists, so there is no ACR to review. Since no product exists, you need to base your decisions on secondary factors such as the company culture, the company’s development environment, their development process, and most importantly, any prior work that they have done with accessibility requirements implemented. The goal is whether or not the vendor can reliably produce an accessible result. I think that if a company has never made a product accessible but claims they’re going through the training and will be able to do it for you, the risk is too high. Let them cut their teeth somewhere else.
Sanjay Nasta: Can you require a VPAT after the development cycle is completed?
Jeff Kline: Yes, you can ask a vendor to produce an ACR at the end of development. The VPAT template may also be used as a standard for accessibility testing. I think that that’s a legitimate way to report compliance levels. But you should also consider contract language that stipulates a vendor provides the accessibility test plan and the results when completed, and (addresses) corrective actions plans for issues discovered.
Determining Credibility of Accessibility Claims
Sanjay Nasta: How do you determine if a vendor’s accessibility documentation, such as an Accessibility Compliance report, is credible?
Jeff Kline: There are several things that you can look at.
I’ve discussed red flags to look out for while reading VPATs in various presentations and my book. The VPAT should be completed by qualified accessibility experts using generally accepted industry tools and procedures following accessible testing.
Then you must review the VPAT with a critical eye. For example:
- Does the title block have the correct product name?
- Is the VPAT for the present version of the product? Frequently providers will not re-evaluate the product when a new version is released.
- Do they complete the block when it says evaluation methods are used? If they don’t include some language about the methods and procedures and say “general product knowledge,” that is a big red flag. That tells me that the product has never been tested, so there’s an accessibility risk.
- Saying globally, everything is supported, and there are no remarks or explanations. This implies that it’s just a perfect product that we know is more theoretical than actual.
I would point people to some of my online presentations or my book to get into more details.
For vendors that provide development services, that’s a little tougher. There is no VPAT. There were two other pieces of information that I look for. In my State of Texas Accessibility Program Director role, I developed a form called the VADSIR. It’s a bit of a mouthful. It stands for Vendor Accessibility Development Services Information Request. 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.
It helps you judge if a vendor can produce accessible products and services, and then, of course, you can go on to some of the websites and check their prior work. The interesting thing is I’ve seen many vendors list prior work as accessible, but when you go to their website, you find that it’s far from that.
Also, consider using an accessibility maturity model such as the Policy Driven Adoption for Accessibility (PDAA) to evaluate the vendor’s PDAA includes a tool that can be given to vendors that measure the level of accessibility maturity within an overall organization.
There are also several other accessibility maturity models out there. The W3C just published its first working draft of its maturity model. I am part of the team developing that model. The hope is that it becomes more of a de facto standard accessibility maturity model rather than having various other ones available here and there.
Accessibility Documentation: Where to start?
Sanjay Nasta: Where and how should we include accessibility languages and requirements and solicitations and contracts?
Jeff Kline: When you are looking for a company to provide you with an ICT product or solution, the requirements for accessibility documentation should be based on the type of ICT or solution being procured. The criteria should be clearly stated in the solicitation language. By understanding what to ask for and what a credible response is supposed to look like, the documentation can give you confidence in the vendor’s knowledge of the accessibility levels of its offerings.
The typical technical standard requested in most solicitations is WCAG 2.0 AA or higher.
For commercial off-the-shelf (COTS) products, VPATs / ACRs should be required. I would specify that VPATs / ACRs be accurate, so you get something that is credible evidence as opposed to a sales rep going down and trying to complete one without any knowledge of accessibility.
For ICT development services, or hybrid solutions, VPATs are not available since the deliverable (such as a new website or web application) does not yet exist. In such situations, you must include documentation requirements in the solicitation language to gauge a vendor’s skills, abilities, processes, tools, and prior project examples. (I also go to the vendor’s home page and look at that.)
Other documents to consider requesting are an accessibility maturity model such as PDAA or early use of the W3C Maturity Model. For development services, consider requesting the VADSIR.
Remember that these documents are just the initial step in an accessibility review. You shouldn’t accept the information provided at face value. After you get the solicitation responses, you should validate the information provided and investigate further by asking for more information. On the VPAT, for example, you can ask, “Tell me more about how you tested your product. Can you provide the test cases? When are you going to have the issues identified fixed?”
It’s unlikely that you’re going to have any product that’s 100% accessible. There’s a certain level of risk associated with every procurement concerning accessibility, but at least ensure that you’ve got the language that says that the VPAT and other accessibility documentation provided is accurate to assess the risk correctly.
Sanjay Nasta: We are seeing more and more organizations incorporate the VPAT as part of the contract, so it’s the era of a salesperson filling out a VPAT and submitting it. It’s hopefully over because I think it exposes a vendor to too much legal risk to do so.
Jeff Kline: Very true, Sanjay. Assuming that the vendor organization recognizes the liability, hopefully, we’ll see less and less of that. And I did see such problems that started to decrease at the end of my State of Texas tenure,
I think that most of the large manufacturers worldwide understand accessibility, have organizations in place, and they do a pretty good job of documenting compliance levels. Most mid-range companies and smaller vendors must be educated on accessibility responsibilities.
Accessibility Roles for Vendors and Purchasers
Sanjay Nasta: Who should be responsible for testing a product for accessibility?
Jeff Kline: In my opinion, the burden of proof for accessibility belongs to the manufacturer, reseller, or development services company as opposed to the customer.
This means that contract language needs to be in place that ultimately proves the accessibility levels for COTS offerings or a vendor’s ability to produce accessible services. . . with very little testing being performed by customers.
I don’t think you should completely eliminate customer testing. Still, if the vendor’s test results are good and they have other checks in place, you may have a reduced need for customer testing, but rather more of a “sniff” test to validate vendor results.
Make sure that you include language in your contract that states the necessary steps that have been taken to ensure accessibility and proper project management. This will help reduce the amount of validation efforts you have to do.
Sanjay Nasta: We’ve discussed the vendor side and the start of the purchasing process. As a purchasing organization, you get all this documentation in. Who do you need to include in the review of the solicitation from an accessibility compliance perspective?
Jeff Kline: If you have competent procurement personnel well-versed in accessibility, they’re the ones to include in the review. In many cases, you need to have an accessibility subject matter expert (SME) to review documents and help with the contract language, etc. If you don’t have an SME on your team, reach out to a third-party accessibility consulting firm that can assist you and go through the responses with you, as well as help you build those solicitations.
It is also important to keep in mind that accessibility is not the only requirement when procuring IT. for a COTS product procurement, it could be that the ICT has a critical business need, and accessibility criteria are a lower priority than other requirements. If the ICT is not fully accessible, the procurement process or the company’s IT needs don’t just grind to a screeching halt.
Your expert needs to guide you when purchasing inaccessible products and explain the level of risk the product brings to your organization if you choose to buy the product; the expert should provide input on what level of risk is acceptable? I would argue, however, that if the procurement is for a custom IT development, there should RARELY be a reason that a contract for something built from the ground up should not be developed with very high compliance levels.
Whether COTS or custom developed, a higher-level executive must be educated on the risk and choose whether to accept an inaccessible deliverable. This should be done before the contract is awarded and a purchase is completed,
Have a Remediation Plan
Sanjay Nasta: You might also consider asking the vendor to commit to a remediation plan before the contract signing. In our experience, it is much easier to have a vendor accept a remediation plan before contracts are signed than after.
Jeff Kline: Great point, but I would recommend caution on remediation plans. A remediation plan is just that. It’s a plan, and a plan can sometimes change within a vendor organization based on the dynamics that are occurring there. Things can move in and out of plans. Make sure there is a commitment and not just a plan in your contract.
Purchasing accessible technology is an area that should not be taken lightly. It’s where a lot of problems arise.
Recommended Resources: ICT Accessibility Policy and Purchasing
- Inside Strategic IT Accessibility: Enabling the Organization With Author Jeff Kline:
- EIR Accessibility Review – Texas A&M Chancellor’s Summit
- Let the Buyer be Aware: The Importance of Procurement in Accessibility Policy.
- University of Washington—Procuring Accessible IT
- Purdue University—Tips for Procuring Universally Accessible Software
- California State University Channel Islands—Procuring and Implementing Accessible Technology
- Accessibility Training Series from Microassist
Subscribe to Accessibility in the News
Stay informed! Get your weekly update on digital accessibility standards, private and public sector trends, litigation, events, and more.