How to Write an Accessibility Statement

Why an accessibility statement matters

An accessibility statement is a public declaration that tells visitors with disabilities what level of accessibility your website or application provides, what is not yet accessible, and how to get help or report a problem.

Publishing one serves three purposes simultaneously. It demonstrates good faith — showing that you have considered accessibility rather than ignoring it. It provides practical information — letting users know about known issues and available workarounds before they spend time trying to use something that does not work. And in many jurisdictions, it is a legal requirement.

Under the EU Web Accessibility Directive, all public sector bodies must publish an accessibility statement that conforms to the format specified in Commission Implementing Decision (EU) 2018/1523. Under the European Accessibility Act (EAA), private sector businesses in scope must provide information about accessibility conformance — and while the EAA does not prescribe the exact format a public statement must take, publishing one that follows best practice is a strong baseline. In the United States, while the ADA does not mandate a specific document format, having a published statement and a clear feedback mechanism is considered a meaningful indicator of accessibility commitment.

The bottom line: you should have one regardless of whether your jurisdiction requires it, because it is useful to your users.

What to include

A well-structured accessibility statement contains six core elements. Leave any of them out and the statement either fails a compliance check or becomes unhelpful to the users it is meant to serve.

1. Scope

State clearly which websites, apps, or digital products the statement covers. If you have multiple domains, subdomains, or mobile apps, list each one or explain the scope explicitly.

This statement covers the website at qualibooth.com and its subdomains, including app.qualibooth.com. It does not cover third-party services linked from our site, such as our payment processor or embedded video player.

Be honest about scope. A statement that implies coverage of a product it does not actually cover is worse than no statement.

2. Conformance status

State which version of WCAG you are targeting, which conformance level (A, AA, or AAA), and your current status. The W3C defines four standard conformance statuses:

• Fully conforms — meets all requirements with no exceptions
• Partially conforms — most requirements are met but specific parts do not conform
• Does not conform — fewer than half of requirements are met
• Not assessed — the content has not been evaluated

For most organizations, “partially conforms” is the honest and appropriate status. Very few websites fully conform to WCAG 2.2 Level AA without any exceptions. Do not claim full conformance unless you have tested every page and every interaction with a range of assistive technologies and can stand behind it.

qualibooth.com partially conforms to WCAG 2.2 Level AA. The non-conformances and exemptions are listed below.

3. Known non-conformances and exemptions

This is the section most organizations skip or write vaguely. It is also the most useful section for users with disabilities.

List each known issue with enough specificity that a user can decide whether the barrier affects them:

• Which WCAG success criterion is not met
• Which part of the site is affected
• What the impact is for users
• What workaround exists, if any
• When you expect to fix it

PDF download area — Some older PDF documents do not have proper document structure for screen readers. This affects WCAG 2.1 success criterion 1.3.1 (Info and Relationships). We are remediating all PDFs published before 2024 and expect to complete this by Q3 2026. In the meantime, contact us and we will provide the information in an alternative format.

For the EAA and EU Web Accessibility Directive, you must also distinguish between non-conformances that result from your own content and those caused by third-party content you do not control (e.g., embedded maps, social media widgets).

Exemptions recognized by some regulations include:

• Disproportionate burden — where the cost of remediation is genuinely disproportionate to the benefit. This is a high bar and must be justified with documented evidence.
• Pre-recorded time-based media published before a specific date (varies by directive)
• Office file formats published before a specific date, unless required for active administrative purposes

If you claim a disproportionate burden exemption, you must document the assessment and make it available on request. You cannot simply state “this would be too expensive” — you need to show the analysis.

4. Contact and feedback mechanism

Users who encounter a barrier need a way to ask for help or report the problem. Provide:

• An email address (not a generic contact form — some users need to explain their needs in detail)
• Optionally, a phone number with text relay information
• A commitment to respond within a specific timeframe

If you experience difficulty accessing any part of this website, or if you need content in a different format, email accessibility@yourcompany.com. We will respond within 5 business days.

For EU public sector bodies, the response time under the Web Accessibility Directive is 14 days.

5. Enforcement body (where applicable)

In jurisdictions with enforcement mechanisms, link to the body where a user can escalate if they are not satisfied with your response. In the EU, this varies by member state — link to the relevant national authority. In the UK, link to the Equality and Human Rights Commission.

If you are not satisfied with our response, you can contact the [relevant enforcement body] at [URL].

Including this demonstrates you are aware of the formal complaint process and are not trying to obscure it.

6. Date

State when the statement was last reviewed and updated. An undated statement — or one dated three years ago — signals to users that it may not reflect the current state of the site.

This statement was last reviewed on 24 July 2026.

Format and placement

The statement should be a standalone page, not buried in a privacy policy or terms of service. Standard placement is:

• A link in the site footer labeled “Accessibility” or “Accessibility statement”
• A link in the site header if the organization places particular emphasis on accessibility
• Linked from the cookie or legal pages

The page itself should conform to WCAG — it would be ironic and problematic if your accessibility statement was itself inaccessible. Use plain language, headings for each section, and avoid PDF-only formats.

Keep it in plain language. The statement is for users, not lawyers. “We aim to meet WCAG 2.2 AA” is better than “The operator of the present digital service endeavors to conform to the applicable technical standards as set forth in the internationally recognized Web Content Accessibility Guidelines version 2.2 at the double-A conformance level.”

Keeping it accurate

An outdated accessibility statement is actively harmful. If it claims full conformance but users find barriers, or if it lists issues as “under remediation” that have been abandoned, it destroys trust and creates legal exposure.

Build a review cadence into your accessibility program:

• After every major release — check whether any new content or features introduce non-conformances
• Annually at minimum — re-assess conformance status and update the list of known issues
• After a user complaint — if a user reports a barrier you were unaware of, add it to the statement

Tie the review to your broader recurring accessibility audit schedule rather than treating it as a separate process. When your audit surfaces new issues, update the statement in the same sprint.

A template to start from

Here is a minimal structure you can adapt:

Accessibility Statement for [Product Name]

Conformance status
[Product] partially conforms to WCAG 2.2 Level AA.

Non-accessible content
The following content is not fully accessible:
- [Issue]: [Affected area]. Affects [WCAG criterion]. [Workaround or expected fix date].

Feedback and contact
Email: accessibility@example.com
We aim to respond within [X] business days.

Enforcement
If you are not satisfied with our response, contact [enforcement body] at [URL].

Date
This statement was prepared on [date] and last reviewed on [date].

The W3C also provides a free accessibility statement generator through WAI that walks you through the required fields and produces a statement in multiple languages.

The statement is not the goal — accessibility is

A published statement does not make a site accessible. It is a communication document, not a technical fix. The work that makes a statement credible is the accessibility testing, the remediation backlog, and the ongoing monitoring that sit behind it.

If you write an honest statement today — partial conformance, several known issues, a realistic fix timeline — and you work the backlog, you will be able to update it to reflect genuine progress. That is the trajectory organizations with strong accessibility programs follow.

If you have not yet assessed your site, run a free accessibility scan to get a baseline. It will show you which issues to address first and give you the information you need to write a statement that reflects your real starting point.