A useful VPAT audit starts with proof, not promises. If a product claims support for accessibility, the audit should show what was tested, where it passed, where it failed, and what the team will fix next. A weak VPAT can create sales delays, procurement pushback, legal risk, and a lot of awkward follow-up questions.
TLDR: Most VPAT problems come from vague ratings, old templates, shallow testing, and missing remediation plans. For example, a SaaS team may claim “supports” for WCAG 2.1 keyboard access, while its main billing form traps focus in a modal after three tab presses. In one internal review of 60 product flows, teams often found that 25% to 40% of issues were tied to forms, focus order, or unclear error messages. Fix the evidence first, then update the VPAT with plain, testable statements.
What a VPAT Audit Really Checks
A Voluntary Product Accessibility Template, or VPAT, is used to create an Accessibility Conformance Report. Buyers use it to judge whether software, hardware, documents, or digital services meet standards such as WCAG, Section 508, and EN 301 549.
The audit is not just a paperwork exercise. At least, it should not be. It should compare what the VPAT says against what the product actually does. This includes reviewing user flows, interface behavior, assistive technology support, code patterns, documentation, and known defects.
Honestly, it feels like some reports were written to dodge decisions. They say “partially supports” on half the criteria, then give no details. That helps nobody. Procurement teams need clarity. Product teams need tasks. Users need working access.
1. Using the Wrong VPAT Version
One common issue is an outdated template. A vendor may submit a VPAT based on WCAG 2.0 when the buyer expects WCAG 2.1 or 2.2. Some reports also miss regional requirements. A product sold to public agencies in the United States may need Section 508 coverage. A product sold in Europe may need EN 301 549.
How to address it:
- Confirm the buyer’s required standard before the audit starts.
- Use the latest official VPAT template from the ITI site.
- State the exact version used in the report header.
- Keep older VPATs archived, but do not reuse them as current proof.
A report based on the wrong template can be rejected before anyone reads the details. That is a painful way to lose two weeks.
2. Vague Conformance Language
Terms like supports, partially supports, and does not support need explanation. A VPAT that says “partially supports” with no note is incomplete. The reader has no idea if the issue is minor, severe, rare, or present on every screen.
Bad note: “Some accessibility issues exist.”
Better note: “The settings page supports keyboard input, but the account deletion modal does not return focus to the trigger button after close.”
How to address it: Write notes that name the affected feature, the user impact, and the condition that triggers the issue. Keep the wording direct. Avoid legal fog. If the product fails a criterion, say so and explain the fix plan.
3. Relying Only on Automated Testing
Automated tools are useful. They catch missing labels, color contrast failures, invalid ARIA, and some structural problems. But they do not catch everything. They will not reliably tell you if a screen reader announcement makes sense. They may miss broken focus order. They cannot judge whether instructions are clear.
Expect to waste time on false confidence if the audit is tool-only. A dashboard may score 96%, while a keyboard user still cannot reach the export button.
How to address it:
- Use automated scans as the first pass, not the final answer.
- Test core flows manually with keyboard only.
- Test with screen readers such as NVDA, JAWS, VoiceOver, or TalkBack.
- Review error handling, modals, menus, tables, and custom widgets by hand.
4. Missing Critical User Flows
A VPAT audit often fails because it tests the easy pages. Home page. Login page. Static help page. Fine, but not enough. The real problems usually live inside account setup, checkout, dashboards, file upload, reporting tools, maps, or admin screens.
How to address it: Build a test plan around user goals. For a payroll product, test adding an employee, running payroll, correcting an error, exporting a report, and changing tax settings. For an ecommerce platform, test search, filters, cart, payment, discounts, order tracking, and returns.
5. Keyboard Access Problems
Keyboard access issues are among the most common audit findings. Users may get stuck in a modal. Links may not receive visible focus. Dropdowns may open with a mouse but fail with Enter or Space. Focus may jump to random areas after an action.
The annoyance is real. A date picker that adds 12 seconds to each task because focus keeps resetting is not a tiny bug. It compounds fast for users who handle forms all day.
How to address it:
- Make every interactive element reachable by keyboard.
- Use logical focus order that matches the visual order.
- Show a clear focus indicator.
- Return focus to the right place after closing dialogs.
- Test custom controls against expected keyboard patterns.
6. Poor Color Contrast and Visual States
Contrast failures are easy to find and still oddly common. Light gray text on white backgrounds. Pale blue links. Disabled-looking active buttons. Error messages shown only with red borders. These issues affect users with low vision, color blindness, glare, eye strain, and aging vision.
How to address it: Check text and interface components against WCAG contrast requirements. Do not use color alone to show status. Pair color with text, icons, patterns, or labels. Update design tokens so the same mistake does not return in the next release.
7. Weak Form Labels and Error Messages
Forms create a large share of VPAT findings. Common defects include missing labels, vague placeholders, unlabeled required fields, errors that appear too late, and summary messages that do not move focus.
How to address it:
- Connect every input to a visible or accessible label.
- Mark required fields in text, not only with an asterisk.
- Tell users what went wrong and how to fix it.
- Place errors near the related fields.
- Announce errors to screen reader users when forms fail.
8. Misused ARIA
ARIA can improve access when used well. It can also break a working interface. Common problems include clickable <div> elements with no role, buttons mislabeled as links, live regions that announce too much, and hidden content that screen readers still reach.
How to address it: Use native HTML first. A real <button> is usually better than a scripted element with several ARIA attributes. When ARIA is required, test it with assistive technology. Do not assume the code reads the way it looks.
9. Ignoring Documents, PDFs, and Help Content
Many audits focus on the application and skip attached documents. That is risky. Product guides, invoices, exported reports, training decks, and PDFs may be part of the user experience. If they are inaccessible, the VPAT should say so.
How to address it: Audit sample documents. Check headings, reading order, tags, tables, alt text, form fields, and document titles. If exports are generated by the product, test several real examples, not a polished sample file.
10. No Remediation Plan
A VPAT that lists failures with no plan leaves buyers uneasy. They need to know what will be fixed, when, and how severe each issue is. Product teams need the same thing.
How to address it: Add a remediation tracker outside the VPAT. Include:
- Issue description
- WCAG or legal criterion
- Affected feature
- Severity
- Owner
- Target release
- Retest result
How to Make Your Next VPAT Audit Stronger
Start with scope. List the product version, platforms, browsers, assistive technologies, and user flows tested. Then run automated and manual checks. Record evidence. Be honest about gaps. Update the VPAT only after the findings are confirmed.
The strongest reports are specific. They do not oversell. They help buyers make decisions and help teams fix defects. That is the real point of a VPAT audit: not to create a pretty document, but to show the current state of access and move the product closer to equal use.
