Section 508 Documentation: VPAT and ACR Complete Guide

Section 508federal accessibilitygovernment compliance508 complianceBrowseCheck
·12 min read

Section 508 compliance requires more than building accessible technology—it demands comprehensive documentation proving accessibility conformance. The Accessibility Conformance Report (ACR), commonly created using the Voluntary Product Accessibility Template (VPAT), is the standard format for documenting Section 508 compliance. For federal contractors and vendors, a complete, accurate VPAT is often required before contracts are awarded. This guide explains what VPATs are, how to create them, and what documentation Section 508 requires beyond the VPAT.

What is a VPAT?

The Voluntary Product Accessibility Template (VPAT) is a standardized format for documenting how information and communication technology (ICT) products conform to accessibility standards, including Section 508 and WCAG 2.0.

Created by: Information Technology Industry Council (ITI) Current version: VPAT 2.5 (as of 2024) Format: Structured template with tables documenting conformance Purpose: Provide consistent, comparable accessibility information

Despite "Voluntary" in the name, VPATs are effectively mandatory for federal procurement—agencies require them to evaluate accessibility before purchasing.

VPAT vs ACR: Understanding the Terminology

VPAT (Voluntary Product Accessibility Template): The blank template format ACR (Accessibility Conformance Report): The completed document using the VPAT format

In practice: People often use "VPAT" to refer to both the template and the completed report. Technically, you "create an ACR using the VPAT template."

VPAT Template Editions

VPAT 2.5 includes multiple editions for different standards:

VPAT 2.5 Revised Section 508 Edition

Documents conformance to:

  • Revised Section 508 Standards (incorporating WCAG 2.0 Level A and AA)
  • EN 301 549 (European standard)
  • WCAG 2.0 and 2.1

Most comprehensive edition, recommended for federal use.

VPAT 2.5 WCAG Edition

Documents conformance to:

  • WCAG 2.0 (Level A and AA)
  • WCAG 2.1 (Level A, AA, and optionally AAA)
  • WCAG 2.2 (Level A, AA, and optionally AAA)

Use when only WCAG conformance needed (non-U.S. or non-federal).

International Edition

Documents conformance to:

  • EN 301 549 (European Accessibility Standard)
  • Includes WCAG 2.1 requirements

Use for European market or global products.

INT Edition (Integrated)

Single template covering all standards:

  • Section 508
  • WCAG 2.0/2.1/2.2
  • EN 301 549

Most flexible, used when selling across multiple jurisdictions.

VPAT Structure and Sections

Product Information

Essential product details:

Product Name: Official product name and version

  • Example: "BrowseCheck Accessibility Monitor v3.2"

Product Description: What the product does and who uses it

  • Example: "Cloud-based continuous accessibility monitoring platform for websites and web applications"

Version: Specific version being evaluated

  • Example: "Version 3.2.1, released March 2024"

Report Date: When ACR was created

  • Example: "May 15, 2024"

Contact Information: Who to contact about accessibility

  • Email, phone, website
  • Accessibility team contact details

Notes: Any important context about the evaluation

  • Evaluation methodology
  • Tools used
  • Scope limitations

Evaluation Methods Used: How conformance was determined

  • "Automated testing with axe DevTools and BrowseCheck"
  • "Manual testing with keyboard and NVDA screen reader"
  • "Expert review by IAAP-certified accessibility specialists"

Applicable Standards/Guidelines

Check which standards apply to your product:

☑ Web (WCAG 2.0 Level A and AA) ☑ Revised Section 508 Standards ☐ EN 301 549 ☑ WCAG 2.1 (if choosing to exceed Section 508 minimum)

Most products check multiple boxes—web applications typically conform to both Section 508 and WCAG.

Terms and Definitions

VPAT defines four conformance levels:

Supports: Functionality fully conforms to the criterion without exceptions

Partially Supports: Some functionality doesn't conform, but most does

  • Example: "Most forms accessible, but payment form missing error descriptions"

Does Not Support: Functionality doesn't conform to the criterion

  • Example: "Video content lacks captions"

Not Applicable: Criterion doesn't apply to the product

  • Example: "No audio content exists" (audio-related criteria N/A)

Choose carefully: Be honest but accurate. "Partially Supports" with clear explanation is better than claiming "Supports" when gaps exist.

Completing the Criteria Tables

The bulk of the VPAT consists of tables listing each success criterion with your conformance determination.

Table 1: Success Criteria, Level A (WCAG 2.0)

Lists all 25 WCAG 2.0 Level A criteria.

For each criterion:

Criterion number and name: Pre-filled in template

  • Example: "1.1.1 Non-text Content"

Conformance Level: Your determination

  • Supports / Partially Supports / Does Not Support / Not Applicable

Remarks and Explanations: Details supporting your determination

  • What works
  • What doesn't work
  • Planned fixes and timelines
  • Workarounds if applicable

Example entry:

| Criteria | Conformance Level | Remarks and Explanations | |----------|-------------------|--------------------------| | 1.1.1 Non-text Content | Partially Supports | All interface images include alt text. However, user-uploaded images may lack alt text if users don't provide it. Platform prompts for alt text during upload and provides guidance. |

Table 2: Success Criteria, Level AA (WCAG 2.0)

Lists all 13 WCAG 2.0 Level AA criteria beyond Level A.

Same format as Table 1, but these are specifically Level AA requirements.

Critical for Section 508: All Level AA criteria must be evaluated.

Table 3: Success Criteria, Level AAA (Optional)

Lists all 23 WCAG 2.0 Level AAA criteria.

Not required for Section 508, but some organizations choose to document Level AAA conformance to demonstrate commitment beyond requirements.

Section 508 Specific Tables

Chapter 3: Functional Performance Criteria (FPC)

Documents conformance to functional performance criteria:

  • 302.1 Without Vision
  • 302.2 With Limited Vision
  • 302.3 Without Perception of Color
  • 302.4 Without Hearing
  • 302.5 With Limited Hearing
  • 302.6 Without Speech
  • 302.7 With Limited Manipulation
  • 302.8 With Limited Reach and Strength
  • 302.9 With Limited Language, Cognitive, and Learning Abilities

Chapter 4: Hardware (if applicable)

For physical devices, kiosks, or hardware components.

Chapter 5: Software

Critical for desktop applications, mobile apps, and web applications:

  • 502.2 Interoperability with Assistive Technology
  • 502.3 Accessibility Services
  • 502.4 Platform Accessibility Features

Chapter 6: Support Documentation and Services

Documents accessibility of:

  • User documentation
  • Help systems
  • Technical support channels

Writing Effective Remarks and Explanations

The "Remarks and Explanations" column is crucial. Generic statements like "Fully supported" or "Not applicable" aren't sufficient.

Best Practices for Remarks

Be specific: ❌ Bad: "Supports" ✅ Good: "All form inputs include associated labels using the

Acknowledge limitations honestly: ✅ "Interface supports keyboard navigation for all core functionality. Third-party embedded chat widget (from vendor XYZ) has keyboard navigation issues that we've reported to the vendor"

Explain "Not Applicable": ✅ "Not Applicable: Product is a dashboard application with no video content"

Provide timelines for planned fixes: ✅ "Partially Supports: Currently lacks audio descriptions for video tutorials. Audio descriptions will be added by Q3 2024"

Include workarounds: ✅ "Does Not Support: PDF export doesn't include proper tags. Workaround: Use HTML export option which is fully accessible, or request accessible PDF via [email protected]"

Common Mistakes in Remarks

Too vague: "Mostly compliant" (What does "mostly" mean?)

Overly optimistic: Claiming "Supports" when significant gaps exist

No explanation: Just marking conformance level without details

Defensive tone: Excessive justification rather than factual description

Missing context: Not explaining why something doesn't apply

VPAT Creation Process

Step 1: Inventory Product Capabilities

Identify all product features and content:

  • Web interface components
  • Documents (PDFs, help files)
  • Videos and multimedia
  • Software functionality
  • Hardware (if applicable)

Step 2: Determine Applicable Standards

Which standards apply to your product?

  • Web application → Section 508/WCAG 2.0 web standards
  • Desktop software → Section 508 software requirements (502)
  • Mobile app → Section 508 software + mobile-specific considerations
  • Hardware → Section 508 hardware requirements (407-415)

Step 3: Conduct Thorough Testing

Test against all applicable criteria:

  • Automated scanning (axe, WAVE, BrowseCheck)
  • Manual keyboard and visual testing
  • Screen reader testing (NVDA, JAWS, VoiceOver)
  • Platform accessibility API testing (for software)

Document findings meticulously for each criterion.

Step 4: Complete VPAT Template

Download official template from ITI website (https://www.itic.org/policy/accessibility/vpat)

Fill out methodically:

  • Product information section
  • Each criterion table
  • Honest conformance levels
  • Detailed remarks

Review for accuracy and completeness

Step 5: Internal Review

Have multiple stakeholders review:

  • Development team (technical accuracy)
  • Product management (product description accuracy)
  • Legal/compliance (risk assessment)
  • Accessibility specialist (conformance determinations)

Step 6: Finalize and Publish

Create PDF version for distribution

Post publicly (best practice):

  • On product website
  • In support documentation
  • Accessible to procurement teams

Update regularly:

  • When product changes significantly
  • When accessibility improvements made
  • At least annually

Beyond the VPAT: Other Section 508 Documentation

Accessibility Documentation in Product Help

Section 602.2 requires documenting:

Accessibility features list:

  • "BrowseCheck supports screen readers NVDA, JAWS, and VoiceOver"
  • "Keyboard shortcuts available for all functions"
  • "High contrast mode available in Settings > Display"

How to activate accessibility features:

  • "To enable high contrast: Settings > Display > High Contrast Mode"
  • "To navigate via keyboard: Use Tab to move between elements, Enter/Space to activate"

How to create accessible content:

  • "When uploading images, provide descriptive alt text in the Alt Text field"
  • "Use the built-in heading styles rather than bold text for structure"

Known compatibility information:

  • "Compatible with JAWS 2022 and later"
  • "Known issue with ChromeVox on Chrome OS (workaround: use Firefox with NVDA)"

Support Services Accessibility

Section 603 requires accessible technical support:

Multiple communication channels:

  • Phone support
  • Email support
  • Chat support
  • TTY or relay service support for deaf/hard of hearing users

Accessible support documentation:

  • Help articles meeting WCAG 2.0 Level A minimum
  • Video tutorials with captions
  • Text alternatives to video-only support content

Accessibility specialist availability:

  • "For accessibility-specific support, email [email protected]"
  • "Response within 2 business days"

Alternative Format Availability

Section 602.4: On request, provide non-electronic documentation in:

  • Braille
  • Large print
  • Audio recording
  • Electronic text format compatible with screen readers

Document this availability: "To request documentation in alternative formats (Braille, large print, audio), contact [email protected] or call 1-800-XXX-XXXX"

Maintaining Your VPAT

When to Update

Mandatory updates:

  • New product version with significant changes
  • Major accessibility fixes or improvements
  • Remediation of previously documented gaps

Recommended updates:

  • Annually, even without major changes
  • When WCAG standards update (2.0 → 2.1 → 2.2)
  • When Section 508 references new standards

Version Control

Track VPAT versions clearly:

  • VPAT for Product v1.0 (dated June 2023)
  • VPAT for Product v2.0 (dated January 2024)
  • Keep historical VPATs available for customers using older versions

Continuous Monitoring Integration

Use automated monitoring (like BrowseCheck) to:

  • Track compliance status continuously
  • Identify new issues immediately
  • Validate improvements made
  • Provide evidence for VPAT updates

Regular automated scans catch regressions quickly, ensuring your VPAT remains accurate.

Common VPAT Mistakes

Mistake 1: Claiming "Supports" Too Broadly

Problem: Marking everything "Supports" without thorough testing

Impact: False claims create legal liability and damage trust

Solution: Test comprehensively, acknowledge gaps honestly

Mistake 2: Generic or Missing Remarks

Problem: "Supports" without explanation or "N/A" without context

Impact: Procurement teams can't evaluate actual conformance

Solution: Provide specific, detailed explanations for each criterion

Mistake 3: Outdated VPATs

Problem: VPAT from 2020 for product updated significantly since

Impact: Inaccurate representation, compliance risk

Solution: Update VPAT with major releases and at least annually

Mistake 4: Ignoring Software/Hardware Requirements

Problem: Only evaluating web interface, missing software accessibility APIs

Impact: Incomplete assessment for non-web products

Solution: Evaluate all applicable Section 508 sections, not just web

Mistake 5: No Update Plan for Known Issues

Problem: Documenting gaps without remediation plans

Impact: Appears as lack of commitment to accessibility

Solution: Include timelines and plans for addressing identified issues

VPAT Tools and Resources

Official Template

Download: https://www.itic.org/policy/accessibility/vpat

Current version: VPAT 2.5 (check for updates)

Formats: Word document (editable), Excel (for batch products)

VPAT Creation Tools

Manual: Complete template in Word/Excel

  • Most control and customization
  • Requires deep accessibility knowledge

Semi-automated: Tools that pre-populate based on testing

  • Faster, may miss nuances
  • Still requires manual review

Professional services: Hire accessibility consultants

  • Most accurate, comprehensive
  • Higher cost

Accessibility Testing Integration

BrowseCheck and similar tools help by:

  • Identifying conformance gaps to document
  • Providing evidence for "Supports" claims
  • Tracking remediation progress
  • Alerting when new issues arise (affecting VPAT accuracy)

Conclusion

The VPAT (Accessibility Conformance Report) is essential documentation for Section 508 compliance, especially for federal procurement. A complete, accurate VPAT demonstrates your product's accessibility conformance and helps procurement teams make informed decisions.

Key VPAT components:

  • Product information and evaluation methodology
  • Conformance determinations for all applicable criteria
  • Detailed, specific remarks explaining conformance levels
  • Honest acknowledgment of gaps with remediation plans
  • Regular updates as product evolves

Beyond the VPAT, Section 508 requires accessible product documentation, accessible support services, and availability of alternative formats on request.

Creating a high-quality VPAT requires:

  • Comprehensive testing (automated, manual, assistive technology)
  • Deep understanding of Section 508 and WCAG criteria
  • Honest, detailed explanations of conformance
  • Regular updates and version control
  • Integration with continuous monitoring for accuracy

Ready to create your VPAT? Start with thorough accessibility testing using automated tools (like BrowseCheck for continuous monitoring), manual evaluation, and screen reader testing. Document findings methodically, be honest about gaps, and provide clear timelines for planned improvements. An accurate VPAT builds trust, demonstrates commitment to accessibility, and positions your product competitively for federal procurement.

← Back to blog