When filling in a VPAT, the key is full transparency into the accessibility of your product or service. Below is our VPAT requirements checklist that we used when creating our AI VPAT generation feature inside of Accessibility Tracker.
If you’d like to automate the process of filling in a VPAT using your accessibility audit report, all you need to do is upload that audit report in Excel spreadsheet format to Accessibility Tracker to start the AI generation process.
Note: This is written for and based on the WCAG edition of the VPAT, but virtually all of the requirements carry over to other editions.
| Requirement Category | What You Must Include |
|---|---|
| Report Header | Company name in specific format, VPAT version number, product details, and report date |
| Product Information | Name, version, description, and contact information for follow-up questions |
| Evaluation Details | Testing methods used, applicable standards, and conformance level definitions |
| Accessibility Table | Conformance level and remarks for every criterion in the selected standard |
Table of Contents
Header
Report Title Format
The heading must follow this exact structure: “[Company Name] Accessibility Conformance Report”
The company name appears first, followed by the exact phrase “Accessibility Conformance Report.”
Template Version
Include “Based on VPAT® Version 2.5Rev” in the heading section.
The registered service mark symbol (®) must appear with VPAT. This trademark belongs to ITI and requires proper attribution.
Details Section
Product Name/Version
List the product name being reported. Include the version identifier when available.
If your product has multiple versions, specify which version this ACR covers. Buyers need to know exactly which product iteration you evaluated.
Report Date
Provide at minimum the month and year of publication. For example: “May 2025”
When including a specific date, use clear formatting like “4 May 2025” or “May 4, 2025” to avoid confusion between different date conventions.
Product Description
Write a concise description of your product or service.
This section provides context for procurement agents reviewing your ACR. Include enough detail that someone unfamiliar with your product understands what it does.
Contact Information
Provide contact information for follow-up questions. An email address is sufficient.
Buyers may need clarification about specific accessibility features or conformance levels. Make it easy for them to reach you.
Notes
Add details or explanations about the product or report. This section can remain blank.
Use notes for important context like:
- Additional product version information
- Document revision history
- Links to related documentation
- Coverage limitations or scope clarifications
Evaluation Methods Used
Include a thorough description of evaluation methods used to complete the VPAT for the product.
This section demonstrates the rigor of your accessibility evaluation.
For example, you will likely include screen reader testing, keyboard testing, and other manual evaluation methodologies.
Applicable Standards/Guidelines
Clearly indicate which standards this ACR covers.
The WCAG edition includes:
- Web Content Accessibility Guidelines 2.0 or WCAG 2.0 (ISO/IEC 40500)
- Web Content Accessibility Guidelines 2.1 or WCAG 2.1
- Web Content Accessibility Guidelines 2.2 or WCAG 2.2
Present this information in a table at the top of the report or within the introductory text.
The template provides an example table with “(yes / no)” for each guideline. Leave the appropriate yes or no for each guideline to indicate coverage.
When reporting on WCAG, specify which conformance levels you’re addressing: Level A, AA, or AAA.
Each VPAT table must identify which guideline the criteria represent.
Terms
Carried over from the VPAT are definitions for terms used in the Conformance Level column.
ITI recommends these standard definitions:
- Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation
- Partially Supports: Some functionality of the product does not meet the criterion
- Does Not Support: The majority of product functionality does not meet the criterion
- Not Applicable: The criterion is not relevant to the product
- Not Evaluated: The product has not been evaluated against the criterion (WCAG Level AAA only)
WCAG Edition Note: When filling in WCAG tables, you may use “Supports” where you might otherwise use “Not Applicable.”
WCAG 2.0 Understanding Conformance states: if there is no content to which a success criterion applies, the success criterion is satisfied.
Accessibility Table Requirements
Complete Coverage
Tables must show responses to every criterion in the selected standard.
You cannot skip criteria or remove individual items from the table. Each criterion requires both a conformance level and, if marked as “Does Not Support” or “Partially Supports”, there must be an entry in the remarks and explanations column. This is at a minimum.
Also, only WCAG level AAA success criteria may be marked as not evaluated.
WCAG Conformance
When reporting on WCAG conformance levels (A, AA, or AAA), answer every criterion for that level in the particular WCAG version your report includes.
The answers are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in WCAG Conformance Requirements.
WCAG Version
When reporting only on WCAG 2.0, remove WCAG 2.1 and 2.2-specific criteria from the table. These are marked “2.1 and 2.2” or “2.2 only” within the row.
If reporting only on WCAG 2.1, remove rows marked “2.2 only.”
Remarks and Explanations
Provide detailed remarks in the Remarks and Explanations column to justify your answer in the Conformance Level column.
This column is extremely important and carries significant weight. Empty remarks render your ACR nearly worthless to buyers.
Partially Supports or Does Not Support
As mentioned above, when the conformance level is “Partially Supports” or “Does Not Support,” the remarks must identify:
- The functions or features with issues
- How they do not fully support
Vague explanations don’t satisfy this requirement. Be specific about which product areas have limitations and exactly what those limitations are.
Not Applicable
When a criterion doesn’t apply to the product or service, explain why.
Don’t simply mark “Not Applicable” without explanation. Procurement agents need to understand your reasoning.
Accessible Alternatives
If you use an accessible alternative approach, describe it in the remarks and explanations column.
Sometimes products meet intent through different means than the criterion specifies. Document these equivalent approaches.
Section Removal
You can remove sections (but not individual criteria) in specific situations:
When reporting only WCAG 2.0, remove WCAG 2.1 and 2.2-specific criteria marked in the rows.
If the product is not evaluated for a conformance level (such as Level AAA), delete that entire table.
When a requesting customer identifies that a section doesn’t apply, include information in the notes explaining the removal.
Removal Documentation
Always document why you removed a section.
Unexplained gaps in your ACR raise questions about thoroughness and accuracy.
ACR Preparation
Remove Instructions
Delete the entire first 9 pages of the template when publishing your ACR.
This includes the table of contents, introductory information, and instructions. Your ACR should begin with the report title.
Verification Checklist
Before publishing, confirm every required element appears:
- [Company Name] Accessibility Conformance Report title
- (Based on VPAT® Version 2.5Rev)
- Name of Product/Version
- Report Date
- Product Description
- Contact Information
- Notes (even if blank)
- Evaluation Methods Used
- Applicable Standards/Guidelines
- Terms definitions
- Tables for Each Standard or Guideline
- Response for each criterion’s Conformance Level and Remarks and Explanations
Also, verify that the final document itself is accessible.
An inaccessible ACR creates immediate credibility problems. The document reporting on accessibility must meet accessibility standards.
Common Checklist Errors
- Missing Remarks – The most frequent error is leaving the Remarks and Explanations column empty or providing minimal detail.
- Procurement agents scrutinize this column to understand actual product accessibility. Generic statements like “meets requirement” provide no useful information.
- Incorrect Conformance Levels – Using conformance levels that don’t match the actual product state undermines the entire ACR.
- An audit must precede VPAT completion. You cannot accurately determine conformance levels without thorough evaluation.
- Incomplete Evaluation Methods Vague descriptions like “tested the product” are insufficient.
- Specify which screen readers you used, which testing methodologies you employed, and who conducted the evaluation.
- Wrong Edition Selection Choosing the VPAT edition without considering buyer requirements creates problems.
- Most buyers specify which edition they need. Confirm requirements before starting your ACR.
Automating the Process
Meeting every requirement ensures your ACR serves its intended purpose: helping buyers assess your product’s accessibility accurately and completely.
If you’d like to automate this process to generating a filled-in VPAT using your accessibility audit report, sign up for any paid plan at AccessibilityTracker.com and you will have access to this feature.
FAQ
How detailed should the Remarks and Explanations column be?
Provide enough detail that procurement agents understand exactly what works, what doesn’t, and why. When issues exist, explain which features are affected and how users experience the limitation.
Do I need to report on all WCAG conformance levels?
No. Report on the levels your buyers require. Most organizations request Level A and AA conformance. Level AAA is rarely required.
Can I update my ACR after publication
You can create a revised ACR with a new report date. Document the revision in the Notes section. Alternatively, create an entirely new report explaining it supersedes the earlier version. Accessibility Tracker makes generating a new VPAT (after fixes) extremely easy. Just update the status of the issues in your audit report and then generate a new VPAT.
