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鈥攗sually too late鈥攖hat 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鈥檝e 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鈥檙e considering. However, don鈥檛 vaguely ask 鈥淚s 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鈥檙e 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鈥檚 Web Content Accessibility Guidelines (WCAG). As of November 2020, 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鈥檚 website includes no content about their products鈥 accessibility, this typically means they have not considered it.
Often vendors provide a 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鈥檚 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