An Accessibility Conformance Report (ACR) records how a specific product or service supports defined accessibility requirements. The Voluntary Product Accessibility Template (VPAT®) is a template. A completed VPAT for a product is an ACR.
An ACR is a dated disclosure, not a certification, accessibility audit, accessibility statement, or guarantee that every person can use every feature. It must be based on an evaluation of a clearly defined product and supported by evidence.
A contract, tender, procurement policy, or customer may require an ACR and may specify the template edition, standard, scope, format, evaluator independence, or submission process. Follow those requirements. Ask the purchaser when they are unclear.
A project may also publish an ACR voluntarily to support transparent procurement and maintenance. Do not create one only to satisfy a checkbox. An unsupported claim creates risk and gives buyers little useful information.
Use the right document for the purpose:
These documents can link to one another, but none substitutes for the others.
Use the latest template required by the purchaser. As of April 2025, ITI's current release is VPAT 2.5Rev. Check the ITI VPAT page before starting because the template can change.
ITI provides four editions:
| Edition | Primary requirements | Current WCAG version incorporated |
|---|---|---|
| 508 | Revised Section 508 for United States federal procurement | WCAG 2.0 |
| EU | EN 301 549 | WCAG 2.1 |
| WCAG | WCAG conformance reporting | WCAG 2.2 |
| INT | Combined 508, EU, and WCAG requirements | Includes the WCAG versions incorporated by those standards |
Do not replace a contractually required edition with the edition you prefer. A product can be evaluated against WCAG 2.2 while a procurement still requires a 508 or EU report based on the standards incorporated into that edition. Record the distinction.
Identify the exact product being reported. Include:
Scope must not be manipulated to exclude difficult parts of a product while making a broad product claim. If the report covers only a limited configuration or set of workflows, say so prominently.
Use WCAG Evaluation Methodology (WCAG-EM) 2.0 to define the scope, explore the product, select representative samples, evaluate them, and report findings.
A representative sample should include:
Evaluate the entire product when that is feasible. Sampling is unnecessary for a small or indivisible product. For a larger product, first build the structured sample. The random sample must then add unique items equal to at least 10% of the structured sample.
Compare findings from the random and structured samples. If the random sample reveals new types of content, components, states, processes, or barriers, the structured sample was not representative enough. Expand it and repeat the random sampling step.
WCAG-EM sampling supports findings about the evaluated sample. It does not normally establish that every item in a large product conforms. Describe the limits of the evaluation rather than converting a sample into a universal claim.
The evaluation requires people who understand WCAG, accessible design, the technologies used, assistive technologies, and the barriers experienced by people with disabilities. A team can combine expertise when one evaluator does not cover the complete scope.
Use:
User testing can identify barriers that standards review misses, but it does not replace evaluation against every applicable requirement. Automated results are also not conformance decisions. Barriers affect people, WCAG success criteria define requirements, and tools test a limited set of rules. Only a smaller deterministic, high-confidence subset is suitable for automated gates.
An independent evaluator can improve credibility and reduce conflicts of interest. ITI does not require third-party review or certify completed VPATs. A purchaser may impose a separate independence requirement.
When a report claims to follow WCAG-EM, document the outcomes of every required step. Include:
Report at least one example for every unmet conformance requirement and success criterion. Note when the same barrier occurs repeatedly. Preserve enough evidence to reproduce important findings. Useful records include rendered DOM, screenshots or video, paths and actions, settings, test data, and tool versions. Protect credentials, personal information, and other sensitive material when evidence is stored or shared.
A WCAG-EM evaluation statement is optional. It is not a general claim that the complete product conforms. WCAG-EM permits a conformance claim only when all non-optional methodology requirements are met, all items in the evaluated sample meet the target, and the product owner commits to maintaining the statement's accuracy. Use WCAG's limited partial-conformance provisions only when their specific conditions apply. Do not use “partially conforms” as a general label for a product with known failures.
Avoid reducing the findings to a single score. WCAG does not define a conformance score, and an aggregate can hide barriers that block essential tasks. If a purchaser requires a score, document its calculation and limitations.
Use the conformance terms defined by the selected template. ITI's current terms are Supports, Partially Supports, Does Not Support, and Not Applicable. Not Evaluated is limited to Level AAA criteria.
For every applicable criterion, record enough information for another person to understand and verify the claim. Remarks should include:
Do not paste a tool rule name or result in place of a success-criterion evaluation. A tool rule may test one narrow condition related to a criterion. It does not establish the complete outcome for that criterion.
If the project target is WCAG 2.2 AA, report Level A and AA requirements as the conformance target. Level AAA criteria can be recorded as aspirational goals. Do not mix an unmet AAA aspiration into the AA result or report it as an AA failure.
Drupal is a platform that can produce many different products. An ACR for Drupal core, a distribution, a contributed project, and a deployed site have different scopes.
Define the evaluated core version, installation profile, core modules, themes, configuration, content, roles, and workflows. Include both front-end and administrative interfaces when the report claims to cover them. Separate results by component or interface where one result would otherwise conceal important differences.
The issue to add an ACR to Drupal core remains open. Do not state that Drupal core ships an official ACR until the report, ownership, review method, and maintenance process have been accepted.
A separate Phase 0 Drupal 11 issue-traceability pilot proposal is available for human review. It defines a bounded issue sample and governance gates only; it does not authorize collection, evaluation, an ACR draft, or publication.
A contributed project can publish an ACR when it has a meaningful interface or changes the accessibility of rendered output. Define the supported core and dependency versions, configuration, themes, and test fixture. A project with no independent user interface may be better served by documented accessibility requirements, test coverage, and issue tracking.
Evaluate the integrated product. Do not inherit a Supports claim merely because Drupal core or a dependency makes one. Site configuration, custom code, contributed projects, content, themes, and external services can change the result.
Apply WCAG to the user interface covered by the ACR. Drupal also functions as an authoring tool. ATAG 2.0 adds requirements for making the authoring interface accessible and supporting the production of accessible content. A standard VPAT WCAG table does not replace a separate ATAG evaluation.
Drupal.org issue queues contain reported barriers. They are not a complete inventory of all barriers, and tags may be missing or incorrect. The absence of an open issue is not evidence that a criterion is supported.
For issues used in an ACR:
Issue counts are not a conformance score. One underlying pattern can create many instances, while one unreported barrier can block an essential task.
OpenACR is an open, machine-readable ACR format maintained by the United States General Services Administration. Its YAML source can be version controlled and rendered as accessible HTML. The current catalog includes VPAT 2.5 WCAG reporting against WCAG 2.2.
The OpenACR Editor can help create an OpenACR in the browser. Confirm that the tool and catalog support the exact edition required by the purchaser. OpenACR does not remove the need for evaluation, evidence, expert review, or an accessible final document.
WCAG-EM 2.0 recommends the Evaluation and Report Language (EARL) for optional machine-readable evaluation results. EARL and OpenACR serve different purposes. EARL can record detailed test assertions and evidence. OpenACR structures the procurement-facing conformance report. They can be used together, but an OpenACR does not satisfy WCAG-EM's machine-readable reporting recommendation unless the project provides an explicit mapping.
Store source and generated output in version control when the project can maintain them. Keep the human-readable report and machine-readable source synchronized. Do not modify ITI's protected VPAT form or service marks outside its usage terms.
Before publication:
An ACR is a snapshot. Review it after significant interface changes, dependency changes, newly verified barriers, remediation that changes a claim, a change in the required standard, or before a procurement submission. Also set a periodic review cadence appropriate to the project's release cycle. Do not change the product version or report date without rechecking the claims.