Accessibility Conformance Reports are one of the most useful documents in accessible procurement, yet they are also one of the most misunderstood. If you buy, deploy, design, or evaluate digital products, learning how to read a VPAT helps you separate genuine accessibility progress from marketing language. In practice, that skill affects software selection, risk management, implementation planning, and the experience disabled users have once a product reaches the workplace, classroom, or public service environment.
A VPAT, or Voluntary Product Accessibility Template, is the standardized format vendors use to describe how a product supports accessibility requirements. When completed, it becomes an Accessibility Conformance Report, often shortened to ACR. The template itself is published by the Information Technology Industry Council, while the completed report is the vendor’s statement about how a specific product or service performs against named standards. Those standards may include WCAG 2.0, WCAG 2.1, Revised Section 508, and European EN 301 549 requirements, depending on the edition used.
This matters because accessible technology implementation rarely begins with code. It begins with decisions: which platform to buy, which collaboration tool to renew, which learning system to integrate, which mobile app to approve, and which gaps your organization can realistically remediate. I have used ACRs during software evaluations, contract reviews, and remediation planning, and the difference between a careful reading and a quick skim is substantial. A polished report can hide major barriers if the remarks are vague, outdated, or disconnected from real user workflows. A candid, detailed report can reveal manageable issues and make a product a safer choice.
As a hub within Technology and Accessibility, this guide connects procurement, testing, governance, design, and continuous improvement. Implementing and advancing accessible technology means more than collecting compliance paperwork. It requires understanding what a report can tell you, what it cannot prove, how to compare multiple vendors fairly, and when to validate claims through manual testing, assistive technology checks, and internal policy review. Read well, a VPAT becomes a decision tool. Read poorly, it becomes a false signal of accessibility maturity.
What a VPAT is, what an ACR is, and why the distinction matters
The first point to understand is terminology. A VPAT is the template. An ACR is the completed document. Many people say “send us your VPAT” when they really mean “send us your completed Accessibility Conformance Report.” That casual shorthand is common, but the distinction matters because a template has no value until it is filled out for a specific product, version, and date. If those details are missing, the report has limited procurement value.
A strong ACR identifies the product name, version number, report date, evaluation methods, applicable standards, and contact information. It should also describe whether the scope covers web, desktop, mobile, electronic documents, support documentation, or customer service channels. This is essential because accessibility performance often differs across platforms. A product may have a usable web interface but an inaccessible native mobile app, or accessible core workflows but inaccessible admin screens. If the scope is broad and the remarks are thin, treat the report cautiously.
In most enterprise settings, ACRs are used during due diligence. Procurement teams use them to screen vendors. Accessibility specialists use them to estimate risk. Security and legal teams may include them in contract files. Implementation teams use them to anticipate accommodations, configuration changes, or custom development needs. Institutions in higher education and government often rely on them because they need a standardized, documented basis for comparing products before adoption.
How to read the conformance levels without being misled
Most ACRs organize requirements in rows with a conformance level such as Supports, Partially Supports, Does Not Support, Not Applicable, or Not Evaluated. These labels are useful, but they are never enough on their own. The decisive content sits in the remarks and explanations column. That is where a vendor should describe how the product meets the criterion, where limitations exist, and under what conditions the result applies.
When I review ACRs, I ask a simple question for every row: could an accessibility tester reproduce this claim? If the remark says “supports with minor exceptions,” that is weak. If it says “all form fields expose programmatic labels to screen readers, but the date picker in report scheduling lacks keyboard access in version 4.2,” that is actionable. Specificity signals maturity. Vague reassurance usually signals either shallow testing or reluctance to document defects clearly.
It also helps to remember that “Partially Supports” covers a wide range of risk. A minor issue in a settings page and a blocking issue in account creation can both be labeled partial support. That is why the operational impact matters more than the label itself. Ask whether the issue affects a critical path, whether a workaround exists, whether the workaround requires assistance, and whether remediation is scheduled. Accessibility is about task completion, not just row counts.
| Conformance label | What it usually means | What you should verify |
|---|---|---|
| Supports | The vendor states the requirement is met for the scoped product version. | Check for testing detail, platform scope, and whether any exceptions are buried elsewhere. |
| Partially Supports | Some aspects meet the requirement, but exceptions exist. | Determine whether the exception affects critical workflows, assistive technology users, or only edge cases. |
| Does Not Support | The product fails the requirement in scope. | Assess whether the failure is blocking, whether remediation is planned, and whether alternatives exist. |
| Not Applicable | The requirement does not apply to the product features in scope. | Confirm the feature truly is absent and not simply unevaluated. |
| Not Evaluated | No claim is made for that requirement. | Treat as unknown risk and request clarification before procurement. |
What evidence makes an Accessibility Conformance Report trustworthy
A credible ACR is transparent about methodology. Look for references to manual testing, automated scanning, keyboard-only testing, screen reader testing, zoom and reflow checks, color contrast analysis, and document review where relevant. Named tools can add confidence, including axe DevTools, WAVE, Accessibility Insights, JAWS, NVDA, VoiceOver, TalkBack, and browser developer tools. Good reports also explain that automated testing alone cannot verify all success criteria, which is accurate and important.
Dates matter just as much as methods. A report from two years ago may not reflect the current interface, especially for SaaS platforms shipping frequent releases. I have seen vendors provide an ACR for a legacy interface while selling a redesigned product that changed navigation, modal behavior, and component libraries. Always confirm the report date and the exact version or release train covered. If a product updates continuously, ask how accessibility regressions are monitored between report updates.
Remarks should cite real behavior. Strong examples include statements about heading hierarchy, focus order, error identification, captions, status messages, and semantic roles. Weak examples repeat the criterion in different words without evidence. Another trust signal is honesty. A vendor that documents known failures, planned remediation windows, and support channels is often more reliable than one claiming universal support across complex workflows. Accessibility work is iterative; perfect claims in a complicated product are uncommon and should invite scrutiny.
Using a VPAT in procurement, implementation, and governance
Reading a VPAT well supports the full lifecycle of accessible technology, not just vendor selection. In procurement, use the report to narrow the field, identify nonnegotiable barriers, and generate follow-up questions. During implementation, use it to plan configuration choices, training, alternate workflows, and testing priorities. In governance, use it to document risk acceptance, contract commitments, and timelines for remediation. ACRs become most powerful when they are paired with policy and process rather than filed away as static attachments.
For example, a university evaluating a learning platform may accept a product with partial support if the vendor documents accessible assignment submission, grading, and discussion tools, while also acknowledging known issues in lesser-used analytics dashboards. That decision could still be responsible if the contract includes remediation milestones, if instructors receive guidance on avoiding inaccessible features, and if disability services has a documented accommodation path. The ACR informs implementation choices; it does not make the choice automatically.
This hub topic, Implementing and Advancing Accessible Technology, depends on that broader view. Procurement should link to accessibility testing practices, design system standards, content governance, and incident response. If your organization publishes internal accessibility requirements, create links from this page to guides on WCAG basics, screen reader testing, accessible documents, captioning, procurement questionnaires, and continuous monitoring. Those connected resources turn a single ACR review into a repeatable accessibility program.
Common red flags and the questions to ask vendors
Several warning signs appear repeatedly. One is missing scope: no product version, no platform distinction, and no date. Another is boilerplate language copied across every criterion. A third is overuse of “supports” paired with generic remarks such as “tested for compliance.” I also watch for reports that ignore documentation, support services, or PDFs, because accessibility failures often live outside the core application interface. Finally, be careful when a vendor offers only a roadmap and no current-state report. Future intent is not current accessibility.
Good follow-up questions are direct. Which assistive technologies were used, and on which operating systems and browsers? Were tests performed by internal staff, consultants, or disabled users? Which workflows were included: login, purchasing, reporting, content creation, administration? Are there known keyboard traps, unlabeled controls, drag-and-drop barriers, time limits, or inaccessible CAPTCHAs? Is there an accessibility statement, issue intake process, and documented SLA for fixes? Can the vendor share defect IDs or release notes tied to accessibility remediation?
If the product is mission critical, validate the ACR with hands-on testing. Even a short test of top tasks can reveal whether claims match reality. Try account creation, search, form submission, file upload, error recovery, media playback, and mobile orientation changes. Use keyboard navigation first. Then test with a screen reader. If your environment depends on Single Sign-On, embedded content, or third-party plugins, include those paths. Many accessibility gaps emerge at integration points rather than in the base product.
How VPAT review fits into an accessible technology maturity model
Organizations that handle accessible technology well treat ACR review as one control in a larger system. The most effective programs define accessibility requirements in procurement language, require current ACRs from vendors, score reports with a standard rubric, perform risk-based validation, and track remediation after purchase. They also train buyers and project managers so accessibility is discussed before contracts are signed. This prevents the common pattern of discovering barriers only after rollout, when fixes are slower and more expensive.
Advancing accessible technology also means recognizing the limits of conformance documents. ACRs do not measure usability for every disability, do not guarantee compatibility with every assistive technology combination, and do not replace user research. A technically conforming workflow can still be confusing, exhausting, or inefficient. That is why mature teams combine standards-based review with practical testing and feedback from disabled users. The goal is dependable access, not paperwork completion.
To get more value from every VPAT, build a simple review checklist, compare reports side by side, and document decisions clearly. Focus on scope, version, methodology, critical task support, known exceptions, and remediation commitments. Use the report to ask better questions, not to avoid asking them. That approach strengthens procurement, improves implementation, and moves your accessibility program from reactive exception handling to informed, sustainable progress. Start by reviewing one current ACR in your stack and identifying the claims that need verification next.
Frequently Asked Questions
What is a VPAT, and how is it different from an Accessibility Conformance Report?
A VPAT, or Voluntary Product Accessibility Template, is the standardized template vendors use to document how a product supports accessibility requirements. Once that template is completed for a specific product, it becomes an Accessibility Conformance Report, often shortened to ACR. In other words, the VPAT is the form, and the ACR is the finished report. People often use the terms interchangeably, but the distinction matters because what buyers and evaluators actually review during procurement is the completed report, not the blank template.
This difference is important because a polished-looking document can create a false sense of confidence if readers do not understand what they are reviewing. A vendor may say it “has a VPAT,” but that statement alone does not tell you whether the document is current, complete, based on real testing, or relevant to the version of the product you plan to use. A useful ACR should identify the product version, the evaluation methods used, the standards covered, and detailed remarks explaining where the product supports, partially supports, or does not support specific criteria.
For procurement teams, accessibility professionals, and implementation leaders, the ACR is not simply a compliance artifact. It is a decision-making tool. It can help you estimate remediation effort, identify deployment risks, anticipate accommodation needs, and compare products more intelligently. The key is to treat the report as evidence to analyze, not as a certificate that automatically proves accessibility.
What sections of a VPAT should I review first when I am trying to evaluate a product quickly?
If you need to assess a report efficiently, start with the sections that reveal whether the document is credible and relevant. First, review the report date and product version. An old ACR or one that does not clearly identify the evaluated version may not reflect the product you are actually purchasing or renewing. Accessibility can improve or regress over time, so timing matters. Next, look at which edition of the VPAT was used and which standards are included, such as WCAG, Section 508, or EN 301 549. That tells you what framework the vendor is mapping against and whether the report aligns with your legal or organizational requirements.
After that, go directly to the conformance tables and focus on the “Remarks and Explanations” column. This is where the most meaningful information should appear. A label such as “Supports” or “Partially Supports” is only the beginning. The remarks should explain how the product was evaluated, what limitations exist, whether exceptions are narrow or widespread, and which user journeys may be affected. If the remarks are vague, repetitive, or written like marketing copy, that is a sign the document may not be reliable enough to support an important purchasing decision.
Also review the sections describing evaluation methods and known limitations. Strong reports often mention manual testing, assistive technology testing, keyboard testing, and the environments used for evaluation. Weak reports tend to provide little transparency. If you are triaging several vendors, these early checks help you quickly separate reports that deserve deeper review from ones that require follow-up questions before you can place much trust in them.
What do terms like “Supports,” “Partially Supports,” and “Does Not Support” actually mean in a VPAT?
These labels are summaries, not verdicts. “Supports” generally means the vendor believes the product meets the applicable criterion without known accessibility barriers that would prevent conformance. “Partially Supports” usually means some aspects of the criterion are met, but there are exceptions, gaps, or edge cases that affect certain content, workflows, or user groups. “Does Not Support” indicates the product fails to meet the criterion in a meaningful way. There may also be entries such as “Not Applicable,” which means the criterion does not apply to that product feature, and “Not Evaluated,” which should prompt immediate follow-up because it signals missing information rather than demonstrated support.
The most common mistake is reading these labels too literally without examining the explanation behind them. For example, “Partially Supports” can describe anything from a minor issue with one settings page to major barriers across core workflows. Likewise, “Supports” may still require scrutiny if the remarks are thin or overly general. A well-written ACR will clarify scope, identify affected components, and explain the severity or frequency of issues. Without that context, the status label has limited value.
In practical terms, your job is to interpret impact, not just count statuses. Ask whether any listed exceptions affect essential tasks such as logging in, completing forms, uploading documents, participating in meetings, viewing media, or using the product with a screen reader or keyboard. A report can contain many “Supports” entries and still present serious usability problems if the remaining exceptions sit inside critical workflows. Reading a VPAT well means translating conformance language into real-world user risk.
How can I tell whether a VPAT is trustworthy or just a marketing document?
A trustworthy ACR is specific, transparent, and technically grounded. It identifies the product and version clearly, states when the assessment was performed, and explains what testing methods were used. It typically references manual review, automated checks where appropriate, keyboard-only testing, and testing with assistive technologies such as screen readers or magnifiers. It may also identify supported browsers, operating systems, mobile platforms, or document formats. These details matter because accessibility can vary significantly across environments.
The remarks themselves are often the clearest indicator of quality. Reliable reports describe actual behavior. They mention where headings are structured properly, where form fields are labeled, where color contrast exceptions exist, or where modal dialogs create focus management issues. They do not rely on generic phrases copied across dozens of criteria. If every row says the product “supports accessibility” without explaining how, the report is not giving you enough evidence to make a serious procurement or risk decision.
You should also watch for signs of overstatement. Be cautious if a complex product claims universal support with almost no exceptions, especially if you know from demonstrations or user feedback that the interface is complicated. Accessibility in real products is nuanced. Even mature teams usually disclose at least some known limitations, roadmap items, or dependencies on authoring practices, customer configuration, or third-party content. A credible report does not pretend perfection; it shows that the vendor understands accessibility deeply enough to document strengths and limitations honestly.
Finally, trust increases when the ACR aligns with other signals. If the vendor has an accessibility statement, publishes remediation updates, responds knowledgeably to follow-up questions, and can discuss testing processes in detail, the report becomes more believable. If the ACR is strong on paper but the vendor cannot answer basic questions about accessibility ownership, issue tracking, or timelines for fixes, treat the document cautiously.
How should I use a VPAT during procurement, implementation, and ongoing risk management?
A VPAT is most valuable when used as a working document throughout the product lifecycle rather than a one-time checkbox during purchasing. In procurement, it helps you compare vendors, identify products that pose legal or operational risk, and decide where to ask tougher questions. Instead of simply requesting a VPAT and filing it away, use it to guide conversations: Which issues affect core workflows? Which problems are already scheduled for remediation? Are there equally functional alternatives with fewer barriers? This turns accessibility from a passive documentation exercise into an active part of product selection.
During implementation, the ACR can help teams plan around known limitations. If the report identifies issues with keyboard access, PDF exports, captions, authentication, or complex interactive components, those details should inform rollout decisions, user support planning, accommodation readiness, training, and configuration choices. Some accessibility barriers can be mitigated operationally in the short term, while others require vendor fixes before broad deployment. Reading the VPAT carefully helps organizations distinguish between manageable limitations and blockers that could significantly harm disabled users’ ability to work, learn, or access services.
For ongoing risk management, the VPAT should be paired with independent validation, especially for high-impact products. A vendor’s report is useful, but it is still self-reported unless an external evaluator is involved. Organizations should verify critical workflows, document any gaps they discover, and revisit accessibility when major product updates occur. Accessibility is not static, and neither is product risk. A strong procurement process uses the ACR as one source of evidence, then combines it with testing, contractual commitments, roadmap reviews, and user feedback to build a more accurate picture of accessibility over time.
That broader approach is what makes VPAT literacy so important. When you know how to read an ACR well, you can separate meaningful accessibility progress from reassuring language, make better purchasing decisions, and reduce the chance that inaccessible technology creates avoidable barriers once it reaches employees, students, or the public.
