VPAT Development: Accessibility Report Template

VPAT Development — Accessibility Report Template

When participating in tenders for US government agencies or commercial procurement of large corporations, without a VPAT (Voluntary Product Accessibility Template) the application is automatically rejected. Manually preparing this report takes weeks and requires deep knowledge of WCAG and Section 508 standards. We create a turnkey VPAT: conduct an accessibility audit, document each criterion, and prepare the final report suitable for customers. As a result, you get a document that not only opens access to government contracts but also increases trust among users with disabilities. Our VPAT preparation service starts from $2,500, depending on product complexity, and automation can reduce manual effort by up to 40% compared to traditional methods.

VPAT Versions

VPAT templates are available on the IT Industry Council (itic.org) website. The version choice determines the audit requirements.

Why VPAT is Mandatory for Government Procurement?

Government contracts in the US and Europe require accessibility confirmation. Lack of VPAT leads to application rejection or penalties up to 10% of the budget. Companies ignoring this lose access to million-dollar contracts. Our experience shows: even partial compliance with WCAG 2.1 Level AA significantly increases chances of winning. Time and budget savings through draft automation — up to 40%.

Risks of Not Having VPAT

In addition to fines up to 10% of the budget, lack of VPAT blocks participation in procurement from giants such as US government IT systems (GSA) and European state structures. Reputational risks: users with disabilities may file a complaint about website inaccessibility, leading to lawsuits. In some jurisdictions, the absence of a report equates to violating disability law (e.g., ADA in the US).

VPAT Structure

VPAT consists of tables for each WCAG section. For each criterion, the support level is indicated:

Components of an Accessibility Audit

The audit is the foundation of VPAT. We conduct systematic manual testing with screen readers (NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari) and automated tools (axe-core, WAVE). All WCAG Success Criteria at Level A and AA are checked: keyboard navigation, contrast, semantics, animations, alternative text, ARIA attributes. Special attention is paid to critical errors: missing focus, keyboard traps, unreadable contrasts.

VPAT Preparation Process

Step 1: Product Audit

A systematic manual test is performed with screen readers (NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari) and automated tools (axe-core, WAVE). We test all sections: keyboard navigation, contrast, semantics, animations.

Step 2: Filling Criteria

For each WCAG Success Criterion (78 total for Level AA in 2.1):

1.1.1 Non-text Content (Level A)
  Criteria: Supports
  Remarks: All images have appropriate alt text. Decorative images
           use empty alt="" attribute. Complex charts include
           long description via aria-describedby.

Step 3: Documenting Limitations

1.4.3 Contrast (Minimum) (Level AA)
  Criteria: Partially Supports
  Remarks: Most text meets 4.5:1 contrast ratio requirement.
           Exception: placeholder text in form fields uses #9ca3af
           on white background (2.7:1 ratio). Fix planned in upcoming release.
           Workaround: Users can use browser high contrast mode.

Accelerating VPAT Preparation with Automation

Automatic VPAT filling is 2-3 times faster than manual, but accuracy requires manual verification. Use a script to generate a draft:

// scripts/generate-vpat-draft.js
// Based on axe-core report, generate a VPAT draft

const WCAG_CRITERIA = require('./wcag-criteria.json');  // List of all criteria

async function generateVpatDraft(axeReport) {
  const violations = new Set(axeReport.violations.map(v => v.tags).flat()
    .filter(t => t.startsWith('wcag')));

  const draft = WCAG_CRITERIA.map(criterion => ({
    id:       criterion.id,
    title:    criterion.title,
    level:    criterion.level,
    support:  violations.has(criterion.wcag_tag) ? 'Partially Supports' : 'Supports',
    remarks:  violations.has(criterion.wcag_tag)
      ? `Automated testing found issues: ${axeReport.violations.filter(v => v.tags.includes(criterion.wcag_tag)).map(v => v.description).join('; ')}`
      : 'No issues detected in automated testing. Manual verification recommended.',
  }));

  // Generate Markdown
  return draft.map(c =>
    `### ${c.id} ${c.title} (Level ${c.level})\n\n**${c.support}**\n\n${c.remarks}\n`
  ).join('\n');
}

The draft requires mandatory manual verification — automation covers about 40% of criteria. The remaining 60% are nuances of keyboard, focus styles, prefers-reduced-motion.

Typical Manual Checks

• Keyboard navigation (Tab/Shift+Tab/Enter/Space/Escape/arrow keys)
• Compatibility with NVDA, JAWS, VoiceOver
• Zoom 200% and 400% without loss of functionality
• Windows high contrast mode
• Animations with prefers-reduced-motion
• Session timeouts and warnings

What Is Included in the Work

• Full accessibility audit with detailed report for each criterion
• Filling VPAT 2.4 (required version)
• Documentation of all accessibility limitations and recommendations for fixing
• Raw audit data and final report suitable for customer presentation
• Team training on keeping VPAT up-to-date
• One month of post-delivery support

We guarantee data confidentiality. All certified specialists have experience with WCAG 2.1/2.2. Our team has over 10 years of experience in accessibility and has completed more than 150 VPAT audits for clients ranging from startups to Fortune 500 companies.

Timelines

Audit, VPAT 2.4 filling, and its review take 5 to 10 business days depending on product complexity. For urgent projects, accelerated preparation is possible.

Order an accessibility audit — and we will prepare VPAT in 5–10 days. Contact us for a free project assessment.

Website Accessibility: WCAG, Screen Readers, Keyboard Navigation

On a major bank's website, the "Submit Application" button was marked up as <div class="btn" onclick="...">. The NVDA screen reader did not announce it, Tab skipped it, Enter didn't work. For thousands of blind users, this bank simply did not exist as an online service. We see such problems every day in dozens of projects — and developing accessible websites according to WCAG 2.2 AA has become the only way to avoid discrimination and legal risks. Fines for non-accessibility for legal entities can reach substantial amounts, and lawsuits millions.

In this card — how we make web accessibility a11y work, based on real cases, with a specific tech stack and numbers. No generic phrases.

Why is Semantic Markup the Foundation of Web Accessibility (a11y)?

Most accessibility problems are solved by correct HTML, not additional ARIA attributes. <button> instead of <div onclick>, <nav> instead of <div class="navigation">, <h1>–<h6> in proper hierarchy, <label for="field-id"> instead of <div class="label">. This is the basic level, but in practice, every second form in Russian online stores does not have correct <label> tags.

ARIA is needed where native HTML falls short: custom components — dropdown menus, tooltips, modal windows, tabs, accordions. And here the complexity begins.

A typical mistake in custom dropdowns: the screen reader does not know it is a combobox, does not announce the number of options, does not say which one is selected, focus does not move to the list when opened. Proper implementation:

• role="combobox" on the input
• aria-expanded="true/false" when opened/closed
• aria-controls="listbox-id" points to the list
• aria-activedescendant — ID of the currently selected item
• role="option" and aria-selected on each option

This is not theory; it is tested with a screen reader. NVDA + Chrome or VoiceOver + Safari is a mandatory part of QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Select city</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Cities">
    <li role="option" aria-selected="false" id="opt-1">Moscow</li>
    <li role="option" aria-selected="false" id="opt-2">St. Petersburg</li>
  </ul>
</div>

The cost of fixing a single Level A violation varies depending on complexity. Implementing a11y from the design stage reduces the refactoring budget by 2–3 times compared to retrofitting a finished site.

How to Properly Build Keyboard Navigation?

Tab order should match the visual order of elements. If in HTML the "Cancel" button comes before "Confirm", but CSS swaps them — the keyboard user is confused.

Focus trap in modal windows. When a modal opens, Tab should cycle only within it. When closing, return focus to the element that opened the modal. Without this, the user ends up at the top of the page after closing.

tabindex="-1" — element does not enter Tab sequence but can receive focus programmatically. Used for elements that receive focus via JavaScript (section headings after anchor navigation).

tabindex="1" and above is almost always an error. Explicit order breaks natural order and creates unpredictable behavior. Control order via DOM, not tabindex.

Skip links — a "Skip to content" link, hidden visually, visible on Tab. Allows screen reader users to skip repetitive navigation.

Color and Contrast: Requirements and Common Violations

WCAG 2.2 AA requires contrast 4.5:1 for normal text, 3:1 for large text (18px+ or 14px+ bold). AAA requires 7:1 and 4.5:1.

The most common violations: gray placeholder in inputs (#999 on white = 2.9:1), light gray secondary text, white text on pastel backgrounds.

Color should not be the sole indicator: "required fields are red" without an asterisk — violation for color blind users.

Testing tools: axe DevTools, WAVE, Accessibility Inspector in Chrome DevTools. axe-core integrates into Playwright tests: automatic check of 80+ rules on every deployment. Manual testing finds about 60% more errors than automated.

What Is Important About Media Content and Dynamics?

Images without alt — a common basic failure. alt should be meaningful: not alt="image_123.jpg", but a description of content relevant to context. Decorative images — alt="" (empty, not missing attribute).

Video should have captions. YouTube auto-captions are not a standard; they make mistakes. WebVTT files with correct captions for all educational and marketing video content.

Animations — a problem for users with vestibular disorders. @media (prefers-reduced-motion: reduce) — media query that disables or slows animations for users with that OS setting.

What Changed in WCAG 2.2?

Version 2.2 came into effect with new criteria:

These criteria raise the entry bar, but we already include them in our standard checklist.

Audit and Remediation

Automated tools find about 30–40% of violations. The rest is only manual testing. Minimum scenario: go through the entire critical user flow (registration, purchase, form) using only keyboard and screen reader.

Process

1. Automated audit — axe-core, Lighthouse, WAVE — outputs 80+ rules.
2. Manual testing — NVDA, VoiceOver, keyboard — 2–3 days for a typical site.
3. Violation prioritization — P1 (blocks usage), P2 (creates difficulties), P3 (enhancements).
4. Fixing — iteratively, integrate checks into CI via Playwright + axe.
5. Re-audit — close all P1/P2 before release.
6. Documentation and handover — report with results, maintenance recommendations, team training.

Results and Scope

• Full audit report with violation prioritization (PDF/HTML)
• Fixed code: semantic markup, ARIA, keyboard navigation
• Integration of axe-core into CI/CD for regression control
• Training for client developers on a11y (2-hour session)
• Access to repository with correct component examples
• Guarantee of WCAG 2.2 AA compliance at time of delivery

Timeline

Budget is calculated individually after the audit. Contact us — we will evaluate your project in 1 day. Get a consultation and free checklist when ordering an audit.

Experience and Guarantees

We have been working in web accessibility a11y for over 8 years. Completed more than 50 projects for banks, retail, and government. Certified specialists (IAAP CPACC, WAS). We guarantee passing a third-party audit or will fix for free.

WCAG 2.2 Standard — official W3C recommendation defining web content accessibility requirements.

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

— web accessibility levels a11y per version 2.2.

Order an audit now — get a checklist and preliminary estimate for free. Contact us – we will respond within an hour.