name: vpat description: Use when auditing web projects for WCAG 2.1 / Section 508 accessibility compliance, generating Accessibility Conformance Reports (ACR), or fixing accessibility gaps found during audit user-invokable: true args:

• name: scope description: "audit" to run accessibility audit, "acr" to generate the ACR document, or "fix" to remediate findings (default: audit) required: false metadata: author: Dylan Goldblatt version: 1.0.0 license: MIT tags:
  • accessibility
  • wcag
  • vpat
  • section-508
  • a11y
  • audit
  • acr filePattern:
  • "**/*.html"
  • "**/*.tsx"
  • "**/*.jsx"
  • "**/*.css"
  • "**/accessibility*"
  • "**/a11y*"
  • "**/vpat*"
  • "**/acr*" bashPattern:
  • "lighthouse"
  • "axe"
  • "pa11y"

VPAT — Accessibility Audit & ACR Generator

Overview

The VPAT (Voluntary Product Accessibility Template) is a standardized template created by the Information Technology Industry Council (ITI). When you fill it out for a specific product, the result is an ACR (Accessibility Conformance Report). This skill automates both the audit process and ACR generation for web applications.

Core standard: WCAG 2.1 Level A and AA — the globally recognized benchmark for web accessibility, referenced by Section 508, EN 301 549, and most procurement policies.

When to Use

• Before a product launch or procurement response
• When a customer or institution requires a VPAT/ACR
• During accessibility remediation sprints
• As a periodic compliance check

Audit Workflow

START
  │
  ▼
┌─────────────────────────┐
│ 1. READ the codebase    │  Identify all pages, components,
│    (HTML, CSS, JS/TSX)  │  interactive elements, media
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│ 2. PERCEIVABLE          │  Alt text, headings, contrast,
│    (WCAG 1.x criteria)  │  text resize, reflow, spacing
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│ 3. OPERABLE             │  Keyboard access, skip links,
│    (WCAG 2.x criteria)  │  focus visible, no traps, timing
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│ 4. UNDERSTANDABLE       │  Lang attr, predictable behavior,
│    (WCAG 3.x criteria)  │  error identification, labels
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│ 5. ROBUST               │  Valid markup, ARIA name/role/value,
│    (WCAG 4.x criteria)  │  status messages
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│ 6. SECTION 508 CHAPTERS │  Ch3: Functional Performance
│    (beyond WCAG)        │  Ch4: Hardware (usually N/A)
│                         │  Ch5: Software (usually N/A for web)
│                         │  Ch6: Support Documentation
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│ 7. RATE each criterion  │  Supports / Partially Supports /
│                         │  Does Not Support / Not Applicable
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│ 8. GENERATE ACR         │  Fill the VPAT 2.4 template
│    (→ reference/        │  with findings and ratings
│     acr-template.md)    │
└─────────────────────────┘

Conformance Rating Guide

Use these exact phrases — they are standardized by the ITI VPAT:

Remarks are REQUIRED for "Partially Supports" and "Does Not Support". Encouraged for "Supports".

Decision heuristic for Partially vs Does Not Support

Is the CORE user journey affected?
  YES → Does Not Support
  NO  → Are affected areas secondary/edge-case?
          YES → Partially Supports (document which areas fail)
          NO  → Does Not Support

Quick Reference — Code-Level Checks

Perceivable (WCAG 1.x)

Operable (WCAG 2.x)

Understandable (WCAG 3.x)

Robust (WCAG 4.x)

Section 508 Chapters

Chapter 3 — Functional Performance Criteria

Applies to all web products. Ensures people with disabilities can use all product functions:

• Without vision → screen reader compatible
• With limited vision → magnification, contrast
• Without color perception → not color-dependent
• Without hearing → captions/transcripts (if audio)
• With limited manipulation → keyboard-operable
• With limited reach → N/A for web (physical)
• With limited language/cognitive → clear labeling, simple navigation

Chapter 4 — Hardware

Typically Not Applicable for web applications. Applies to physical hardware (kiosks, terminals).

Chapter 5 — Software

Typically Not Applicable for web-only products. Applies to native platform software. If the product includes a desktop/mobile app, this chapter applies.

Chapter 6 — Support Documentation and Services

Applies to all products:

• Documentation describes accessibility features
• Documentation is available in accessible formats
• Support services accommodate users with disabilities

ACR Generation

After completing the audit, generate the ACR using the template at → reference/acr-template.md

Fill in:

1. Title page — Product name, version, date, evaluator, methods
2. WCAG 2.1 Level A table — Rate every A criterion
3. WCAG 2.1 Level AA table — Rate every AA criterion
4. Section 508 tables — Chapters 3 and 6 (mark 4 and 5 as N/A if web-only)
5. Remarks — Specific, actionable details for every non-Supports rating

Common Mistakes

• Vague remarks: "Some issues exist" — instead, describe exactly which components fail and how
• Skipping N/A criteria: Still list them with "Not Applicable" and a brief reason
• Rating "Supports" without testing: Every "Supports" should be verifiable
• Ignoring dynamic content: SPAs must audit route changes, modals, toast notifications, lazy-loaded content
• Forgetting third-party components: Cookie banners, analytics widgets, embedded iframes all need auditing