Introduction

Pushing Public Sector Accessibility from the Bottom Up – Part 3

Pushing Public Sector Accessibility from the Bottom Up – Part 3

This is Part 3 in my series about promoting digital accessibility in state and local government procurements. Part 1 explained the problem and some of the ideas I’ve learned as an entrepreneurial new business owner wiggling my way into the local government procurement process. Part 2 summarizes the different approaches I’ve tried over the last few months—plus my thoughts on how to use each approach in the most effective way possible. Part 3 takes the opposite angle and describes how local governments can improve accessibility through the procurement process—and do it in a way that won’t cost an arm and a leg.

Digital Accessibility is Hard

Most governments understand that making their websites and other digital technologies accessible is critical for residents with disabilities accessing government services. Local governments often post information about events to their websites or through electronic email before other media. Using digital technology is so much faster, easier, and less expensive than using older technologies that digital media is often the only way of accessing the services, benefits, and activities of local government.

The problem, however, is that digital accessibility is hard. Making a website accessible requires a detailed understanding of HTML, JavaScript, and CSS—and how these technologies impact people with different disabilities. Most IT vendors, however, don’t understand how their choices affect people with disabilities so websites are rarely made accessible. Yet, even if a website is coded properly, accessible websites don’t include features that reveal their accessibility readily to the untrained eye. This leads to two unfortunate outcomes.

First, because accessibility is hard for developers, most products are inaccessible. The Web Content Accessibility Guidelines (WCAG) are vague and imprecise. As a consequence, vendors may focus on minor accessibility features while excluding major features critical to users with disabilities. And, because WCAG is vague, developers and testers cannot identify exactly what needs to be included and what must be excluded. Also, this means that developers can honestly believe that their products are accessible even when they are not.

Second, because accessibility is hard for buyers, local governments need to rely on their vendor’s assurances about accessibility. We’ll take on this issue in the next section, but asking a vendor whether their product is accessible is a bit like walking into the local Porsche dealership and asking, “do any of these cars go fast?” From a cynical perspective, accessibility is just a marketing exercise. But, even from a less cynical perspective, how can we expect vendors to accurately assess the accessibility of their product against a standard (WCAG) that they don’t understand?

While this situation may sound hopeless, there are a few strategies that state and local governments can use to implement accessibility.

Approach 1: Ask for a VPAT or ACR

The simplest thing that a state or local agency can do is ask the vendor for documentation about the accessibility of their products. Shortly after the first Section 508 standards were developed in 2000, the Information Technology Industry Council (ITI) and the General Services Administration (GSA) developed the Voluntary Product Accessibility Template (VPAT) as a standard reporting tool that vendors could use to document how closely their products conformed to the original Section 508 standards. As we know, the Access Board amended these standards in 2017 to align with the W3C’s Web Content Accessibility Guidelines (WCAG) 2.0 so the VPAT is now an ideal means of documenting the accessibility of web pages. Once a vendor completes the VPAT template and includes all necessary documentation, the template is obviously no longer a template—so it magically changes its name to an Accessibility Conformance Report (ACR). The GSA expects Federal agencies to ask for and evaluate ACRs during IT purchases to ensure agencies comply with Section 508.

While the VPAT and ACR process was developed for the Federal government, other organizations were quick to adopt the format. And, because IT accessibility standards worldwide have largely harmonized with WCAG, the VPAT now helps vendors meet the accessibility needs of their customers at every level from international bodies down to state and local governments. If you are part of a state or local government agency that is thinking about developing or refreshing its website (e.g. changing to a more robust content management system), then it makes perfect sense to require your vendors to complete a VPAT and provide an ACR.

If every company was diligent and had expertise in accessibility, the VPAT and ACR model would work splendidly. Unfortunately, as we discussed earlier, most vendors have little to no expertise in accessibility. Consequently, VPATs are filled out incorrectly and the resulting ACRs are inaccurate. So, while VPATs and ACRs are great ideas, they simply aren’t enough in most cases to ensure that IT procurements will be accessible.

Approach 2: Rely on Evaluators with Disabilities

Often people with disabilities are the most effective advocates for accessible IT. Many times, particular employees or members of the public are the loudest voices for accessibility—and agencies sometimes turn to these individuals to assess whether their products are accessible. For most buyers, this makes sense—accessibility is hard to discern or understand. But a user with a disability should understand better than anyone whether accessibility is included.

The problem with this logic is that it reduces accessibility to the usability impressions of a single user or a small group of users. This is problematic for several reasons. First, if the user is not trained to test to accessibility standards, they may miss issues that affect other disabilities. For instance, if your website is perfectly usable by a blind user, that doesn’t mean that your videos are captioned or that your color contrast is correct. Second, a disabled user’s experience in evaluating a product will be largely shaped by their expertise in their assistive technology. This problem frequently comes up when a new screen reader user is blocked on a website because they don’t understand how to navigate with their screen reader. Also, screen readers can artificially compensate for bad code and give a novice screen reader user a false impression of compliance. For instance, JAWS commonly assumes that data tables are not coded correctly and will read the first row as a set of header cells—thus making an inaccessible table appear to be accessible. Third, no tester can know what they can’t know. If a region of the screen is completely unavailable to assistive technology, a blind user may not know that the region exists and may consider the screen accessible when it is quite inaccessible.

I am certainly not suggesting that people with disabilities should not be part of the testing process or that user feedback isn’t important during an IT procurement. Instead, I believe it is important to not rely only on the feedback of a small group of disabled users.

Approach 3: Encourage Third-Party Verification

As a consultant in IT accessibility, it may seem a bit self-serving for me to suggest that state and local governments should rely on third parties to verify the accessibility of products. Unfortunately, however, accessibility is hard and so in most cases, the only way to really know if a product conforms to guidelines like WCAG is to hire an accessibility consultant who truly understands WCAG.

Identify a Pool of Qualified Accessibility Vendors

Some states use a process where they let accessibility consultants compete to become eligible for accessibility projects. Then, when the state is thinking about an IT project, prospective vendors need to work with one of these consultants to have their products tested. This means that testing is done at a professional level and against universal design standards like WCAG.

Put the Burden on the Vendor

Accessibility is hard enough for buyers. There is absolutely no reason that we should expect procurement officers or IT professionals to become accessibility experts. Vendors, however, have a vested interest in making their products accessible because it opens their products to bigger markets and enables them to compete more effectively. Thus, state and local governments should require vendors to have their products tested by a trusted accessibility vendor.

In my last post, I described a strategy for consultants to insert themselves into the procurement process. In most cases, this means that the state or local government agency is paying directly for those accessibility services. Instead, state and local governments should try to make their vendors pay for accessibility assessments. Asking a vendor to spend over $10,000 to have their product assessed for accessibility, however, is a tall ask. For large Commercial Off the Shelf (COTS) purchases, agencies may be able to get away with this early in the procurement process. For custom projects or smaller IT purchases, however, agencies may need to first identify a small pool of finalists before asking them for an accessibility audit later in the procurement process.

Request an ACR and Remediation Plan

Any accessibility consultant worth their salt knows exactly what needs to be done to create an ACR. And, because IT vendors usually don’t understand accessibility, their ACR will usually look terrible—particularly if they didn’t try to focus on accessibility during the product’s development.

This is completely normal. Because so few products are completely accessible, WCAG should be viewed as an aspirational standard. A messy ACR identifies where the major accessibility gaps exist—and guides agencies and vendors in creating a remediation plan to close these gaps. So state and local governments should ask for an ACR and work with their vendors to create a remediation plan that balances the agency’s need to quickly buy the products they need and the agency’s obligation to ensure that their IT procurements are accessible.

Ask for an Accessibility Demonstration

Because accessibility is hard to discern, it makes sense for the vendor to demonstrate how a product can be used by users with different disabilities in common scenarios. For instance, imagine a university is thinking about buying a chat widget for deploying on its website. The chat client can be accessed by prospective students and can provide some automated responses to common question (e.g. “how do I apply for financial aid?”) as well as connecting to a live agent for difficult questions. The university has reduced the candidates in their procurement to a pool of three finalists and asks each one to demonstrate how a blind user using NVDA would ask about in-state residency requirements and escalate their question to a live agent. Then they may ask each finalist how a ZoomText user would search for student housing options at the university.

Performing these demonstrations obviously requires a high level of proficiency with different assistive technologies and most vendors will need to rely on an accessibility consultant to demonstrate these features.

An accessibility demonstration is also a great way to leverage evaluators with disabilities in an objective and unbiased way. For instance, if your agency has a particularly vocal employee with a disability, getting them involved to validate the accessibility consultant’s work both gives them a voice in the process and ensures a high level of accessibility.

Combining Approaches

Any carpenter knows that having the right tool for the job makes all the difference between an easy project and a difficult one. And having a variety of tools at your disposal—and knowing when to use each one—will serve any procurement officer well as they work to ensure that accessibility requirements are met. For instance, in a small web project with a small budget and minimal exposure, asking for an ACR may be all that can be required. But, with larger projects of higher impact, a more robust combination may be needed. The important point is to have the right tools at your disposal when you need them.

Listen to Cheryl Pruitt

I don’t think there is one approach that works with every organization and every procurement. What works at a massive Federal agency may not work with a small municipality. Also, buying COTS software from multinational vendors with internal accessibility teams is completely different from hiring a single developer to write a custom web-based application.

But there is one person who can help steer any organization through the accessibility challenges in any procurement. Cheryl Pruitt has been at the helm of accessibility for California State University’s Office of the Chancellor. We hope to be presenting with Cheryl in the coming months at various events. Stay tuned for more details!

Want to See More Content Like This?

Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!

We're Here to Help When You're Ready

Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.

0 comments on “Pushing Public Sector Accessibility from the Bottom Up – Part 3

Leave a Reply

Your email address will not be published.