Third-party vendor management with accessibility and suppliers icons

Accessibility Program Fundamentals: 3rd-Party Vendor Management

Those who are new to accessibility oftentimes think it’s a one-and-done assessment and remediation process. But in a world of rapidly changing websites and applications, accessibility can be a moving target. Sustainable and cost-effective accessibility means building a culture of accessibility into one’s organization and mission.

Introducing an accessibility program can include a myriad of things, from proper tooling to building accessible internal applications for employees. One important topic that comes up time and time again is learning how to manage your third-party vendors so their products are accessible. Third-party software can range from an outsourced tool or application to plug-ins or reusable components from outside your organization.

In this post, we will discuss how your organization can properly manage its third-party vendors via a policy so that accessibility is a priority.

Step 1: State Your Commitment to Digital Accessibility

Here’s an example:

“[Your Organization] is committed to providing an inclusive and accessible digital experience to all users, clients, and employees regardless of ability. We strive to ensure that all digital products developed, purchased, or used by [Your Organization] comply with established accessibility standards.”

This statement sets the tone, reinforces accessibility as a priority, and this language can be reused in other accessibility policy documentation.

Step 2: Define Your Accessibility Requirements

This typically means picking an existing accessibility standard that vendors need to comply with. If your organization must comply with existing accessibility regulations (like Section 508), you’ll want your vendors to comply with those regulations as well.

If you don’t have any existing accessibility compliance requirements, your safest bet is to require compliance with the W3C’s Web Content Accessibility Guidelines, version 2.0 (WCAG 2.0), levels A and AA. WCAG 2.0 serves as the basis for most accessibility regulations worldwide.

Some organizations are proactively looking to WCAG 2.1 levels A and AA, the updated guidelines which were released on June 5th, 2018 which are starting to be more regularly adopted.

Step 3: Identify All Potential Sources for 3rd-Party Content

While identifying third party content may seem straightforward, most companies overlook non-standard content from B2B relationships. For example, if your vendor has contract language on your company’s website. Identifying and defining all the content that could be 3rd party content requires additional organization and process integration.

Step 4: Assign a Position To Be Responsible for Accessibility

There are two very important questions you need to answer before you complete this section:

  1.  Who, within your organization, is responsible for ensuring that 3rd-party products and deliverables comply with your accessibility guidelines?
  2. How can they ensure accessibility guidelines are followed and others in the organization maintain them?

For example, if your  Procurement Officer is responsible, they may be tasked to ensure accessibility by having an internal Accessibility Coordinator to test the vendor’s product. Or, maybe responsibility belongs to Project Managers, and they must require vendors to submit expert-certified proof that their products are accessible.

This section will be unique to your organization’s structure and processes, and it is imperative that you make sure everyone on your team knows and understands their responsibilities. Additionally, if your organization has an existing IT risk assessment and approval process, you will need to work with them to include accessibility in their assessments and reporting.

Step 5: Define Your Procurement and RFP Process

In order to win an RFP, third-party vendors must demonstrate compliance with the accessibility requirements laid out in the RFP or contract.

Common of Accessibility Certification types vendors should have to be properly vetted:

  • VPAT (Voluntary Product Accessibility Template)
  • PDAA (Policy-Driven Adoption of Accessibility)

The long-term goal is to have contractual clauses in place that require a scorecard for accessibility.

Any exceptions to accessibility requirements requested by the vendor must be documented and formally submitted to the appropriate member of your organization. Additionally, the vendor should include a warranty assuring your organization that they will take responsibility for fixing accessibility issues found within a certain time after the completion of the project.

Step 6: Explain in Your Exception Request Process

While your organization should strive to provide the most accessible experience possible, sometimes exceptions need to be made. A common example is color contrast issues where the contrast ratio between the text and the background is just slightly off of the prescribed number, but the specific colors are part of the overall brand and design.

Depending on the context of this issue, it may be worth making an exception. Your policy documentation should cover…

  • The Exception Request process
  • Which of your team members will be responsible for reviewing requests and maintain records of exception requests
  • A list of the information required in an Exception Request (e.g. description of the issue, the justification for the exception including relevant cost avoidance estimates, a plan for alternate means of access, etc.)

Step 7: Ensure Accountability

The last section of your policy should explain consequences to the vendor if they fail to meet your accessibility requirements (e.g. activation of warranty, loss of contract, loss of option to renew the contract, etc.).

In some cases, this could mean charging the vendor back the accessibility fees as a clawback provision. Additionally, contract language could cover remediation service level objectives and agreements in the event that accessibility issues are found after production.

If you would like more information about specific contract language, you may contact us to inquire about our Accessibility Program Office consulting as a service.

In Summary

One of the hardest accessibility challenges for accessibility programs can be changing the culture around procurement and third-party vendors. However, by using a policy similar to the one outlined above, organizations can start the process of procuring new, accessible vendors and work accessibility terms and conditions into their existing contracts. If all the major players start demanding accessible products from the vendors, then moving the needle towards procuring accessible software will become easier and easier.

Photo of Greg Williams

About Greg Williams

Greg Williams is the Vice President & Chief Program Architect at Deque Systems, Inc. He oversees program development and operations for some of Deque’s largest customers, helping them to build mature, sustainable accessibility programs.

Prior to joining Deque, Greg spent more than 30 years in the information technology field focusing on large, complex program operations for Fortune 40 companies and before that served in the United States Navy for a number of years. He had great success as the founder and owner of the Digital Accessibility Program Office for State Farm Insurance, building their practice from the ground up into one of the highest maturity level programs in the world between 2013 and 2018.

Greg has always been passionate about diversity and inclusion and has extended this passion to the disability and accessibility community - joining Deque Systems in 2018 to help launch and mature similarly successful programs across the globe.
update selasa

Comments 2 responses

  1. Hello,

    We need to evaluate a mobile application in regards to WCAG 2.1. Do you offer such a service for a mobile apps?

    Best Regards
    Aleksandar Stefanov

  2. Hi Aleksandar – Yes, we do offer tools, services and training for native mobile accessibility as well.

Leave a Reply

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