A Novice’s Guide to VPATs

John Lilly

If you’re new to the accessibility space, or even if you are not, you have probably heard the term “VPAT” (usually pronounced “vee-pat”) thrown around. So what is a VPAT, and why is it important?

When evaluating a vendor or product for potential use, one requirement that the product may (and definitely should) fulfill is that the product must be accessible for users using assistive technology. Before even evaluating the product, the first question to be asked is if the product is accessible, and if the developer claims it is, then a VPAT is usually provided as proof of the product being accessible.

VPATs are generally not provided to the public audience since they are intended to indicate to the government and other companies looking to use a product that it is accessible, but for some companies, you can request them although you may run into roadblocks if you are not actually trying to buy or use the product. But if you are planning to use a product yourself, seeking out the VPAT might be a helpful step in evaluating if the product will meet your needs. This is especially true when taking into account cost and the seriousness of your use case, e.g., using accounting software for a home business.

What is a VPAT?

VPAT stands for Voluntary Product Accessibility Template and is used as part of the Section 508 Standards which for the purpose of this discussion boils down to the rule that vendors and products that contract with the US Federal Government must meet certain accessibility standards, and the VPAT is documentation of how well the product conforms to those standards. VPATs are usually used for software which can include computer applications, websites, and mobile apps. They could also be included for certain types of hardware such as smart TVs, but they usually still detail the accessibility of the software or user interface associated with the hardware. You may have also heard of an ACR or Accessibility Conformance Report. Where the VPAT is simply an empty template, the ACR is a completed VPAT, and they are generally used interchangeably in conversations. For this article, we will just refer to them as VPATs.

Since 2017, the VPAT has been based on the Web Content Accessibility Guidelines or WCAG. WCAG is a set of accessibility guidelines that the World Wide Web Consortium or W3C maintains with input from accessibility experts across the world. The template contains a list of the WCAG success criteria and allows authors to document whether their product meets each of the success criteria.

Due to the voluntary nature of VPATs, they should not be used as proof of the product being accessible. VPATs can be written by anyone. You don’t have to have a special certification in order to fill out the template, but usually they are written by a third-party, independent accessibility expert in order to give the document more credibility. VPATs can also be written by the product owner themselves, but the product owner has a vested interest in showing their product in a good light. VPATs should only be used as a first step in the process of determining if a product is accessible. If the vendor does not have a VPAT for their product or has never heard of a VPAT, it is a pretty good indication that they have not taken accessibility seriously or at all.

If you did get a VPAT from a vendor, the first thing you should look at is the date that the VPAT was created. If it is over a year old, ask the vendor when the last major code update took place because there is a chance that the VPAT is no longer accurate due to changes that have been made to the product. If the VPAT seems particularly old, you will want to be extra skeptical of its claims to accessibility due to how quickly most digital products are updated these days.

How to Read a VPAT

VPATs should be treated as an initial step in the evaluation process for determining whether a vendor or product is accessible. If the vendor is honest, their VPAT will reflect what WCAG success criteria they meet, and what success criteria they partially meet or do not meet at all.

The meat of the VPAT is the list of WCAG success criteria. Typically each success criteria will have a conformance rating that the product meets. These ratings include:

• Supports - The product fully supports or meets the success criteria
• Partially Supports - The product supports or meets the success criteria with exceptions
• Does Not Support - The product does not support or meet the success criteria
• Not Applicable - The success criteria does not apply to the product. You typically see this response with success criteria like captions or audio descriptions when the product doesn’t contain any video or media.
• Not Evaluated - The product was not evaluated against the success criteria.

When a success criteria is rated as Partially Supports or Does Not Support, there should be an accompanying remark or explanation as to why the success criteria received that rating, which should give some examples as to why the product partially supports or does not support the success criteria.

The sample table below demonstrates the formatting of the VPAT:

If a success criteria is marked as “Partially Supports” or “Does Not Support”, that does not mean that the product is “not accessible”. It is very rare to see a product that is 100% accessible with zero issues, and that is very hard to achieve considering that not everyone interprets WCAG in the exact same manner. If you see “Partially Supports” or “Does Not Support” within the VPAT, you should ask the vendor why those are marked as such and when they plan on fixing those issues. You should also validate those issues yourself just to see how severe they are because those issues could be fairly minor or appear somewhere in the product that you do not have any plans of using.

Validating a VPAT

So, you’ve found or received a VPAT and the date on it appears reasonable, what is the next step? In order to be certain that the product is accessible, it is necessary to investigate its claims yourself to see if it is accurate. This doesn’t mean that you need to do a full accessibility audit of the product, but you should check some of the success criteria that they claim to support. For example, if they claim to fully support 1.1.1 Non-Text Content, check out some of the images within the product to make sure they do indeed have alternative text and that the alternative text is accurate. If the vendor refuses to give you access to test the product in order to validate the accessibility yourself, that should be considered a red flag. You as the purchaser bear the responsibility of the product being accessible from the standpoint of whoever is going to be using the product. If the vendor will not allow you to validate the accessibility yourself, it gives off the air of not caring about customer satisfaction.

On the other hand, if you see that a product has “Partially Supports” marked for some success criteria, verify the severity of the claim. It could be that the issue is more severe than what the VPAT is claiming, or it could be not that big of a deal such as a list not being coded correctly within the footer.

If you do not have the expertise or time to validate VPAT issues yourself or within your organization, contact the AFB Talent Lab. We have decades of comprehensive experience as well as individuals that use assistive technology on a daily basis.

Takeaways

VPATs should be thought of as a starting point for determining the accessibility of a product. You can think of them as the keys to the starting point of an accessible product. If they do not have a VPAT, have never heard of a VPAT, or refuse to share the VPAT with you, then it should be a big red flag that the product is most likely not accessible. VPATs should also never be used as proof of an accessible product if you are trying to determine whether a product is accessible or not. The VPAT could claim that the entire product is free from accessibility issues but was written 5 years ago and they have not produced a new VPAT since then. Or they could claim to have zero accessibility issues, but the product contains numerous accessibility issues after you have already signed a contract and started using it. Use the VPAT as a starting point and do a spot check of the claims that the VPAT is making. Don’t be afraid to ask the vendor questions about inconsistencies within the VPAT or concerns you may have because in the end, the VPAT is their claim of accessibility, and they should be able to defend their claims.