Asking the Right Questions for Procuring Inclusive, Accessible Technology

Postsecondary institutions have obligations to ensure the accessibility of electronic content, especially content purchased from third parties. Higher education accessibility experts from fifteen colleges and universities synthesized best practices across many institutions. The resulting assessment questions for vendors have been incorporated into the 2021 updates to the Higher Education Community Vendor Assessment Toolkit (HECVAT), a widely used tool that previously focused on assessing risk for security compliance (see the appendix for the full set of accessibility questions that were added to the HECVAT).

Accessibility Challenges in Technology Acquisition

Making higher education more diverse, inclusive, and welcoming has been an increased focus in recent years. One of the often overlooked dimensions of inclusion is people with disabilities, including students, faculty, staff, and the public with whom our institutions engage as part of teaching and research missions. Most would acknowledge we have a long way to go to reach desired outcomes for diversity, and accessibility is no different. Beyond the goals for inclusion, legal imperatives demand that programs, services, and activities do not discriminate based on disability. In the United States, this expectation dates back nearly fifty years to Section 504 of the Rehabilitation Act, well over thirty years for the Americans with Disabilities Act (ADA), and other lengthy periods of time for other regulations, including state and local requirements.

With decades of precedents demanding equal access, why do so many challenges remain? It's a bit cliché to blame it on times of great change. But the technology that is used to facilitate nearly all education modalities has changed significantly, and all too often new iterations have failed to provide equal access to disabled students and staff from the outset. It's disappointing yet unsurprising when technology providers release new products or features without accessibility in mind, requiring them to go back and "fix" the issues after the fact, unnecessarily excluding students and other users in the meantime. This does not need to be the case, and if accessibility is included in new and updated products and services, the higher education community can better live up to its ideals of being a pathway to discovery, learning, improvement, and employment for so many, regardless of background.

The challenges for institutions to ensure accessibility are complex, including training vast campus content creator networks how to make their digital content accessible. In the era of digital-first and digital-primary learning experiences—even within face-to-face learning models—more and more third-party products mediate learning experiences on behalf of institutions—think learning management systems, conferencing and chat apps, text and video platforms, student information systems, virtual labs or simulations, and media repositories, to name a few. It is likely today that constituents interact more frequently with purchased platforms than homegrown ones. To ensure equity for the nearly one in five students with a disability, it is incumbent upon higher education institutions and their academic and technology leaders to hold technology partners accountable to ensure accessible, equitable learning environments for today and into the future.

Attempts to do so are not new. Some institutions and their IT units have long had policies requiring accessibility to be considered in procurement. The expertise and number of knowledgeable accessibility professionals needed, relative to the quantity of technology products acquired by most institutions, does not make this task easy. There are glaring inefficiencies in a system that forces thousands of institutions to vet the same products over and over again, from many of the same vendors, for the same technical standards, to ensure compliance with legal requirements for access and inclusion; and yet at present, this is required and necessary.

One of the best ways to approach accessibility in procurement is to have widely accepted, shared cultural values to consider early in the process. Often these cultural values are codified in policy statements that allow simple adoption, from frontline employees to senior executives. Informed CIOs and technology executives committed to upholding accessibility standards offer meaningful opportunities for IT departments to demonstrate campus leadership for inclusion and equity. If accessibility criteria are included early in purchasing decisions, institutional buyers are likely to have more options that prioritize accessibility, rather than being asked only to vet a finalist candidate when options are limited. Some institutions that have been working on these issues have well-documented processes, and many processes have grown to mirror each other over time. But variations in the expectations and assessments during sales processes for thousands of institutions and vendors create inefficiencies for all involved, especially when each interaction should be looking to assess and share similar information about digital accessibility.

Partnerships with Security and the HECVAT

Leading and managing digital accessibility efforts requires immense collaboration, and growing mature programs offers opportunities to learn from the existing higher education IT landscape. IT security colleagues offer one germane example because they have experience assessing products for risk and promoting security and privacy awareness among campus stakeholders. It is increasingly common for CIOs to have a chief information security officer (CISO) on their leadership team to guide policies, educate stakeholders, and assesses campus risk across important areas with legal, reputational, and ethical implications. Accessibility teams may not have the organizational maturity or extensive track record of their security counterparts, yet both disciplines share many of the same aspirations and add value by being well managed proactively rather than responding to crisis incidents. One tool security leaders have developed and evolved to streamline initial risk assessment for technology acquisition is the Higher Education Community Vendor Assessment Toolkit.

The HECVAT was created in 2016 to help institutions assess risk for security and privacy. It has been adopted by many institutions as a common framework to assess vendor risk. Therefore, it also serves as a baseline of concerns that vendors might work to address, appealing to common needs among higher education customers. The HECVAT Users Community Group is a place users discuss HECVAT's effectiveness and evolve the tool over time, while a database maintains current, completed HECVATs for many vendors. Likewise the EDUCAUSE IT Accessibility Community Group is a place higher education digital accessibility professionals discuss and work to address systemic challenges.

In 2021, these community groups formed a partnership to explore shared interests within the HECVAT framework. HECVAT leaders expressed interest in having risk assessed for additional areas important to the higher education community, including accessibility. (Read about all of the updates to the HECVAT in the EDUCAUSE Review article "HECVAT 3.0 Launches … to Outer Space?") IT accessibility leaders are universally in search of ways to expand awareness of and capacity to assess vendors for accessibility commitment earlier within the many pathways to purchasing technology. Partnering accessibility and security risk assessments in the same vendor toolkit offers efficiency potential for vendors and higher education partners alike. While responses should still be evaluated by qualified professionals to inform campus decisions, a common framework and pathway for collecting and assessing these institutional risk factors is promising.

Questions to Ask for Accessible Procurement

Addressing digital accessibility within higher education requires sustained, strategic, collaborative, and multi-dimensional approaches. Asking the right questions about a product prior to acquisition is key to assessing the risk in adopting technology that inadequately addresses accessibility and unnecessarily excludes people. Importantly, many factors influence critical needs of adopting technology within complex postsecondary organizations. Acquiring products, supporting them, and maximizing their use requires consideration of many factors beyond highlighted feature specifications. If a product is widely used on your campus but is inaccessible, it provides inequitable experiences for individuals who rely on such features, and this circumstance can open institutions to legal risk. Additionally, it can be more expensive and time intensive to work with vendors on addressing issues after product adoption, on top of providing necessary accommodations to affected users. Therefore, taking the time to consider accessibility before adopting or switching products can save an institution massive amounts of time and resources.

The following five areas of accessibility questions are common and long-standing across a wide variety of institution types:

• A Knowledgeable Accessibility Contact
• Product Conformance to Accessibility Standards
• Organizational Maturity toward Accessibility
• Accessibility via User Experience, Support, and Documentation
• Institutional Use and Context

Included in each section below are the questions in the latest update to the HECVAT that attempt to address these areas. Many of the HECVAT questions are adopted from questions found on the IT accessibility websites of institutions. In many cases, those adopted questions have been modified to be yes-or-no questions to conform to the HECVAT and its use of automated scoring of initial responses with the opportunity to provide further information.

A Knowledgeable Accessibility Contact

Contact information may seem almost not worthy of a mention; it is. Accessibility professionals who help acquire products have no doubt spent lots of time chasing down "the right person" through opaque organizations in order to get accessibility questions answered. A frequent topic of lament among professionals is that it often takes significant time and effort to get product accessibility questions answered by someone knowledgeable about the topic. I fully support the notion that accessibility awareness and expertise should be diffused throughout an organization, yet this is far from the reality today. Vendors that sell products to enterprise clients who have obligations to provide accessible solutions should be able to provide credible, accurate information to address this important client need. The process does not often work this way.

In recent years during procurement engagements for large enterprises, when looking for someone to answer my accessibility-related questions, I've been directed to people with a plethora of job titles, including accessibility program manager, head of digital inclusion, account executive, head of green and environmental initiatives, and security and compliance architect. Which ones would give you more confidence from the start? Readers may be shocked to learn that the head of green and environmental initiatives—though a lovely person who laudably cared deeply about the environmental impact of the company's products—could not actually answer any technical questions about accessibility. This company, in fact, had thousands of employees worldwide and lovely platitudes about caring for disabled customers in their abundance of product specifications but no accessibility experts on staff. This circumstance indicated that the company believed accessibility and serving customers with disabilities was a philanthropic endeavor and that green initiatives are nice, too—so perhaps they fit together organizationally.

• Questions GENL 11 through 13 ask for the name, title, and contact information for the most appropriate accessibility contact for the product under consideration.

Product Conformance for Accessibility Standards

The World Wide Web Consortium (W3C) Web Accessibility Initiative maintains the most widely used technology standards called the Web Content Accessibility Guidelines (WCAG). The most current version of these standards is 2.1, with version 2.2 scheduled for release at the end of 2021. WCAG 2.1 AA—the most widely adopted conformance level for governments and higher education institutions—has 50 separate testable statements. All 50 must be passed in order to achieve conformance. The jargon can be a bit intimidating for the nontechnical or someone new to the field. But the testable statements include criteria many are likely familiar with, such as captions for audio, alternative text for images, and focus indicators for keyboard use, to name a few.

One of the most common ways product owners indicate conformance to a technical standard is by completing a Voluntary Product Accessibility Template (VPAT). A complete VPAT includes many sections, but the most relevant for these purposes is listing all of the testable statements within WCAG, where the tester states whether the product in question supports each criterion. A VPAT—or an Accessibility Conformance Report (ACR) as the completed template is known—is by no means a perfect assessment or even entirely sufficient, but it directly ties product features to the technical standards to which many institutions intend to conform. As indicated by the "V" in voluntary, it can be completed by anyone, most often one of the product's creators. The results are heavily dependent on the accuracy and accessibility expertise of the individual completing a review, so extra credence is given to ACRs completed by expert, third-party reviewers. Furthermore, every product update is an opportunity to improve or break accessibility. A test of product version 3.3.4 is nice, but what if someone is looking to purchase version 3.6.8? Or 4.2? Answers vary widely by product versions and organizational maturity (addressed below), but having a current VPAT/ACR will give a more accurate picture of accessibility conformance.

It is still very common for products not to meet all necessary accessibility criteria. This makes conversation about product accessibility roadmaps vital when considering enterprise adoptions. Some vendors are understandably sensitive about sharing product roadmaps or timelines. In this case, however, less important are product features and capabilities. What matters is whether and how they will be accessible to everyone. A product accessibility roadmap states how a product owner is implementing accessibility improvements for the existing product. An accessibility roadmap is incomplete without timelines, and a mature organization committed to building more inclusive products should be able to demonstrate progress on previous roadmap commitments, evidence that can instill confidence that future waypoints will be delivered upon.

Collectively, these issues of reporting on accessibility conformance, roadmaps to address barriers, qualifications of the reviewer, identifying a standard, and specifying the currency of the version under review go a long way to understanding the accessibility of the present product being purchased. In line with HECVAT questions about security standards, the accessibility update led to the inclusion of the following questions in the 2021 changes:

• DOCU-12: Has a VPAT or ACR been created or updated for the product and version under consideration within the past year?
• ITAC-01: Has a third-party accessibility expert conducted an accessibility audit of the most recent version of your product?
• ITAC-02: Do you have a documented and implemented process for verifying accessibility conformance?
• ITAC-03: Have you adopted a technical or legal accessibility standard of conformance for the product in question?
• ITAC-04: Can you provide a current, detailed accessibility roadmap with delivery timelines

Organizational Maturity toward Accessibility

The accessibility conformance questions address the present state of accessibility in line with standards. It's one thing to know the present state of a product, but enterprise customers should also have a sense of reliability to depend on maintained and improved accessibility for a product moving forward. Organizations, for example, that depend on a single accessibility superhero may make a product shine, but if that person moves to a new role or leaves the company, progress is lost. Therefore, organizational maturity for accessibility is key to confidently investing in bringing to your campus a product that will not unnecessarily exclude people. Of note, many of the practices the higher education community should look for in vendors can be part of assessing overall maturity of our own higher education digital accessibility programs.

As technologies evolve, being current with accessibility best practices is critical. Vendors can achieve this in multiple ways. Among accessibility professionals, increasingly popular strategies to develop and demonstrate expertise include pursuing and maintaining professional certifications. Certification bodies reference quality training resources, and for larger organizations, accessibility experts will create their own internal, role-based training for relevant stakeholders. While training and hiring highly qualified accessibility experts on staff indicates maturity and commitment, it could be possible to work closely with a highly qualified accessibility partner to achieve some of the same outcomes. But quality of the consultant would be paramount in such cases. Each organization could choose a model that is sustainable and works best for them.

Once the right internal people know how to incorporate accessibility, it can be a separate matter to ensure that sufficient time and processes allow it to be done in a repeatable, sustainable manner. Knowing when, how, and by whom products are reviewed for accessibility—with multiple methods of assessment—demonstrates maturity, and documented, repeated processes to do so demonstrate that commitment best. Vendors that consistently release new products features and then later "fix" accessibility undercut any public commitment they may have to building inclusive products.

Meanwhile, customers should be able to easily report accessibility issues and have a way of monitoring progress toward a resolution. Except in rare circumstances, considering reported accessibility barriers as "feature requests" is not the right approach. While this should never be the primary means of bug reporting, it is a simple way to maintain a feedback loop with customers who rely on accessibility.

These factors give institutional purchasers confidence that an organization will continue to maintain the accessibility of the product and/or a culture of digital inclusion. The HECVAT questions that measure organizational maturity for accessibility include:

• ITAC-05: Do you expect your staff to maintain a current skill set in IT accessibility?
• ITAC-06: Do you have a documented and implemented process for reporting and tracking accessibility issues?
• ITAC-07: Do you have documented processes and procedures for implementing accessibility into your development lifecycle?

Accessibility via User Experience, Support, and Documentation

Ultimately the most important evidence to verify the accessibility of a product is the experience of its disabled users. Just as general usability goes beyond a feature list, this too is the case for accessibility. Qualified accessibility experts—especially those with disabilities themselves—will be the best reviewers, but product owners could also moderate feedback from usability tests by disabled users to collect feedback. A further benefit is that deep expertise is not always necessary to verify some of these factors.

One simple way to distill such assessments is by asking a vendor as part of the sales exploration phase to demonstrate the product and its key features using only a keyboard and a screen reader. Keyboard-only use and assistive technologies that make use of this capability are critical to many people with dexterity challenges. A screen reader is a tool that reads aloud screen elements for blind or low-vision users. One does not need to be a subject-matter expert to determine whether core functions can be accomplished via such a demonstration. Demonstrations should be validated with documentation and more complete assessment, but a very short demo with minimal institutional investment can provide tremendous insight early in a procurement process.

Product documentation can affect the user experience for everyone, including those concerned with disabilities. One example is the many tools institutions purchase that are content-creation platforms. First, these authoring platforms should themselves be accessible. Secondly, authors should be able to easily discover any steps necessary to author accessible content. Should certain settings be enabled by administrators, or should checks be made by authors? If so, how? It is one thing for providers to say their tools are accessible or can allow accessible content to be created; it's another to make it easy for distributed networks of campus content creators to do so.

Finally, the use of separate accessibility modes should be discouraged. The working group that helped generate the new questions shared numerous stories of vendors offering to have "accessibility modes" or "lite versions" of products that would meet accessibility standards. But the accessibility modes were completely separate versions of the product, had unequal feature sets, and typically followed separate code and update paths. A "separate but equal" approach to online environments is antithetical to building inclusive digital products. As new features get built and enhanced, it becomes nearly impossible to maintain parity, and the version of the product for disabled users inevitably gets left behind. Related to the use of "lite" product versions are vendors that attempt to address all of the accessibility concerns with the use of "quick fix" accessibility overlays. Many well-funded providers have sold their products as quick fixes that easily and cheaply make sites or tools accessible with minimal code. Any vendor that relies on these too-good-to-be-true platforms to fix their product's accessibility has misunderstood the aims of higher education institutions seeking authentically inclusive products, platforms, and services.

The questions built into the new HECVAT that address user experience and documentation are:

• ITAC-08: Can all functions of the application or service be performed using only the keyboard?
• ITAC-09: Does your product rely on activating a special "accessibility mode," a "lite version," or accessing an alternate interface for accessibility purposes?
• DOCU-13: Do you have documentation to support the accessibility features of your product?

Institutional Use and Context

Because the HECVAT is completed by vendors, there are no accessibility questions about the intended campus use of the product. This factor should nonetheless be considered. The more widely used, the greater the risk that an inaccessible product may exclude someone. Likewise, no matter the number of users, any product or service that is required for processes or transactions should also receive higher levels of scrutiny. And just because no one needing accessibility uses the product at your institution today does not mean accessibility should get a pass. One of the wonderful aspects of higher education is the recurring turnover of students on an annual basis, if not more frequently. Faculty and staff often change the courses taught or their areas of responsibility. Foreseeable accessibility barriers previously bypassed for expediency can stir up lots of panic for support staff, cost significantly more to address under stricter timelines, and worst of all be reasons applicants self-select or are dissuaded from pursuing curricular or employment opportunities.

Conclusion

The questions described above provide a solid framework for understanding a vendor's product conformance to accessibility standards, organizational maturity for accessibility, along with user experience and documentation implications. An institution need not use the HECVAT to ask these important questions of potential technology providers. For the hundreds of institutions that already require the HECVAT and for the vendors that participate, the addition of these accessibility questions will provide a solid foundation for qualified reviewers to assess risk. Ultimately, purchasers should be able to consider inclusion for people with disabilities more easily as part of institutional buying processes.

Acknowledgments

The EDUCAUSE IT Accessibility Community Group meets regularly to discuss issues of importance within the higher education community for digital accessibility. The group includes knowledgeable experts from a myriad of campuses who collaborate and share resources and best practices. The incorporation of accessibility questions into the HECVAT resulted from a collaboration between the EDUCAUSE HECVAT Users Community Group and the IT Accessibility CG. On behalf of the group and with community feedback, a working group of volunteers was established to include broad representation among institution types, deep subject-matter expertise, and practicality from many years of having worked on accessible procurement within higher education. The working group drew on their extensive collective experience to balance data collection, ease of use, and efficiency for vendors and institutional partners alike. Thank you to the HECVAT CG leaders Jon Allen (Baylor University) and Charlie Escue (Indiana University), who liaised on behalf of many other contributors to iterate and test the new contributions. And thank you to the IT Accessibility working group members for their contributions and development of the initial HECVAT accessibility assessment instrument:

• Kyle Shachmut (Harvard University, IT Accessibility CG Co-Chair)
• Michael Cyr (University of Maine System, IT Accessibility CG Co-Chair)
• Mary Albert (Princeton University)
• Jill Bateman (Ohio University)
• Gwen A. Bostic (Western Michigan University)
• Jiatyan Chen (Stanford University)
• Glenn Dausch (Stony Brook University)
• Laura Fathauer (Miami University [OH])
• Greg Hanek (Indiana University)
• Tania Heap (University of North Texas)
• Lori Kressin (University of Virginia)
• Carmen Schafer (University of Missouri)
• Eudora Struble (Wake Forest University)
• Kate Tipton (California State University at Northridge)
• Todd Weissenberger (University of Iowa)

The groups plan to continue the partnership among rotating volunteer members to refresh content and supporting resources based on higher education IT community and partner feedback in line with the HECVAT update cycles.

Appendix: Questions List

Table 1 shows the accessibility questions added to HECVAT, organized by question theme.

Table 1. Accessibility Questions Incorporated into the 2021 HECVAT

Number	HECVAT Question ID	Question Theme	Question Text
1	GENL 11 to 13	Accessibility contact	Name, title, and contact information for the most appropriate accessibility contact for the product under consideration
2	DOCU-12	Accessibility standards conformance	Has a VPAT or ACR been created or updated for the product and version under consideration within the past year?
3	ITAC-01	Accessibility standards conformance	Has a third-party accessibility expert conducted an accessibility audit of the most recent version of your product?
4	ITAC-02	Accessibility standards conformance	Do you have a documented and implemented process for verifying accessibility conformance?
5	ITAC-03	Accessibility standards conformance	Have you adopted a technical or legal accessibility standard of conformance for the product in question?
6	ITAC-04	Accessibility standards conformance	Can you provide a current, detailed accessibility roadmap with delivery timelines
7	ITAC-05	Organization maturity for accessibility	Do you expect your staff to maintain a current skill set in IT accessibility?
8	ITAC-06	Organization maturity for accessibility	Do you have a documented and implemented process for reporting and tracking accessibility issues?
9	ITAC-07	Organization maturity for accessibility	Do you have documented processes and procedures for implementing accessibility into your development lifecycle?
10	ITAC-08	UX, support & documentation	Can all functions of the application or service be performed using only the keyboard?
11	ITAC-09	UX, support & documentation	Does your product rely on activating a special "accessibility mode," a "lite version," or accessing an alternate interface for accessibility purposes?
12	DOCU-13	UX, support & documentation	Do you have documentation to support the accessibility features of your product?

---

Kyle Shachmut is Assistant Director of Digital Accessibility at Harvard University and Co-Chair of the EDUCAUSE IT Accessibility Community Group.