Accessibility Documentation Templates: VPATs, Statements, and Plans

Documenting accessibility is as important as implementing it. Documentation communicates your accessibility status to customers, demonstrates compliance to regulators, supports procurement decisions, and provides a roadmap for improvement. This guide covers the key document types, where to find templates, and how to use them effectively.

Voluntary Product Accessibility Template (VPAT) / Accessibility Conformance Report (ACR)

What It Is

A VPAT is a standardized document that vendors use to describe the accessibility of their products. When completed, it becomes an Accessibility Conformance Report (ACR). The VPAT template structure was created by the Information Technology Industry Council (ITI) and is updated to align with current standards.

Current Version

The VPAT 2.5 template (as of 2024) includes columns for:

• WCAG 2.2 (web content accessibility)
• Revised Section 508 (U.S. federal ICT)
• EN 301 549 (European ICT accessibility)

Vendors can complete all three editions or select the ones relevant to their market.

Where to Find It

The ITI VPAT template is available free at itic.org/policy/accessibility/vpat. Templates are provided in multiple editions: WCAG only, Section 508 only, EU only, and International (all three).

How to Complete It

For each success criterion or requirement, report:

• Conformance level: Supports, Partially Supports, Does Not Support, Not Applicable
• Remarks and explanations: Specific details about how the product meets or fails the criterion, workarounds, and known issues

A well-completed VPAT is honest about limitations. Claiming “Supports” for criteria the product does not fully meet erodes trust and creates legal risk.

Accessibility Statement

What It Is

An accessibility statement is a public document on your website or product that describes your commitment to accessibility, your current conformance status, known limitations, and how users can report issues or request accommodations.

What to Include

W3C WAI provides a generator tool and guidance for accessibility statements. Key elements:

1. Commitment statement: Your organization’s commitment to accessibility
2. Standards referenced: Which version of WCAG you target and at what level
3. Conformance status: Current conformance status (fully conformant, partially conformant, non-conformant)
4. Known limitations: Specific accessibility issues you are aware of, with explanations
5. Feedback mechanism: How users can report accessibility issues (email, phone, form)
6. Enforcement procedure: (Required in some jurisdictions) How unresolved issues can be escalated
7. Date: When the statement was last updated

Where to Find Templates

• W3C WAI Accessibility Statement Generator: w3.org/WAI/planning/statements/generator
• EU Web Accessibility Directive model statement: Provided by the European Commission for public sector organizations
• Section 508 guidance: Section508.gov provides federal accessibility statement guidance

Best Practices

• Update the statement at least annually and after significant product changes
• Be honest about known limitations rather than claiming perfection
• Provide multiple contact methods (not just a form that might itself be inaccessible)
• Include the date of the most recent accessibility evaluation

Accessibility Plan / Roadmap

What It Is

An internal or public document that describes your organization’s plan for achieving and maintaining accessibility. It includes goals, timelines, responsibilities, and milestones.

Key Components

1. Current state assessment: Baseline accessibility audit results
2. Goals: Target conformance level and timeline (e.g., “WCAG 2.2 Level AA by Q4 2026”)
3. Priorities: Which issues to address first (based on impact and effort)
4. Responsibilities: Who owns accessibility across teams
5. Training plan: How staff will build accessibility competence
6. Testing plan: How accessibility will be evaluated (automated testing, manual audits, user testing)
7. Maintenance plan: How accessibility will be sustained after initial remediation
8. Metrics: How progress will be measured (see universal design metrics and KPIs)

Templates and Frameworks

• W3C WAI Planning and Managing guide: Provides a framework for organizational accessibility planning
• EN 17161: The European standard for integrating universal design into organizational processes serves as a comprehensive planning framework
• GSA Accessibility Roadmap: The U.S. General Services Administration has published accessibility planning templates for federal agencies

Design Documentation

Accessibility Annotations

Design teams document accessibility requirements within design files (Figma, Sketch, Adobe XD):

• Heading levels for each text element
• Alt text for images
• Focus order for interactive elements
• ARIA roles and labels
• Touch target sizes
• Color contrast ratios

Several Figma accessibility annotation plugins (A11y Annotation Kit, Include) provide standardized annotation components.

Accessible Component Specifications

When design systems document their components, each component spec should include:

• Keyboard interaction pattern (tab, arrow keys, enter, escape)
• ARIA roles, states, and properties
• Screen reader expected behavior
• High contrast mode behavior
• Reduced motion behavior

The W3C ARIA Authoring Practices Guide (APG) provides specification patterns for common components that serve as documentation templates.

Procurement Documentation

When purchasing technology or services, accessibility documentation ensures vendors meet requirements:

• Requirements in RFPs: Include specific WCAG conformance requirements
• VPAT requests: Ask vendors to provide current VPATs/ACRs
• Contract language: Include accessibility requirements and remediation obligations in contracts
• Testing requirements: Specify that products will be evaluated for accessibility before acceptance

The BuyAccessible toolkit (from Section508.gov) provides procurement templates for U.S. federal agencies, adaptable for other organizations.

For the standards referenced in these documents, see standards comparison. For the legal requirements driving documentation needs, see universal design legislation.

Key Takeaways

• VPATs/ACRs communicate product accessibility status using a standardized format; the ITI template is available free at itic.org.
• Accessibility statements are public commitments that should include conformance status, known limitations, and user feedback mechanisms.
• Accessibility plans/roadmaps define goals, timelines, responsibilities, and measurement — use W3C WAI and EN 17161 as planning frameworks.
• Honesty in documentation builds trust; claiming conformance that does not exist creates both legal and reputational risk.

Sources

• W3C WAI — Accessibility Statement Generator: https://www.w3.org/WAI/planning/statements/
• W3C WAI — Planning and Managing Accessibility: https://www.w3.org/WAI/planning-and-managing/
• W3C — WCAG 2.2: https://www.w3.org/TR/WCAG22/
• Section508.gov — Buy Accessible: https://www.section508.gov/buy/
• W3C WAI — ARIA Authoring Practices Guide: https://www.w3.org/WAI/ARIA/apg/