Converge Accessibility

Introduction

Are Your Vendors Living Up to Their Accessibility Promises?

Are Your Vendors Living Up to Their Accessibility Promises?

A Dirty Not-So-Little Secret

Consulting is a rough business. It's hard to get rich. The work is constant and involves a lot of late nights. And the only guarantee that you'll have a roof over your head tomorrow is winning that big contract today. In the twenty years I've spent in the consulting world, I can tell you that the small print of a contract is rarely taken seriously unless the customer focuses on it.

It isn't just devious consultants that fail to live up to the terms of an agreement. As most of you know, Jeff and I have worked with NASA for over ten years and have conducted on-site reviews of grantees who receives thousands (sometimes millions) of dollars in grant money to help develop their educational programs. When you receive a grant from the Federal government, you agree (among other things) to not discriminate against persons with disabilities because of Section 504 of the Rehabilitation Act. The NASA regulations spell out a clear process-- you have to create a grievance procedure, appoint a designated responsible employee, and conduct a self-evaluation of your accessibility. Obviously, winning a NASA grant is a big deal if you are a museum or science center-- and the last thing a grantee wants is to have a grant withdrawn. Yet, whenever we point out these requirements that organizations have agreed to, there is noticeable discomfort in the room because few organizations go through the effort.

Don't get me wrong. I don't think that there is any malice or intent to deceive on the part of vendors. Instead, it's a matter of priorities. Among the dozens (or hundreds in the case of large Federal contracts) of regulations that need to be followed, accessibility is usually not as high of a priority as, say, network security. And, to someone who is not familiar with accessibility, they could just assume making a web based application meet the Web Content Accessibility Guidelines (WCAG) 2.0 A/AA is just a matter of adding a few lines of code so SURELY someone on the development team can easily handle it.

Of course, accessibility isn't that easy. And, if you're reading this blog post, accessibility probably IS a big deal to you. So how can you protect yourself when you are hiring a vendor?

Isn't a VPAT Enough?

When the original Section 508 requirements came out near the turn of the Millennium, the General Services Administration (GSA) and the Information Technology Industry Council (ITI) created the voluntary product accessibility template (VPAT), which is a simple table that outlines how a product conforms (or doesn't conform) to the Section 508 accessibility requirements. Fast forward to 2020 and now the VPAT still serves that function, although the format has become much more complex because of the addition of WCAG.

While the VPAT is an essential tool in the procurement process, vendors realized quickly that customers who wanted their products badly enough would be willing to overlook an incomplete VPAT. Others hid their VPATs because they feared they put the company at a competitive disadvantage. While companies like Microsoft are a notable exception and saw accessibility as a competitive advantage, other companies did not and undermined the effectiveness of the VPAT as a driver for accessibility.

Traditional Approach: Build Testing and Remediation into the Contract

Process flow that demonstrates a vendor winning a contract. Then a 3rd party tester evaluates the product for accessibility. The accessibility errors are then fixed by the vendor and the 3rd part tester retests the remediated code. Eventually, the product is deployed to the customer.

If you are a big customer (such as a large state agency), you can use your market power to require winning vendors to undergo third party testing and agree to remediate any found issues. How does this work? Simple. In your request for proposals (RFP), include a note that winning vendors must agree to have their application tested for accessibility by a third-party that they will agree to remediate any identified issues within a fixed period (e.g. six months) or the contract is nullified. Then, you go about the procurement as usual and, once you have selected a winner, you require that vendor to go through third-party testing before the contract is awarded. At one point, the company I used to work with (HiSoftware) was one of the third-party testing companies used by the Commonwealth of Massachusetts under this kind of accessibility scheme. This process is depicted in the diagram above. The third-party tester evaluates the products and identifies accessibility deficiencies, which are fixed by the vendor. And then this cycle repeat until there are no significant accessibility errors. Once it is fully accessible, it is delivered to the customer.

In general, I think that these strategies work relatively well for larger organizations that can offer enticingly large contracts for IT vendors. But they also are really expensive and introduce delays into the procurement process of up to a year or more. After all, all that testing and remediation takes a lot of time!

Better Approach: Document Accessibility Throughout Design and Build

Process flow demonstrating how WebAlign makes achieving accessibility quicker. The vendor is required to use WebAlign. Vendor Designs product using WebAlign. Once design has addressed the core concepts in WebAlign, the Vendor can write the code using WebAlign. Once code has been written using the core concepts in WebAlign, the Vendor then test the product using WebAlign. Because of WebAlign, product incorporates accessibility quicker, vendor is awarded contract and delivers an accessible product. Throughout the whole process following WebAlign allows vendor to provide progress reports to customer during development lifecycle.

A far quicker approach is to use WebAlign to guide your vendor's design and development efforts. For less than the cost of one round of third-party testing, the vendor's design and development teams can all be enrolled in WebAlign. This gives them access to WebAlign's training modules and checklists and have them return their checklists during the design and development process. WebAlign's short training modules are tightly integrated with the role-specific checklists so there's no excuse to not fully meet WCAG at all stages of the development process.

As depicted in the diagram above, the process of introducing WebAlign is fundamentally different from the traditional approach described earlier. Instead, all vendors use WebAlign during all stages of the design and development process. As teams complete their checklists, they also provide their checklists to the customer. This gives customers assurance that WCAG 2.1 A/AA is being fully considered at the design, development, and QA levels. While no process can guarantee full accessibility, WebAlign's constant visibility into accessibility comes as close as possible to guaranteeing a fully accessible end product.

  • FASTER (MUCH, MUCH FASTER) PROCUREMENTS. Testing, retrofitting, and retesting code adds a LOT of time to the procurement process. Everyone knows that it is better to plan and build things right from the beginning instead of trying to fix something that is inherently inaccessible. So don't add months (or years) unnecessarily to your procurements-- get WebAlign and know things are being done correctly.
  • BETTER ACCESSIBILITY. Fixing something that is inherently inaccessible rarely comes out as well as something that is designed with accessibility in mind from the beginning. For instance, when something is designed with accessibility in mind at the start, it's easier to focus to making the user path as smooth as possible for all users instead of struggling with basic features.
  • MORE TRANSPARENCY (AND LESS WORRYING). Because you'll see progress throughout the process, you'll know that accessibility was considered in the design stage-- so colors not only meet the contrast requirements but also meet your organization's sense of aesthetics. Completely changing your design palate the day before launch because your vendor didn't consider color contrast would give anyone lots of sleepless nights-- but these types of stresses disappear if your vendor is required to use WebAlign.
  • ULTIMATELY CHEAPER PROCUREMENTS. Even if you continue to use third-party testers to check your vendor's wares prior to delivery, using WebAlign will still save your organization time and money. The reason is that it takes companies a lot of time and money to fix inaccessible products. Using WebAlign means that your vendor will likely get a clean bill of health from the outset-- and so any small changes can be implemented quickly and efficiently. This means you get your vendor's products faster and cheaper. Plus, you avoid costly opportunity costs that would result from not being to roll out delivery sooner (and forcing your employees, for instance, to use an outmoded system longer).

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 “Are Your Vendors Living Up to Their Accessibility Promises?

Leave a Reply

Your email address will not be published. Required fields are marked *