How to Review a VPAT

Today’s blog post explores a sample VPAT that crossed my desk, and I want to walk through why it raised so many red flags.

This is a true battle: VPAT versus The Accessibility Guy!

Video Guide

A VPAT, or Voluntary Product Accessibility Template, is a document vendors use to explain how accessible their product is. Companies often send a completed VPAT to potential customers so the customer can decide whether the software is safe to buy, approve, or adopt.

In theory, that is helpful. In practice, a VPAT only helps when someone actually reviews it.

The customer in this case really wanted to use the product. The vendor claimed the product met WCAG 2.2 standards. But once I looked past the headline claim and started reading the details, the VPAT did not hold up. I could not approve it in good faith.

That is the bigger lesson here: do not treat a VPAT as proof. Treat it as a document that needs review.

A VPAT May Not Reflect the Actual Product

A VPAT can look polished, complete, and official. It can also make a product sound more accessible than it really is.

That does not always mean the vendor is acting in bad faith. Sometimes the problem is weak testing. Maybe the person filling out the document doesn’t fully understand accessibility. Sometimes the language is too vague to help the buyer understand the real risk.

Whatever the reason, slow down and ask questions. A good VPAT should help you understand whether:

screen reader users can understand the interface
keyboard users can complete important tasks
buttons, image buttons, and form fields have clear labels
tables, headings, lists, and landmarks are coded correctly
the tested pages represent real user workflows
the vendor has a plan to fix known issues

The VPAT I reviewed did not give me that level of confidence.

“A Few Instances”

One phrase appeared again and again throughout the document: “a few instances.”

of missing labels.
of inappropriate labels.
of missing descriptions.
of incorrect heading levels.
of missing form labels.
of missing table headers.

At first, “a few instances” sounds manageable, like the kind of thing someone might fix quickly in the next release.

However, a few missing labels can block a user. A few keyboard problems can stop someone from completing a task. A few structural issues can make a page confusing for people using assistive technology.

The issue is not only the number of problems. The issue is where those problems appear and what they prevent users from doing.

“Partially Supports”

The vendor marked several criteria as “partially supports.”

That rating can be appropriate in some situations. A product might support most of a criterion while still having a limited, clearly documented issue.

When a VPAT uses “partially supports,” it should tell the buyer:

Where the issue occurs
Which users are affected
Whether the issue blocks a task
Whether there is a workaround
When the vendor plans to fix it

In this VPAT, the repeated use of “partially supports” made the report feel vague.

Non-Text Content Issues Are a Big Deal

Non-text content includes images, icons, image buttons, and other visual content that needs alternate text. If someone uses a screen reader, alt text helps them understand what the visual content means or what an image button does.

The VPAT admitted that the product had issues such as:

Missing labels for image buttons
Inappropriate labels for image buttons
Missing descriptions across tested pages

Those are not minor technical details.

If an image button does not have a useful label, a screen reader user may only hear something like “button.” That does not tell them what the button does. If the label is wrong, the interface can mislead the user. If descriptions are missing, important information may never reach the person who needs it.

So when a VPAT says this criterion is only partially supported, I want to know exactly where those issues appear. Are they on rarely used pages, or are they part of a core workflow? Are they cosmetic, or do they stop someone from using the product?

The VPAT did not give enough detail to answer that.

Forms Need Clear Labels

The report also mentioned missing labels for form controls, including buttons, combo boxes, input fields, and groups of related controls.

That matters because forms are where users do things. They enter information, make selections, submit requests, update records, approve items, and complete tasks.

When a form field does not have a clear label, people using assistive technology may not know what the field is asking for. When a group of form controls is not labeled properly, users may not understand how the options relate to each other.

This is especially important in business software, where forms are often tied to important workflows. A missing label in the wrong place can turn a routine task into a barrier.

Keyboard Support is Not Optional

The VPAT also said that a few image buttons lacked keyboard support.

Many people use a keyboard instead of a mouse. Some users cannot use a mouse at all. Others may use keyboard commands because they are faster or more reliable.

If a user cannot reach or activate an image button with the keyboard, that control may be unavailable to them. And if that control is required to complete a task, the task becomes unavailable too.

That is why the phrase “a few instances” does not make this issue feel small. One inaccessible button can stop an entire workflow.

Page Structure Helps People Navigate

The VPAT also listed issues with headings, lists, landmarks, and navigation regions.

Headings help users understand the page’s structure and navigate quickly between sections. Lists tell users when items belong together. Landmarks and navigation regions help users jump to major parts of the page, such as main content, search, navigation, and footer.

When these pieces are missing or coded incorrectly, users have to work harder to move through a page. They may need to listen through more content, guess where sections begin, or repeat steps to find what they need.

That extra friction matters. Accessibility is about getting through a page efficiently and confidently.

Tables Need Headers to Make Sense

The report also mentioned missing table headers.

Tables show reports, account records, invoices, schedules, user lists, analytics, approvals, and dashboards.

For sighted users, visual layout helps connect data to headings. Screen reader users depend on correct table markup to understand those same relationships.

Without headers, the data can lose meaning. A user may hear values without knowing which column or row they belong to.

“Not Applicable” is Not a Shortcut

Another thing that stood out was the number of “not applicable” entries.

When a VPAT marks something as not applicable, the report should explain why. Otherwise, the buyer has no way to know whether the criterion truly does not apply or whether the vendor skipped it.

TLDR; What a Strong VPAT Looks Like

A strong VPAT gives the buyer enough information to understand the product’s real accessibility status. At a minimum, it should include:

The product version tested
The date of the evaluation
The accessibility standard used
The pages, features, and workflows tested
The testing methods used
The assistive technologies used
The specific issues found
The impact of each issue
The remediation plan
The expected timeline for fixes
Contact information for accessibility questions

This helps buyers make better decisions, helps vendors build trust, and reduces the chance that users get stuck with inaccessible tools.

The Takeaway

The main takeaway is simple: read the details.

Do not stop at “meets WCAG 2.2.” or assume “partially supports” means the product is mostly fine. Don’t let “a few instances” hide issues that may affect real people doing real work.

A VPAT should give customers a clear view of accessibility. Review the document, ask for specifics, and require honest answers before adopting any product.

Let me be your champion for inclusion. I offer tailored solutions (and self-paced courses!) to ensure your documents meet and exceed compliance expectations. For more detailed insights, tutorials, and in-depth discussions on accessibility and related topics, don’t forget to check out my YouTube channel: The Accessibility Guy on YouTube. Subscribe for regular updates!