> For the complete documentation index, see [llms.txt](https://docs.devally.com/EfyQpV4281edZ3h0g8tY/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devally.com/EfyQpV4281edZ3h0g8tY/core-concepts/accessibility-conformance-reports.md).

# Accessibility Conformance Reports

Accessibility Conformance Reports (ACRs) are standardized documents that communicate the accessibility compliance status of your digital products. They evaluate your product against WCAG (Web Content Accessibility Guidelines) success criteria across different conformance levels.

{% hint style="info" %}
ACRs use the VPAT template recognized by procurement teams. Generate one from any audit's results, share it with stakeholders, and version it as your accessibility improves.
{% endhint %}

***

### How ACRs are created

{% stepper %}
{% step %}
**Select a product**

ACRs are generated from the active issues in your product.
{% endstep %}

{% step %}
**Add details** (optional)

Customize your ACR with additional context:

* **Notes**: general observations or context about the evaluation
* **Evaluation methods**: tools and techniques used during testing
* **Legal disclaimer**: any legal statements or limitations
  {% endstep %}

{% step %}
**Automated analysis**

Behind the scenes, DevAlly:

* Analyzes all issues from the selected audit
* Maps violations to specific WCAG success criteria
* Calculates conformance at each level (A, AA, AAA)
* Generates an overall compliance rating
* Identifies key problem areas and their impact
* Creates a structured document in VPAT format
  {% endstep %}

{% step %}
**Generation**

The ACR is generated as a `.docx` file that includes:

* **Overall compliance rating** (Full, Partial, or None)
* **Level-by-level breakdown** (A, AA, AAA)
* **Supported criteria count** (e.g., 15/20 Level AA criteria)
* **Key issues**: the most critical violations found
* **Impact analysis**: how issues affect users
* **Overall summary**: executive-level overview
  {% endstep %}
  {% endstepper %}

### ACR lifecycle

{% columns %}
{% column %}
**Status states**

* **Generating**: the document is being created (initial state)
* **Draft**: ready for review but not published
* **Published**: finalized and can be shared publicly
  {% endcolumn %}

{% column %}
**Actions**

* **Download**: get the ACR as a `.docx` file
* **Publish**: make the ACR publicly available
* **Un-publish**: return a published ACR to draft
* **Delete**: remove a non-published ACR
  {% endcolumn %}
  {% endcolumns %}

### Understanding the analysis

#### Compliance rating

* **Full**: all applicable criteria are met
* **Partial**: some criteria are met, others have violations
* **None**: significant accessibility barriers exist

#### Level breakdown

Each WCAG conformance level is evaluated:

* **Level A**: minimum level (most basic accessibility)
* **Level AA**: mid-level (commonly required for legal compliance)
* **Level AAA**: highest level (enhanced accessibility)

The ACR shows how many criteria are supported vs. total criteria at each level.

### Benefits of ACRs

* **Standardized format**: uses the VPAT template recognized by procurement teams.
* **Audit trail**: links back to the specific audit that generated it.
* **Version control**: create multiple ACRs over time to track improvement.
* **Shareable**: download and distribute to stakeholders, clients, or compliance teams.
* **Automated**: no manual WCAG mapping required.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.devally.com/EfyQpV4281edZ3h0g8tY/core-concepts/accessibility-conformance-reports.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.