Accessibility and Third-Party Products and Services
COVID-19 has driven us all online, as most of us are now working, teaching, and meeting remotely. This makes us more dependent than ever on third party technology solutions and makes it more critical than ever that those solutions be accessible to all users. In moving our meetings, courses, and even major events such as conferences and commencement ceremonies from face-to-face to an online format, we're discovering that there are many vendors who have products and services that can help us to meet our needs.
Unfortunately, many of these products and services were not designed with accessibility in mind, and we discover – often too late – that the online activity or event we're organizing is not going to be accessible to participants who use screen readers or other assistive technologies, or are physically unable to use a mouse, or who depend on live captions or sign language interpreters.
Making technology products and services accessible requires knowledge of accessibility standards and careful planning early in the design process. Companies who do this well typically have entire teams dedicated to accessibility, and have integrated accessibility into their design, engineering, and quality assurance workflows. They have systems in place for training their new employees on accessibility. Accessibility is an important value within their corporate culture. This is not something that can happen overnight, when a customer suddenly realizes the product they've purchased is not accessible.
Given this, it is important to consider accessibility early in the procurement process. As soon as you realize you have a need for a particular technology solution, establish a goal of finding an accessible technology solution. This needs to be addressed at three stages in the procurement process, described below as three steps:
Step 1. Solicit accessibility information.
Whether your purchase goes through a formal process or is a relatively simple decision by a single individual, it is critical to ask about accessibility of the products you're considering. However, in doing so, don’t ask "Is your product accessible?" Instead, ask open-ended questions about how the vendor ensures their product is accessible. What is their approach to accessibility within their company? What assistive technologies do they test with, and who does the testing? What sort of training do their engineers receive on accessibility? Their responses will give you an indication as to whether the company truly understands accessibility and can be trusted to provide accessible solutions.
In asking for an accessible product, it is important to identify the accessibility standard you're trying to meet. The most common standard used for defining technology accessibility, particularly for web-based software applications, is the Word Wide Web Consortium's Web Content Accessibility Guidelines (WCAG). As of June 2020, WCAG 2.1 is the latest version. WCAG 2.1 is organized into principles, guidelines, and (at the deepest level) success criteria. Each success criterion is assigned a Level (A, AA, or AAA) which corresponds with the importance of that item for accessibility, combined with how difficult it is to implement. Most web or technology accessibility policies, and most legal resolutions and settlements in the United States, have agreed that Level AA is a reasonable target. To meet WCAG 2.1 at Level AA, a product would need to satisfy all Level A and AA success criteria.
Often vendors are asked to provide a Voluntary Product Accessibility Template (VPAT) as a standard means of documenting their conformance with accessibility standards. There are four different editions of the VPAT, based on different accessibility standards. If WCAG 2.1 Level AA is the standards you're trying to meet, the most appropriate VPAT edition for vendors to complete would be the WCAG edition, version 2.3 or higher (since earlier versions were based on earlier versions of WCAG).
Step 2. Validate accessibility information received.
It is important to understand that a VPAT is a vendor's self-report of their accessibility. Vendors that are new to accessibility typically do not have adequate technical expertise to accurately assess their products’ accessibility. Those that do have the expertise sometimes provide VPATs that are prepared with product marketing as a primary goal, rather than transparency. Therefore, vendors’ claims should be independently verified and not accepted at face value. The more credible VPATs are those conducted by independent accessibility consultants.
VPATs, or any other documentation received, should not be perceived as the final answer for whether a product is accessible. Rather, VPATs provide a good starting point for a thorough discussion with the vendor about their accessibility. If their VPAT claims they support each of the WCAG 2.1 success criteria, ask them to explain. For example, given a particular critical function of the software, how does a person perform that function without a mouse? If their VPAT acknowledges they have accessibility problems, this is actually good because it reveals that an accessibility assessment has taken place, and the findings are being reported with some transparency. Your next questions should be: What is the impact of the known problems? Do they prevent particular groups of users from using the product at all, or do they make a few minor functions of the product more difficult?
Validating a product's accessibility can be challenging without knowledge and skills in technology accessibility. This is why it's important, as described above, to determine whether the company seems to be committed to accessibility and has taken observable action to integrate accessibility into their workflows and culture. For understanding the finer details of a product's accessibility, you may need to solicit help from someone with expertise in technology accessibility. Most colleges and universities have a dedicated staff person or department serving this function. If you aren't sure, contact your disability services office. At the University of Washington, the central IT organization (UW-IT) has an entire department (Accessible Technology Services) that can help UW faculty and staff with reviewing VPATs and evaluating products (I'm manager of the IT Accessibility Team within that department).
Step 3. Include accessibility assurances in contracts.
After discussing accessibility issues with a vendor, the contract you sign should include language that specifically addresses expectations around accessibility. With no accessibility requirements built into your contracts, you have little if any leverage when you discover the product you've purchased is inaccessible.
To earn your business, a company should be willing to provide a roadmap with a prioritized list of accessibility issues and a timeline for addressing each issue. Then, your contract with them should include language that requires them to make satisfactory progress on their roadmap, with penalties built in for failing to do so.
Even if the product already meets your accessibility standards, the contract should include language that assures continued accessibility as the product is updated. This is especially important for products that are developed on an ongoing rapid release cycle.
At the UW, we include an IT Accessibility Rider (in PDF) among our Terms and Conditions for contracts and purchases. Feel free to use this as a starting point for developing language for your own contracts.