Preparing Your Website for a VPAT Audit

A website should be considered ready for a VPAT audit only after accessibility issues have been tested, fixed, documented, and tied to clear evidence. A rushed review often creates a weak Accessibility Conformance Report, which can slow sales, procurement, and legal approval.

What a VPAT Audit Really Checks

A VPAT, or Voluntary Product Accessibility Template, is used to create an Accessibility Conformance Report. It shows how a digital product meets standards such as WCAG, Section 508, and EN 301 549. Public agencies, schools, healthcare groups, and large companies often request it before buying software or digital services.

The audit does not only ask whether a site “looks accessible.” It checks whether people using screen readers, keyboards, magnifiers, captions, voice input, and other assistive tools can use the site with fewer barriers. That means buttons, forms, error messages, menus, tables, media, and documents all matter.

Start With a Clear Site Inventory

The preparation should begin with a full inventory of the website. The team should list all page types, key user flows, logged-in screens, templates, forms, documents, videos, and third-party tools. This prevents surprise findings late in the audit.

Common items to include are:

• Public pages: home page, pricing, blog, support, legal, and contact pages.
• Core flows: account creation, login, checkout, search, booking, downloads, and payment.
• Interactive content: modals, filters, accordions, sliders, maps, and chat widgets.
• Documents: PDFs, reports, policy files, invoices, and downloadable forms.
• Media: videos, webinars, audio clips, and training content.

Honestly, it feels like many teams lose hours because one embedded widget or old PDF gets missed. Then the audit report flags it, and everyone acts shocked. A boring inventory prevents that mess.

Confirm the Standards Before Testing

The team should confirm which version of the VPAT template is needed. Different buyers may ask for different standards. A United States federal buyer may care about Section 508. A European buyer may ask for EN 301 549. Many commercial buyers focus on WCAG 2.1 AA or WCAG 2.2 AA.

This choice affects the audit scope. It also affects how findings are mapped in the final report. If the wrong template is used, the organization may need to redo parts of the work. That is costly and, frankly, annoying.

Run Automated and Manual Accessibility Tests

Automated tools are useful, but they are not enough. They may catch missing alt text, color contrast problems, invalid ARIA, empty buttons, and form label issues. Yet they often miss keyboard traps, confusing focus order, poor error recovery, and screen reader ambiguity.

A strong pre-audit process includes:

1. Automated scans across major templates and page groups.
2. Keyboard-only testing for every major task.
3. Screen reader testing with common tools such as NVDA, JAWS, VoiceOver, or TalkBack.
4. Color and zoom checks at 200% and 400% where relevant.
5. Form validation checks for clear labels, required fields, and error messages.
6. Mobile accessibility checks for touch targets, orientation, and assistive features.

Automated scans can give a false sense of safety. A page may show only two tool errors while still being hard to use with a keyboard. That gap is where many VPAT surprises begin.

Fix High-Risk Issues First

Not every issue carries the same weight. The team should first fix barriers that block task completion. A missing decorative image description may be less urgent than a checkout button that cannot receive keyboard focus.

Priority should usually go to:

• Keyboard blockers that stop a user from completing a flow.
• Missing or wrong form labels that harm data entry.
• Poor focus visibility that hides a user’s current position.
• Low contrast text on buttons, alerts, and key content.
• Unclear error messages that do not explain how to fix a problem.
• Missing captions or transcripts for required media.

Prepare Evidence for the Auditor

A VPAT audit becomes easier when the organization can show how the site was tested and repaired. Evidence does not need to be fancy. It needs to be clear, dated, and tied to specific criteria.

Useful evidence includes:

• Accessibility test plans and test dates.
• Browser, device, and assistive technology combinations.
• Issue logs with severity ratings.
• Before-and-after screenshots.
• Code commits or release notes tied to fixes.
• Known limitations and planned remediation dates.
• Design system rules for color, focus states, and components.

This documentation helps the auditor confirm claims. It also helps internal teams answer buyer questions after the VPAT is issued.

Review Third-Party Content and Integrations

Many sites rely on tools the internal team did not build. These may include analytics tags, payment forms, scheduling tools, chat platforms, maps, cookie banners, video players, and CRM forms. They can create accessibility defects inside an otherwise clean site.

The organization should gather accessibility statements or conformance reports from these vendors. If a vendor cannot provide useful accessibility information, the team should test the integration directly. If it fails, the organization may need a workaround, replacement, or clear disclosure in the VPAT.

Check Content Quality, Not Just Code

Content teams play a major role in VPAT readiness. Accessibility is not only a developer task. Headings need a logical order. Link text should make sense out of context. Images need helpful alt text when they convey meaning. Tables need proper headers. PDFs need tags and reading order.

Common content problems include:

• Links labeled only as “click here” or “learn more.”
• Headings skipped for visual styling.
• Images of text used instead of real text.
• PDFs exported without tags.
• Videos posted without captions.

These issues can be fixed before the audit and often do not require major engineering work.

Assign Clear Owners Before the Audit Begins

A VPAT audit touches product, design, content, legal, engineering, and sales. Without owners, simple fixes stall. The organization should assign one lead who manages scope, deadlines, auditor communication, and internal approvals.

Each finding should have a named owner, a target date, and a status. “Someone will fix it” is not a plan. It is how issues sit in a backlog for six months.

Plan for the Final VPAT Language

The final report should be accurate and careful. Overstating conformance can create risk. Understating it can hurt sales. The best VPAT reports use plain explanations, cite known limits, and avoid vague claims.

Typical conformance terms include supports, partially supports, does not support, and not applicable. Each answer should match real test results. If a feature only works after a user takes an unusual workaround, the report should say so.

FAQ

What is the main goal of a VPAT audit?

The goal is to assess how well a website or digital product meets accessibility standards and to support an accurate Accessibility Conformance Report.

How long does VPAT audit preparation take?

Preparation may take one to six weeks, depending on site size, technical debt, documents, media, and third-party tools.

Can automated tools prepare a site for a VPAT audit?

They help, but they cannot replace manual testing. Keyboard use, screen reader output, focus order, and task completion need human review.

Who should be involved in VPAT preparation?

Product managers, developers, designers, content writers, QA testers, legal teams, and procurement or sales staff should all be involved.

Should all issues be fixed before the VPAT is created?

Ideally, major blockers should be fixed first. Remaining issues should be documented with honest status notes and realistic remediation plans.