Accessibility in Third-Party Products and Services

The emergence of COVID-19 drove much of what we do in postsecondary education online, as most of us are now working, teaching, and meeting remotely. Even major events such as conferences and commencement ceremonies are now conducted online. Being more dependent than ever on third party technology solutions makes it more critical than ever that those solutions be accessible to all users, including individuals with disabilities.

Unfortunately, many of these products and services were not designed with accessibility in mind. It is often discovered—usually too late—that the online activity or event being organized is not going to be accessible to participants who use screen readers or other assistive technologies, 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 guidelines 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 and accessibility is an important value within their corporate culture. This is integral; if a customer suddenly realizes the product they’ve purchased is not accessible, it cannot be fixed overnight.

Given this, it is important for people making purchasing decisions in this space 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 a solution that is accessible. This needs to be addressed at three stages in the procurement process, as described below.

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, don’t vaguely 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 guidelines most commonly adopted as standards for the accessible design of technology, particularly for web-based software applications, is the Word Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG). As of November 2020, WCAG 2.1 is the latest version of WCAG. 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.

Information about product accessibility can sometimes be found on companies’ websites, including statements of commitment, accessibility roadmaps, and documentation or tutorials for users with disabilities. If a company’s website includes no content about their products’ accessibility, this typically means they have not considered it.

Often vendors provide a Voluntary Product Accessibility Template (VPAT) as a means of documenting their conformance with accessibility standards. There are four editions of the VPAT, each based on different accessibility standards. If WCAG 2.1 Level AA is adopted as your standard, the most appropriate VPAT edition for your vendors to complete is the WCAG edition, version 2.3 or higher.

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 priority, rather than transparency. The more credible VPATs are those conducted by independent accessibility consultants. Ideally, vendor claims should be independently verified rather than accepted at face value.

VPATs can provide a good starting point for a thorough discussion with the vendor about the accessibility of their product. If their VPAT claims they support each of the WCAG 2.1 success criteria, ask them to explain how. 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.

Step 3. Include accessibility assurances in contracts.

With no accessibility requirements built into your contracts, you have little if any leverage when you discover the product you’ve purchased is inaccessible. 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. The contract you sign should include language that specifically addresses expectations around accessibility. Ask the company to provide a roadmap with a prioritized list of accessibility issues and a timeline for addressing each issue. Your contract should include language that requires them to make satisfactory progress on their roadmap, with penalties built in for failing to do so.

The UW includes an IT Accessibility Rider among their Terms and Conditions for contracts and purchases, which can be referenced as a starting point for developing language for your own contracts.

About AccessComputing

The Department of Computer Science and Engineering and DO-IT (Disabilities, Opportunities, Internetworking and Technology) at the University of Washington lead the AccessComputing Project for the purpose of increasing the participation of people with disabilities in computing careers nationwide.

For further information, to be placed on the mailing list, request materials in an alternate format, or to make comments or suggestions about DO-IT publications or web pages, contact:

University of Washington
Box 354842
Seattle, WA 98195-4842
accesscomp@uw.edu
www.washington.edu/accesscomputing/
206-685-DOIT (3648) (voice/TTY)
888-972-DOIT (3648) (toll free voice/TTY)
509-328-9331 (voice/TTY) Spokane
206-221-4171 (fax)

For more information about navigating the procurement process, check out the University of Washington's webinar on Accessibility in Procurement.

Leaders

University of Washington
Dr. Richard Ladner
Dr. Sheryl Burgstahler
Dr. Amy J. Ko
Dr. Brianna Blaser

Gallaudet University
Dr. Raja Kushalnagar

Tufts University
Dr. Elaine Schaertl Short

University of California, Irvine
Dr. Stacy Branham

Acknowledgment

AccessComputing is supported by the National Science Foundation under Grant #CNS-0540615, CNS-0837508, CNS-1042260, and CNS-1539179. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.