VPAT / ACR Review Guide

What is a VPAT/ACR?

VPAT(Voluntary Product Accessibility Template)

A standardized template for documenting how a product conforms to accessibility standards. Created by ITIC.

ACR(Accessibility Conformance Report)

A completed VPAT—the actual report documenting a product's accessibility status.

VPAT Versions

Version	Standards Covered	Best For
VPAT 2.5(Current)	WCAG 2.2, Revised Section 508, EN 301 549	All new purchases
VPAT 2.4	WCAG 2.1, Revised Section 508, EN 301 549	Acceptable
VPAT 2.0–2.3	WCAG 2.0, Original Section 508	Outdated—request update

Document Structure

A complete VPAT/ACR includes these sections:

1. Product Information

• Product name and version- Should match what you're purchasing
• Report date- Should be recent (within 12-18 months)
• Contact information- For accessibility questions
• Evaluation methods- How testing was conducted

2. WCAG Conformance Tables

The main content—tables showing conformance to each WCAG success criterion:

• Level A criteria (must have)
• Level AA criteria (required for compliance)
• Level AAA criteria (optional/enhanced)

3. Section 508 Tables

For federal purchases—functional performance criteria:

• Without vision
• With limited vision
• Without color perception
• Without hearing
• With limited hearing
• Without speech
• With limited manipulation
• With limited reach and strength
• With limited language/cognitive ability

4. Remarks and Explanations

The most important section—look for:

• Specific details on partial conformance
• Known issues and workarounds
• Remediation plans and timelines
• Accessibility features

Understanding Conformance Levels

Level	Meaning	Evaluation
Supports	Functionality fully meets criterion	Ideal
Partially Supports	Some functionality meets criterion	Review remarks carefully
Does Not Support	Majority of functionality fails criterion	Significant concern
Not Applicable	Criterion not relevant to product	Verify legitimacy
Not Evaluated	Has not been tested	Request testing

Red Flags to Watch For

Critical Failures

These "Does Not Support" entries are deal-breakers:

• 1.1.1 Non-text Content- No alt text support
• 1.3.1 Info and Relationships- Broken semantic structure
• 2.1.1 Keyboard- Can't use without mouse
• 2.1.2 No Keyboard Trap- Users get stuck
• 4.1.2 Name, Role, Value- Screen readers can't read controls

Evaluation Checklist

Document Quality

Report date within last 18 months Product version matches what we're buying Uses VPAT 2.4 or 2.5 template Includes contact information Evaluation methods described

WCAG Level A (Must Have)

All Level A criteria evaluated (not just "N/A") Keyboard accessibility supported (2.1.1, 2.1.2) Non-text content addressed (1.1.1) No "Does Not Support" for critical criteria

WCAG Level AA (Required)

Color contrast requirements met (1.4.3, 1.4.11) Resize/reflow supported (1.4.4, 1.4.10) Focus visibility supported (2.4.7) Error identification supported (3.3.1, 3.3.3)

Remarks Quality

"Partially Supports" includes specific details Workarounds provided for known issues Roadmap/timeline for remediation included Remarks are detailed, not vague

Questions to Ask Vendors

About the Report

1. Who conducted the accessibility evaluation—internal team or third party?
2. What version of the product does this VPAT cover? Is it current?
3. How often is the VPAT updated?
4. Can you provide testing results or detailed audit findings?

About Issues

1. For "Partially Supports" items—what specifically doesn't work?
2. What is your remediation roadmap and timeline?
3. Are there workarounds for current accessibility issues?
4. Will you provide an updated VPAT after fixes are released?

About Commitment

1. Do you have a dedicated accessibility team?
2. Is accessibility included in your development lifecycle?
3. Do you conduct regular accessibility testing?
4. What is your process for responding to accessibility complaints?
5. Will you include accessibility requirements in our contract?

Step-by-Step VPAT Evaluation Process

Follow this systematic approach when reviewing a VPAT/ACR. Allow 30–60 minutes for a thorough evaluation.

Step 1: Verify Document Authenticity (5 minutes)

1. Check the source— Request VPATs directly from the vendor or from their official accessibility page. Third-party repositories may have outdated versions.
2. Confirm product alignment— Verify the product name and version exactly match what you intend to purchase. A VPAT for "ProductX Web App 3.0" doesn't cover "ProductX Desktop 3.0" or "ProductX Web App 4.0."
3. Check the date— Reports older than 18 months should be treated as outdated. WCAG standards and products evolve; older reports may not reflect current accessibility status.
4. Identify the evaluator— Note whether testing was conducted by the vendor's internal team, an independent third party, or a combination. Third-party evaluations from recognized firms (Deque, Level Access, WebAIM, TPGi) carry more weight.

Step 2: Review the Executive Summary (5 minutes)

1. Read the product description— Understand what functionality is covered. Some VPATs only cover core features, not add-ons, integrations, or mobile apps.
2. Note evaluation methods— Look for mentions of automated testing (axe, WAVE), manual testing, and assistive technology testing (screen readers, magnifiers). A robust VPAT describes multiple testing methods.
3. Check scope limitations— Vendors may explicitly exclude certain modules, third-party integrations, or user-generated content areas.

Step 3: Analyze WCAG Level A Criteria (10 minutes)

Level A represents the absolute minimum accessibility requirements. Failures here create fundamental barriers.

1. Count the conformance levels— Tally how many criteria are marked "Supports," "Partially Supports," "Does Not Support," and "Not Applicable."
2. Scrutinize "Does Not Support"— Any Level A failures are serious. Prioritize reviewing:
   • 1.1.1 Non-text Content— Can users with screen readers understand images?
   • 1.3.1 Info and Relationships— Is content structure programmatically determinable?
   • 2.1.1 Keyboard— Can all functionality be operated via keyboard?
   • 2.1.2 No Keyboard Trap— Can users navigate away from any component?
   • 4.1.2 Name, Role, Value— Do interactive elements expose proper accessibility information?
3. Read remarks for "Partially Supports"— Determine whether 80% works or 20% works. Vague remarks like "some issues may exist" are unacceptable.

Step 4: Analyze WCAG Level AA Criteria (10 minutes)

Level AA is required for Title II compliance and most institutional policies. Focus on criteria that affect daily use.

1. Check color contrast (1.4.3, 1.4.11)— Text and UI components must meet minimum contrast ratios. Failures affect users with low vision.
2. Verify text resizing (1.4.4, 1.4.10)— Content must work when zoomed to 200% and reflow at 320px viewport width.
3. Review focus indicators (2.4.7)— Keyboard users must see where they are on the page.
4. Examine form handling (3.3.1, 3.3.2, 3.3.3)— Errors must be identified, labels provided, and suggestions offered.
5. Check heading structure (2.4.6)— Headings and labels must describe topic or purpose.

Step 5: Evaluate Remarks Quality (10 minutes)

The remarks column reveals vendor transparency and commitment to accessibility.

Step 6: Assess Overall Risk (5 minutes)

Assign a risk rating based on your analysis:

Rating	Criteria	Recommendation
Low Risk	Mostly "Supports" at Level A and AA; detailed remarks; clear remediation plans; recent evaluation	Proceed with standard contract language
Medium Risk	Several "Partially Supports" with acceptable workarounds; some gaps in remarks; older report	Request vendor demo; add remediation milestones to contract
High Risk	Multiple "Does Not Support" at Level A; vague or missing remarks; no roadmap; critical criteria failures	Escalate to Accessibility PMO; consider alternatives; require remediation before deployment

Supplementing VPATs with Live Evaluation

A VPAT is a vendor's self-reported claim. Always verify with hands-on testing before major purchases.

Request an Accessibility Demo

Ask vendors to demonstrate their product using assistive technology:

• Keyboard-only navigation— Can all features be accessed without a mouse? Is focus visible?
• Screen reader demonstration— Request a demo using JAWS, NVDA, or VoiceOver. Listen for proper announcements of buttons, links, and form fields.
• Zoom/magnification— Does the interface remain usable at 200% zoom?
• Mobile accessibility— If applicable, demonstrate VoiceOver (iOS) or TalkBack (Android) support.

Conduct Your Own Quick Test

If you have trial access, spend 15 minutes checking:

1. Tab through the main interface— Can you reach all interactive elements? Does focus order make sense?
2. Check color contrast— Use a browser extension like axe DevTools or WAVE to identify contrast failures.
3. Test a key workflow— Complete the most common task (e.g., creating a document, submitting a form) using only keyboard.
4. Listen with a screen reader— Even 5 minutes with NVDA or VoiceOver reveals major issues.

VPAT Scoring Matrix

Use this scoring approach to compare multiple products objectively. Assign points based on conformance level and criterion importance.

Weighting by WCAG Level

Conformance Level	Level A Criteria	Level AA Criteria
Supports	3 points	2 points
Partially Supports	1 point	1 point
Does Not Support	0 points	0 points
Not Applicable	Exclude from calculation	Exclude from calculation

Critical Criteria Multiplier (2×)

Apply a 2× multiplier to these criteria due to their impact on fundamental access:

• 1.1.1 Non-text Content
• 1.3.1 Info and Relationships
• 2.1.1 Keyboard
• 2.1.2 No Keyboard Trap
• 2.4.7 Focus Visible
• 4.1.2 Name, Role, Value

Calculate Overall Score

Sum all points and divide by maximum possible points to get a percentage. Compare products using this normalized score.

Example:Product A scores 85/100 (85%), Product B scores 72/100 (72%). Product A demonstrates stronger accessibility conformance.

Authoritative Sources

This guide draws from established accessibility procurement frameworks and standards organizations.

Official Standards & Templates

• ITI VPAT® Templates— The Information Technology Industry Council (ITI) maintains the official VPAT template. Always reference the current version (2.5 as of 2024).
• W3C WCAG 2.2— The Web Content Accessibility Guidelines define the technical requirements VPATs evaluate against.
• U.S. Access Board ICT Standards— Section 508 standards that inform federal procurement requirements.
• EN 301 549— European ICT accessibility standard, increasingly used in international VPATs.

Procurement Guidance

• Section508.gov: Buy Accessible— Federal guidance on accessible IT procurement, including VPAT evaluation tips.
• Section508.gov: Requesting Accessibility Information— How to request and evaluate accessibility documentation from vendors.
• Minnesota IT Services: Accessible IT Procurement— Comprehensive state-level procurement framework with VPAT review guidance.
• University of Washington: IT Accessibility Procurement— Higher education procurement model widely referenced by institutions.

Evaluation Methodology

• WebAIM: Accessibility Certification— Explains third-party evaluation methodologies and what makes a credible accessibility report.
• Deque: How to Read a VPAT— Practical guidance from accessibility testing experts on interpreting VPAT content.
• Level Access: Understanding Your Vendor's VPAT— Industry perspective on VPAT evaluation and common issues.
• TPGi: Do You Know How to Read a VPAT?— Expert guidance on what to look for and what to question.

Higher Education Resources

• EDUCAUSE: Accessibility Resources— Higher education IT accessibility guidance including procurement.
• AHEAD (Association on Higher Education and Disability)— Professional organization resources for institutional accessibility.
• Higher Education Accessibility Network— Shared resources from accessibility professionals across institutions.

Related UA Resources

• UA VPAT Library— Pre-reviewed VPATs for common campus software
• Procurement Process— Full accessible procurement workflow
• Vendor FAQ— Common vendor questions about UA requirements
• Procurement Hub— Overview of accessibility in procurement