Skip to content

VPAT Maintenance — Keeping Accessibility Conformance Reports Current

DodaTech Updated 2026-06-28 5 min read

In this tutorial, you will learn about VPAT Maintenance. We cover key concepts, practical examples, and best practices to help you master this topic.

VPAT maintenance involves regular review cycles, updating criteria ratings after product changes, re-testing after Accessibility fixes, version control, and communicating updates to buyers and stakeholders.

What You'll Learn

You will learn how to establish a VPAT maintenance cycle, when to update the report, how to manage version history, and how to communicate changes to stakeholders.

Why It Matters

An outdated VPAT loses credibility with buyers. A product that has changed significantly since the last VPAT evaluation may have different conformance characteristics. Regular maintenance ensures your VPAT always reflects the current state.

Real-World Use

DodaTech schedules VPAT maintenance every quarter with a full review cycle. Minor updates happen after each product release. The VPAT includes a version history table showing every revision.

flowchart TD
  A[VPAT Maintenance] --> B[Quarterly Review]
  A --> C[Post-Release Update]
  A --> D[Major Version Re-evaluation]
  B --> E[Check criteria ratings]
  B --> F[Update remarks if needed]
  C --> G[Test new features]
  C --> H[Add criteria for new functionality]
  D --> I[Full re-evaluation]
  D --> J[Complete criteria table rewrite]

The Maintenance Cycle

Quarterly Review

Every three months, review the VPAT to verify that all criteria ratings are still accurate. Product changes, browser updates, and assistive technology versions can affect conformance.

Post-Release Update

After each product release, update the VPAT to reflect new features and any accessibility changes. New features may introduce new criteria or change existing ratings.

Major Version Re-evaluation

When the product undergoes a major version change, conduct a full re-evaluation. The existing VPAT is unlikely to be accurate for a substantially different product.

class VPATMaintenance {
  constructor(product, version) {
    this.product = product;
    this.version = version;
    this.history = [];
    this.lastReviewDate = null;
  }

  recordReview(type, changes) {
    const entry = {
      date: new Date().toISOString().split('T')[0],
      type: type,
      version: this.version,
      changes: changes,
      reviewer: null
    };
    this.history.push(entry);
    this.lastReviewDate = entry.date;
    return entry;
  }

  assignReviewer(entryIndex, reviewer) {
    if (this.history[entryIndex]) {
      this.history[entryIndex].reviewer = reviewer;
    }
  }

  getVersionHistory() {
    return this.history.map(h =>
      `[${h.date}] ${h.type} — v${h.version}${h.changes.length} changes (Reviewer: ${h.reviewer || 'unassigned'})`
    ).join('\n');
  }
}

const vpat = new VPATMaintenance('Durga Antivirus Pro', '5.2.0');
vpat.recordReview('Quarterly', ['Updated remarks for SC 1.4.3', 'Added new criteria for dashboard widget']);
vpat.recordReview('Post-Release', ['SC 2.1.1 changed from Partially Supports to Supports', 'Added SC 2.5.8 for new voice control feature']);
vpat.assignReviewer(0, 'A. Test Engineer');
vpat.assignReviewer(1, 'B. Accessibility Lead');
console.log(vpat.getVersionHistory());

Expected output:

[2026-06-28] Quarterly — v5.2.0 — 2 changes (Reviewer: A. Test Engineer)
[2026-06-28] Post-Release — v5.2.0 — 2 changes (Reviewer: B. Accessibility Lead)

Version Control

Maintain a version history table in the VPAT. Include the date, version, author, and summary of changes. This provides transparency to buyers about how the report has evolved.

<table aria-label="VPAT version history">
  <caption>Revision History for Durga Antivirus Pro VPAT</caption>
  <thead>
    <tr>
      <th scope="col">Date</th>
      <th scope="col">Version</th>
      <th scope="col">Author</th>
      <th scope="col">Changes</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>2026-06-28</td>
      <td>2.0</td>
      <td>Accessibility Team</td>
      <td>Initial VPAT 2.4 for version 5.2.0</td>
    </tr>
    <tr>
      <td>2026-03-15</td>
      <td>1.3</td>
      <td>Accessibility Team</td>
      <td>Quarterly review. Updated 4 remarks. Added SC 2.5.8.</td>
    </tr>
    <tr>
      <td>2025-12-01</td>
      <td>1.2</td>
      <td>Accessibility Team</td>
      <td>Post-release update for v5.1.0. Re-tested 12 criteria.</td>
    </tr>
  </tbody>
</table>

Communicating Updates

When a VPAT is updated, notify stakeholders who rely on it. This includes procurement teams, enterprise customers, and government contract officers. Provide a summary of changes and a link to the new version.

Common Mistakes

1. Forgetting to Update the VPAT After Product Changes

Every feature release can affect accessibility. Test and update the VPAT after each release, not just annually.

2. Keeping Old VPATs Public

When a VPAT is superseded, archive the old version. Do not keep outdated VPATs in public distribution.

3. Not Tracking Version History

Without version history, buyers cannot see when or why ratings changed. Transparency builds trust.

4. Updating the VPAT Without Re-testing

Changing a rating without testing undermines the entire report. Always re-test before updating.

5. Ignoring Assistive Technology Updates

New screen reader versions can change how content is rendered. Update testing environments and re-test.

6. Not Assigning a VPAT Owner

One person should own the VPAT maintenance Process. Without an owner, updates fall through the cracks.

7. Missing Browser or OS Updates

Browser and OS updates can introduce accessibility changes. Re-test after major browser or OS releases.

Practice Questions

1. How often should a VPAT be reviewed?

At minimum quarterly. Review after each product release and after major browser or assistive technology updates.

2. What triggers a full VPAT re-evaluation?

A major product version change that substantially alters the product's features or interface.

3. What information should a VPAT version history include?

Date, product version, author, summary of changes, and reviewer name.

4. Who should be notified when a VPAT is updated?

Procurement teams, enterprise customers, government contract officers, and any stakeholders relying on the report.

5. Challenge: Create a maintenance schedule for a product with quarterly releases. Map out review dates for the next 12 months.

FAQ

Can I reuse the same VPAT for multiple product versions?

Only if the versions are minor and do not introduce significant changes. Major versions require a new evaluation.

What if a new WCAG version is released?

Plan a transition period. Evaluate against the new version and update the VPAT within the transition deadline.

Should I update the VPAT if no changes were made?

At minimum, update the review date to show the VPAT was reviewed. Stale dates reduce credibility.

How do I retire an old VPAT?

Move it to an archive folder, update your website to point to the new version, and inform stakeholders of the change.

Who should own VPAT maintenance?

A designated accessibility specialist or QA engineer who understands both the product and accessibility testing.

Mini Project

Create a VPAT maintenance calendar. Schedule quarterly reviews for the next 12 months. Define triggers for unscheduled updates and list stakeholders who should receive notifications.

What's Next

Complete the VPAT Project where you will practice creating a full VPAT from evaluation through submission.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro