> 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-statement.md).

# Accessibility Statement

Accessibility statements are public-facing documents that communicate your organization's commitment to accessibility, current conformance status, and how users can get support. They serve as a transparent communication channel between your organization and users with disabilities.

{% hint style="info" %}
A published accessibility statement lives at a public URL like `accessibility.<your-org>.com` and includes your branding, your statement narrative, tested assistive technology combinations, and any published ACRs.
{% endhint %}

***

### How accessibility statements are created

The platform guides you through a three-step wizard to create a professional, standards-compliant accessibility statement:

{% stepper %}
{% step %}
**Essentials**

Set up the core information and branding:

* **Organization logo**: your brand's visual identity (SVG recommended)
* **Organization name**: your company or product name
* **Statement key**: a unique identifier (e.g., "DevAlly" for accessibility.devally.com)
* **Organization description**: brief overview of your organization
* **Hero color**: brand color for the statement header (hex format)
  {% endstep %}

{% step %}
**Statement content**

Customize the accessibility commitment narrative:

* **Pre-generated template**: starting point based on your organization name
* **Rich text editor**: edit and format the statement to match your accessibility journey
* **Customizable content**: describe your current phase, goals, and roadmap

Default template highlights:

* Current accessibility status
* Planned improvement phases
* WCAG conformance goals
* Process improvements being made
  {% endstep %}

{% step %}
**Technology recommendations**

Specify tested assistive technology combinations:

* **OS**: operating system (Windows, macOS, Linux)
* **Screen reader**: assistive technology (NVDA, JAWS, VoiceOver)
* **Browser**: web browser (Firefox, Chrome, Safari)

You can add multiple recommendations for different user environments.
{% endstep %}
{% endstepper %}

***

### Published accessibility statement features

Once published, your statement becomes a dedicated public page that includes:

#### Core content

* **Organization header**: logo, name, and description with branded hero section
* **Statement body**: your customized accessibility commitment text
* **Technology recommendations**: list of tested software combinations
* **WCAG compliance badge**: visual indicator of standards adherence

#### Accessibility Conformance Reports (ACRs)

Published ACRs are automatically displayed:

* Links to download VPAT documents
* Compliance ratings and summaries
* Generation dates for transparency

#### Support portal integration

* **"Report an Issue" button**: allows users to submit accessibility feedback
* **Support form**: integrated ticketing system for accessibility issues
* **Product selection**: users can specify which product has the issue

***

### Statement lifecycle

{% columns %}
{% column %}
**Status management**

* **Draft**: statement is being created or edited (not public)
* **Published**: statement is live at `accessibility.<statement-key>.com`
  {% endcolumn %}

{% column %}
**Actions**

* **Save**: store changes without publishing
* **Publish**: make the statement publicly accessible
* **Un-publish**: return to draft
* **Modify**: edit an existing statement
  {% endcolumn %}
  {% endcolumns %}

#### URL structure

Published statements are accessible at:

* Platform URL: `/statement/<statement-key>`
* Custom domain: `accessibility.<statement-key>.com` (configurable)

### Benefits

* **Transparency**: shows users you care about accessibility
* **Legal compliance**: meets regulatory requirements for public statements
* **User support**: provides a clear path for reporting issues
* **Brand consistency**: maintains your visual identity
* **Living document**: easy to update as your accessibility posture improves
* **Professional format**: standards-based structure recognized by accessibility advocates


---

# 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-statement.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.