Common mistakes with VPATs and ACRs

Many VPATs fail not because the product is inaccessible, but because the documentation is incomplete, inconsistent, or written in a way that undermines credibility. These are the most common mistakes suppliers make and the practical steps to avoid them.

Inconsistent or unsupported conformance claims

Suppliers often mark criteria as "Supports" or "Supports with Exceptions" without evidence. This is the fastest way to lose buyer trust.

Avoid this by:

• Backing every claim with a short, factual explanation
• Ensuring manual and assistive-technology testing results match the claim
• Using consistent language across all criteria

Undisclosed high-risk issues

Some suppliers omit or downplay critical issues that would be deal-breakers for buyers. This can lead to lost sales and damage to reputation.

Avoid this by:

• Disclosing all critical and high-risk issues, even if they are being remediated
• Providing clear timelines for addressing medium-risk issues
• Being transparent about any known limitations or workarounds

Copy-and-paste VPATs from older versions

Reusing an old VPAT without updating it for the current product version can lead to outdated criteria, missing requirements and mismatched product versions.

Avoid this by:

• Starting with a fresh, current template for each product version
• Ensuring the VPAT version and product version are clearly stated
• Updating all criteria to reflect the current product state and standards
• Retesting the product against the correct Standard to ensure all claims are accurate

Overstating conformance ("Supports" everywhere)

Buyers immediately distrust VPATs that claim full conformance with no exceptions. Real products always have minor issues.

Avoid this by:

• Being honest about limitations
• Using "Supports with Exceptions" for criteria that are mostly met but have some issues
• Providing clear explanations for any exceptions, including the nature of the issue and any planned remediation
• Providing a remediation plan for any gaps

Missing or vague explanations

Statements like "Supports with Exceptions – some issues exist" provide no value.

Avoid this by:

• Describing what works, what doesn't, and where
• Including examples such as "Form error messages are not announced by screen readers"

No evidence of testing

Many VPATs are written without any actual testing, leading to inaccurate claims.

Avoid this by:

• Conducting thorough testing with assistive technologies, manual and automated checks
• Documenting the tools, methods and environments used
• Keeping screenshots or notes as internal evidence
• Testing your tool with people with disabilities

Ignoring third-party components

Suppliers often fail to disclose accessibility issues in embedded libraries, plugins, or integrations.

Avoid this by:

• Listing all third-party components
• Including their accessibility statements if available
• Disclosing any known issues with these components and mitigation options

Not defining scope clearly

Buyers need to know what was tested — modules, platforms, browsers, and configurations.

Avoid this by:

• Stating exactly what is in scope and out of scope
• Including platform variations (web, mobile, desktop)
• Clarifying any features not tested

No ongoing accessibility commitment

A VPAT without a plan for fixing issues signals low maturity.

Avoid this by:

• Providing timelines for medium/high-severity issues
• Identifying owners for remediation
• Updating the roadmap as fixes are released

Using marketing language instead of factual statements

Phrases like "best-in-class accessibility" or "fully compliant" undermine credibility.

Avoid this by:

• Sticking to objective, factual language
• Avoiding adjectives and promotional claims
• Focusing on what was tested and what was observed

Not updating the VPAT regularly

Accessibility is an ongoing effort. A VPAT older than 12 months is often rejected.

Avoid this by:

• Reviewing and updating the VPAT at least annually or after major releases
• Versioning the document and dating it clearly
• Keeping testing notes so updates are efficient