Dear 3rd party vendor: How to check 3rd party vendors for accessibility plus an email template

You’re assessing third-party software and want to make sure it’s accessible for all your users. This is a great start!

Now comes the tricky part. Communicating with 3rd party software companies to understand their commitment and current accessibility state. Most 3rd party software isn’t super accessible. You’ll run into vague responses or promises you need to double-check. This becomes trickier if you’re not an accessibility expert.

Don’t worry. In this article, we’ll focus on what you should ask for and what red flags to pay attention to. At the end is an email template you can use to start the accessibility conversation with your 3rd party vendors.

Even if you’re not an accessibility expert, you’ll be confident knowing you asked the right questions and took the right steps to understand the product’s current accessibility state, limitations, and roadmap so you can make an informed choice.

---

---

• Why checking 3rd party vendors’ accessibility matters
• 4 easy ways to check a vendor’s accessibility
• Red flags
• Dear vendor email template

Why checking 3rd party vendors’ accessibility matters

You’re already here, so you know your vendor’s accessibility matters. You can use these five reasons to get buy-in with your team or to add to your list of why it matters.

1. Your users. You are your user’s advocate. A 3rd party software that isn’t accessible could introduce barriers to your content that are frustrating or even impossible to get past for some users.
2. Your brand. A vendor’s software on your website or web app represents your organization’s brand. If your own software is accessible and then your introduce an inaccessible component, it can conflict with your brand’s values.
3. Protect yourself form legal retaliation. First, this isn’t legal advice. But, 3rd party plugins, code, or applications are often the source of accessibility issues that increase liability for you.
4. Understand the limitations. The majority of vendor’s won’t be completely accessible (or accessible at all unfortunately). Understanding the limitations increases your chances of finding the most accessible option and helps assess pros and cons between vendors.
5. You could make a difference. We approach accessibility conversations with vendor’s as an opportunity to show them the value-added by addressing accessibility in their software. It’s something that’s possible and important to do. This view point in your own conversations could get accessibility on the vendor’s radar and make it a priority for them too.

Back to top

4 easy ways to check a vendor’s accessibility

These four ways to check a vendor’s accessibility mostly include what you should ask your vendor. There are some actions you’ll want to take to check accessibility yourself.

1. Ask for a VPAT and if they follow WCAG accessibility standards

Let’s start with the technical stuff.

VPAT

VPAT means Voluntary Product Accessibility Template. This is an industry standard report vendors make to explain how the product does and does not meet accessibility standards. It can also give insight as to why some accessibility standards aren’t met.

The VPAT is a voluntary document the vendor completes themself. It’s not an accessibility audit, which is why it’s important to test the product yourself (we’ll cover exactly how further down).

You can check out the VPAT templates to understand what a vendor might send back. The VPAT 2.5 WCAG is a common VPAT report as WCAG accessibility standards are more familiar than others.

WCAG

That brings us to WCAG accessibility standards. WCAG means Web Content Accessibility Guidelines. It is considered the global standard for digital accessibility guidelines and is the basis for web accessibility laws in many countries. So, this is the standard most software follows.

Here’s what you need to know about WCAG:

• It’s a list of guidelines and success criterion. For example, a guideline is “Enough Time.” One success criterion under this guideline describes that moving, blinking, scrolling, or auto-updating content has a pause, stop, or hide functionality.
• It’s organized into three levels: Level A, AA, and AAA. Level AA is what most software aims for. There should be minimal accessibility issues if software is Level AA conformant. Level AA means they meet success criterion for Level A and AA.
• The most recent version is WCAG 2.2. It has all the most recent guidelines and success criteria.

The VPAT report lists all success criterion for Level A, AA, and AAA for vendors to address. You can explore the success criterion on the official WCAG 2.2 specs.

Vendor’s response

Keep in mind, when you ask the vendor for a VPAT and WCAG accessibility standards, they might not know what you mean. You might get a vague response about how “accessibility matters” or “yes, we conform to accessibility requirements.” Especially from the salesperson you’re communicating with.

This doesn’t mean you should end conversations with the vendor. But, it could mean pushing to ask the development team or providing them with more information about what you need, so they can give a better answer.

2. Include accessibility as a requirement

If you’re purchasing software, you have a list of requirements and maybe a Request for Proposal (RFP). In both of these, include your specific accessibility expectations. It’s a lot easier to hold the vendor accountable for certain accessibility agreements if they are detailed in writing.

For example, “The product follows WCAG 2.2 Level AA guidelines” is better than, “The product is accessible.”

3. Test accessibility yourself

There are two easy ways to test the product’s accessibility yourself. These aren’t a comprehensive audit, but it will help you double check what the vendor is saying and (quickly) get a better sense of its accessibility.

Free WAVE extension

The free WAVE extension tests web content for several different accessibility issues. (It’s also based on WCAG).

You can install and run the WAVE extension on a few pages of the vendor’s product to get an idea of what issues there are and how many.

Learn How to install and use the WAVE extension.

Keyboard testing

Keyboard testing is a quick manual accessibility test (seriously, 5 minutes) you can do to gauge the product’s accessibility. Basically, you want to make sure you can access everything using only a keyboard. That means navigating and using any widgets or interactions.

If there are several issues with keyboard testing, odds are there are issues with other assistive technology too.

Learn What to check for when keyboard testing and how to keyboard test.

4. Ask about their accessibility roadmap

Asking the vendor about their accessibility roadmap means asking them how they plan to become accessible and how they keep up and prioritize accessibility issues they find. How do they identify them? Once they do, do they die in a backlog or are they addressed?

You want to make sure that if they are accessible now, they’ll stay accessible. Or, if they aren’t accessible right now, understand if they have a plan on getting there.

Back to top

Red flags

Like we mentioned at the beginning, we approach accessibility conversations with vendors as an opportunity to show them the importance of accessibility. Your business could be what helps them incorporate accessibility and understand the importance of an accessible product.

That said, there are some red flags that could mean accessibility is not a priority for the vendor. It’s important to note these in your decision process.

1. Puts the responsibility on you to make adjustments or identify accessibility issues. While it can be helpful to give the vendor accessibility feedback, it is their responsibility to audit and make their product accessible. If they ask you to make it accessible or identify accessibility issues, it closes the door to a partnership where accessibility is concerned.
2. Aren’t familiar with a VPAT or WCAG. If pressed for a response on these items and you still don’t get a clear answer, it’s a sign they haven’t made much accessibility effort, or aren’t willing to.
3. Accessibility testing doesn’t align with what they’re saying. If you find a lot of issues in your limited accessibility testing and it isn’t matching their responses, that could mean they don’t understand accessibility or wouldn’t be a great partner.

Back to top

Dear vendor email template

This email template includes everything you should ask plus language to encourage a partnership and show the vendor the importance of accessibility.

---

Dear [vendor’s name],

We are evaluating your product because we believe you might be a good fit to help us [insert goal of partnership].

Part of this evaluation is assessing [product name]‘s accessibility. Accessibility is important to us because:

• It means more of our users can access our content without barriers.
• It aligns with our brand’s values.
• It protects us from legal issues.

Our goal is to partner with vendors who share a similar belief and commitment to accessibility. We do understand accessible digital products are a continuous effort and find value in consistent progress toward accessibility.

Our requests and questions to help us understand your current accessibility state and commitment are:

1. Send [insert product name]‘s VPAT.
2. Does [insert product name] follow WCAG 2.2? Provide 1-2 brief examples of this.
3. What is your roadmap for accessibility? In other words, what’s your plan to address current accessibility limitations and how do you currently identify accessibility issues and correct them?

Let us know if there are any questions about these requests. We’re happy to clarify what’s needed.

Back to top