Skip to content
Beta Multi-model support (OpenAI, Gemini, and more) launching soon.

accessibility-vpat-acr

Installable Ships in accessibility-auditor — or copy the raw skill below.
Open Claude.ai

Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V.

ExperimentalNo security review

Accessibility VPAT / ACR Drafting

Produce a formal Accessibility Conformance Report (ACR) using the VPAT 2.5 template. The ACR is the completed version of the VPAT — the document that vendors, agencies, and clients submit to satisfy procurement, legal, or programme requirements.

Usage

/accessibility-vpat-acr <audit-report-path> [--edition wcag|eu|int|508] [--product-name "Name"] [--version "1.0"]

Examples:

  • /accessibility-vpat-acr audit-report.md --edition wcag --product-name "RBA Commerce Site"
  • /accessibility-vpat-acr findings.md --edition eu --product-name "Client Portal" --version "2.3.1"
  • /accessibility-vpat-acr findings.md --edition int — produces all three standards in one document

VPAT Edition Selection Guide

Edition Standard When to use
WCAG WCAG 2.0 / 2.1 / 2.2 Most web/mobile products; general accessibility claims
508 Revised Section 508 US federal government procurement
EU EN 301 549 European clients; EAA compliance documentation
INT 508 + EN 301 549 + WCAG International clients; broadest coverage

Default to WCAG edition unless the client specifies otherwise. For EAA-affected EU clients, use EU edition (EN 301 549 maps to WCAG 2.1 AA at minimum; WCAG 2.2 AA exceeds the requirement).


Phase 1 — Ingest Audit Findings

Read the provided audit report or findings summary. Extract:

  1. Product information — name, version, description, audit date, auditor name
  2. Scope — which pages, components, or user flows were evaluated
  3. Per-criterion conformance ratings — from the WCAG 2.2 AA conformance table
  4. Remarks — specific failure descriptions and partial-support conditions
  5. Evaluation methodology — tools used, manual testing approach

If the input is a raw finding list rather than a structured report, map each finding to its success criterion before proceeding.


Phase 2 — Populate the ACR Header

## Accessibility Conformance Report
### Based on VPAT® Version 2.5

**Name of Product/Version:** <product name> v<version>
**Report Date:** <YYYY-MM-DD>
**Report Version:** 1.0
**Product Description:** <one-paragraph description of the product and its primary audience>

**Contact information:**
RBA Consulting
Accessibility Practice
<contact email>

**Notes:**
This ACR evaluates conformance against WCAG 2.2 Level AA. The evaluation covered the following
scope: <list pages/flows/components>. Evaluation was conducted using axe-core <version>,
Playwright <version>, and expert manual review using NVDA <version> on Windows 11 and VoiceOver
on macOS <version>.

**Evaluation Methods Used:**
Automated testing (axe-core/Playwright), expert manual keyboard navigation, screen reader testing
(NVDA + Chrome, VoiceOver + Safari), and colour contrast analysis (APCA / WCAG contrast algorithm).

Phase 3 — Conformance Rating Rules

Apply these rules when assigning ratings:

Supports The product fully meets the criterion for all evaluated content/functionality. No exceptions or workarounds are required.

Partially Supports The product meets the criterion for some content/functionality but not all. Must document: what passes, what fails, and the specific exceptions.

Does Not Support The product does not meet the criterion. The feature or content type is present but inaccessible.

Not Applicable The criterion does not apply to this product or the evaluated scope. Examples: SC 1.2.x (media captions) on a product with no audio/video content.

Criteria with "Does Not Support" must be listed as findings in the audit report. Do not assign "Not Applicable" to avoid a difficult finding.


Phase 4 — WCAG 2.2 Success Criteria Table

Populate one row per criterion. Pull conformance ratings from the audit report.

Template row format:

| <SC> | <Name> | <Supports / Partially Supports / Does Not Support / Not Applicable> | <Remarks and Explanations> |

Remarks column guidance:

  • For Supports: brief confirmation ("All images have descriptive alt text. CMS makes alt text a required field.")
  • For Partially Supports: list the exceptions ("All decorative images use alt="". Informational images on /about/ are missing alt text. Editorial fix in progress.")
  • For Does Not Support: describe the failure and reference the audit finding ID.
  • For Not Applicable: state why ("This product contains no audio-only or video-only media.")

Section structure for WCAG Edition:

## Table 1: Success Criteria, Level A

| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Supports | … |
| 1.2.1 Audio-only and Video-only | Not Applicable | … |
…

## Table 2: Success Criteria, Level AA

| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) | Not Applicable | … |
| 1.3.4 Orientation | Supports | … |
| 1.3.5 Identify Input Purpose | Partially Supports | … |
| 2.4.11 Focus Not Obscured (Minimum) | Does Not Support | … |
| 2.5.7 Dragging Movements | Not Applicable | … |
| 2.5.8 Target Size (Minimum) | Partially Supports | … |
| 3.2.6 Consistent Help | Supports | … |
| 3.3.7 Redundant Entry | Supports | … |
| 3.3.8 Accessible Authentication (Minimum) | Not Applicable | … |
…

Append a Legal Disclaimer section:

## Legal Disclaimer

This Accessibility Conformance Report is based on a representative evaluation of the product
conducted on the dates specified. Conformance levels reflect the state of the product at the time
of evaluation. Future updates to the product may affect conformance.

RBA Consulting provides this report as a professional assessment. It does not constitute legal
advice and does not guarantee compliance with any specific regulation (ADA, Section 508, EAA, AODA,
or other). Clients are responsible for ensuring their digital products meet applicable legal
requirements in their jurisdiction.

This report follows the VPAT® 2.5 format published by the Information Technology Industry Council
(ITI). VPAT® is a registered trademark of the Information Technology Industry Council.

Phase 6 — EN 301 549 Annex (EU Edition)

For EU edition, append the EN 301 549 annex after the WCAG table. EN 301 549 v3.2.1 (2021) Clause 9 maps directly to WCAG 2.1 AA. Where WCAG 2.2 exceeds 2.1, note it as going beyond the mandatory standard.

## Table EN 301 549: Clause 9 — Web (EN 301 549 v3.2.1)

Clause 9 requires conformance with WCAG 2.1 Level AA. This product has been evaluated against
WCAG 2.2 Level AA, which is backward-compatible with and exceeds WCAG 2.1 Level AA requirements.

| EN 301 549 Clause | WCAG Mapping | Conformance |
|---|---|---|
| 9.1.1.1 | 1.1.1 Non-text Content | <rating> |
…

Phase 7 — Output and Delivery

Write the completed ACR to acr-<product-slug>-<YYYY-MM-DD>.md.

Advise the client/team:

  • ACRs should be reviewed annually or after any major product update.
  • "Does Not Support" findings should have a remediation timeline appended.
  • For live EU-market products: the EAA requires an Accessibility Statement on the website — this ACR can form the technical evidence base for that statement.
  • For Section 508 / US federal: submit the ACR as part of the product's procurement package. The contracting officer may request VPAT 2.5 508 Edition specifically.

Reference

Technical details
Plugin
accessibility-auditor
Author
Dakota Smith
Skill name
accessibility-vpat-acr
Maturity
experimental
Security review
No security review
Owners
  • design
  • engineering
  • security
Argument hint
<audit-report-path or findings-summary> [--edition wcag|eu|int|508] [--product-name "<name>"] [--version "<version>"]
Allowed tools
  • Read
  • Bash(cat *)
  • Bash(ls *)
  • Write
  • Edit
Source
plugins/accessibility-auditor/skills/accessibility-vpat-acr/SKILL.md

Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.