Last updated on November 14, 2025
This week I had a bunch of requests from clients surrounding VPATs and ACRs. This article will be a living article where I’ll post extra questions I receive as they come in.
What is a VPAT?
VPAT stands for Voluntary Product Attestation Template. The Information Technology Industry Council (ITIC) created this format. It is used for responding to governmental requests for purchase to report on a product’s accessibility. It is only a template. A completed VPAT is called an accessibility conformance report, or ACR.
What is an ACR?
Accessible Conformance Reports, or ACRs, are completed VPATs. In fact ACRs don’t even need to follow that template. But choosing not to use that template makes it difficult to prove your accessibility. It can be hard to defend it in court. You will lose chances at new business. Stick to the ITIC template for your maximum win.
How do you calculate the “Supports” level?
This is always confusing my clients when they first have to deal with getting an ACR. Let’s look at the supports levels available on the VPAT:
- Supports
- Does Not Support
- Partially Supports
For your ACR to read supports on any given success criteria, there must be zero WCAG violations. This applies to all pages that were part of the testing. This doesn’t mean you can get away with testing one perfect page and get a perfect ACR. The scope of testing is important.
Some folks out there will argue where to draw the line between “Partially Supports” and “Does not support.” The gist is this: If most controls support accessibility, we mark it as “partially supports.”
For me this is a hard line at 50%. If 51% of an identified success criteria do support accessibility, I will mark it as “Partially Supports.” Anything less means “Does not Support.”
Now we get to the tickler.
Supports levels are not calculated on a site wide basis, but on a document basis. Each document, or page, is tested. It will then score 0 or more than zero for a findings count on that success criteria. When you finish evaluating all of the pages, count how many pages have a finding for a given success criteria. Next, divide that number by the total pages tested. This is the percentage of failure. If it if it is 50% or higher, it is “Does not Support.”
The formula:
F = failed pages, P = total pages, X is solved for
100 - (F / P) = X%
- X% = 100 : Supports
- X% = is between 99% and 50% : Partially Supports
- X% = is between 50% and 30% : Must evaluate for blockers
- X% < 30% : Does Not Support
Must Evaluate for blockers
While a fail is a fail, a fail may not actually block the user from using the site. This all depends on what the failure is. For instance, if an image is missing alt text, but it doesn’t prevent the user from buying the product. This is because it is just one of a set of five on a product page. On the other hand, if the “Add to Cart” button doesn’t work by keyboard, the user is blocked from purchasing the product.
We determine the blocking status of the issue by focusing on the goal of the page. What is the happy path? Then we look at the criteria and ask ourselves, “SC# provides this equity to this group of users. As a user of this group, does this failure prevent me from my task?” If you can say yes, consider it a blocker. I mentioned alt text and keyboard already, so we’ll look at a contrast issue.
Success Criteria 1.4.3 sets the guidelines for text contrast. 1.4.11 does the same for graphical elements. Your “Learn More” button uses a blue background and light blue text that is 4.5:1. But it is placed on a background with less than 3:1 against the buttons blue. As a colorblind user, I cannot determine the function of this from sight alone. While the text is clear to read, it doesn’t say what it does. It isn’t clear it is a link, and I can’t see the borders of the button. With no other context, this would be considered a blocker. There is a very obvious workaround of “click everything,” but it is not considered as an option in WCAG.
My product is made of several smaller apps. How do I document this?
It is perfectly fine to evaluate and issues ACRs for the smaller products and apps. We can then reference them in the bigger, overarching product’s ACR.
My vendor provided an ACR for their product, how do I interpret it?
There are a few things we want to look for.
First, if it is “Supports” all the way across the board, this is a red flag. Achieving 100% conformance is possible. It’s the maintaining it over time that is hard. ACRs typically are not maintained on the same regularity as the product. And an ACR is a snapshot in time. It reflects how the site was at a given version on a given day.
The ACR must be extremely recent and have the exact same version number. If not, then there is likely something that wasn’t reported or caught. The timing depends on how often the client releases patches and updates. But if the ACR is more than a year old, it gets into the questionable area of accuracy. Any ACR older than two years old for a web product should be considered suspect. When dealing with embedded software or kiosks, there can be flexibility in that timing as those products age slower. But something else to learn from the ACR is how responsive the vendor is to change requests. If the ACR is older than a year, they might not be honest about the ACR. Alternatively, they might not make updates.
The age looks good, it isn’t a perfect “Supports,” the next steps require a little testing. Put the mouse aside. Turn on your screen reader. And take a quick test run through the product. Did they list something in the comments? Find it and try it. If it is as they report, there is some truth to the product. What about those things it Supports? Spend some time looking to disprove it. If you can’t, you are likely looking a good report.
The only way to truly know if the ACR is accurate is to pay for an independent audit. This is cost prohibitive for most companies. Imagine needing to spend $20,000 to $40,000 per platform to verify the accuracy of that ACR. Then your boss says you need three verified accessible bids. Now you are hoping the first three are accessible because the project doesn’t have another $120k to check.
Do I have to post my ACR on my website or app?
Not at all. A lot of companies will post a link to it on their sites. This is either because they get a lot of requests for it during a vendor vetting process. Or more likely, to dissuade frivolous lawsuits. Keep in mind, just because you have an ACR, it doesn’t mean you are accessible. It means you volunteered this information about the product.
Are all rules weighted the same?
This is a topic that is heavily debated even within the W3C. Success Criteria in level A are considered the bare minimum effort needed to call a site “accessible”. The next level, AA, are considered more advance techniques and more helpful. The AAA level has very strict requirements that limit designers and developers considerably.
As an industry, we’ve adopted the AA level as the minimum standard for considering a site conformant with accessibility. But that doesn’t answer the original question. Some argue that since A level are so basic, they mean more. Others argue that AA are worth more because the techniques are more advanced. And it truly doesn’t matter.
Each success criterion is looked at independently. Each page is judged for conformance. And the percentage of passing pages in a given success criterion determines the support level. In the end, their weight isn’t even calculated.
How do we prioritize raising our supports level?
I start by looking at the site architecture. Does it use templates? Web components? Reusable pieces?
If we have a component based site, fix an issue in one spot first. This will fix the same issue elsewhere. Start by fixing issues you have “Does not support.” Getting that over 51% will improve the look of your ACR.
If you have a site where things are a little less DRY, tackle one page at a time. Fix all the issues you find. While not focusing on the success criterion, we focus on fixing pages which will increase the level of supports.
Keep checking back for more questions as I get them.
Update 1 (10/15/2024)
Should we have a Third-Party create our VPAT?
Prepare your projects that require a VPAT early. Plan for the evaluation and authoring process. You can conduct the testing and writing in house. Or you can use a third-party.
You will get more push back and scrutiny if you conduct your own evaluation and author your own ACR. But you are perfectly allowed to do this.
You decided to get an ACR from a third-party. First thing to check is the reputation of the third-party. There are many players in the field that do this work, but that doesn’t make all ACRs equal.
You will get more traction if the evaluation and ACR are done by a third-party with a strong reputation. If your client works with the same company you do for evaluations, they probably won’t follow up much.
Update 2 (12/10/2024)
Can I use my vendor’s VPAT?
No.
Lots of organizations rely on a CMS of framework to develop their sites. Those products have an aspect to them we call “authoring” where they provide tools to create pages with. They define how a button works, you just style it. They define how tabpanels work, and you use their component to make your site.
It seems natural to think this way. The vendor got an ACR on these components in their system. So, why wouldn’t it apply to you?
The law doesn’t care
You decided to use VerbSquash as a back end. Any failings of the accessibility of a site built on VerbSquash is on the site creator. Your logo, your accessibility problems. There is an unwritten expectation that you will correct any failings in a product you use. There is also the expectation that if you can’t fix things directly, you work with the vendor to fix them.
What about open source projects?
Open source doesn’t run off the backs of goodwill. Folks are willing to share code across the world to make things easier for others. However, it doesn’t mean that a company has a right to use it for free.
Open source takes time and money to make. The developers of the project may not have time to fix your issue.
As a for profit company using open source software, you need to provide back to the community. This can be in the form of donations or direct payment for features. But it also includes you pitching in with the project. If you see that some code is inaccessible in the platform, fix it. Then file an issue with the code fix. Patch the code and send a pull request. This doesn’t release you from liability, but does offer a better path to fixing than commercial software.
But why can’t I use their VPAT?
Ultimately it comes down to the fact that they don’t know how you modified the component. In configuration A (system default) the component is fully accessible. But in configuration B (your customization), the colors or labels could be off. Maybe you used a “menu” role on an item that needed a different component type. Because we evaluate sites on a per document basis, even if the component is accessible, the page may not be.
The only real solution is to do your own evaluation. Hire a third-party if you can. And then issue the ACR from that evaluation.
Update 3 (08/28/2025)
I’ve update the formula used to calculate support levels. Through discussion with some colleagues, they convinced me that Does Not Support isn’t as black and white. For this, I’ve incorporated a grey zone in calculations. I’ve also provide some guidance on how to decide where in the grey the issue sits.