How to write an accessibility statement (with a sample statement).

An accessibility statement is a public page that states which accessibility standard a website targets, how far it meets that standard today, its known gaps and how a user who cannot access something can get in touch. A good statement is not a claim but the summary of an evaluation; that is why it is written after the audit.

Who has to publish a statement depends on the country. In Türkiye, Presidential Circular No. 2025/10 requires sites to be brought into line with the checklist but does not require a statement to be published. In the European Union, a statement is mandatory for the websites of public sector bodies, and the Commission has published a model statement. The European Accessibility Act, in turn, requires companies offering services to consumers to publish, in their general terms and conditions, information on how the service meets the accessibility requirements. W3C recommends a statement for every organization, even where it is not mandatory. This page is not legal advice; verify with the official source which rule applies to you.

Whatever framework it is written under, the value of a statement depends on the measurement behind it. An unmeasured statement is a promise, and it loses trust at the first complaint. Testing and recording every line that goes into the statement is the last step of a web accessibility audit; the framework in Türkiye is explained in the guide to the circular, the European framework in the guide to the European Accessibility Act.

What sections should an accessibility statement have?

W3C’s guidance defines the minimum content in three points: a commitment to accessibility for people with disabilities, the standard applied (for example WCAG 2.2) and contact information for a user who runs into a problem. The additional content it recommends is: known limitations, measures the organization has taken, technical prerequisites such as supported browsers, the environments in which the content was tested and the relevant national legislation.

The model statement the European Union published for the public sector (Implementing Decision 2018/1523) offers a stricter and better skeleton. Its mandatory sections are:

• Statement — which site or application the organization commits to making accessible, and the scope of the statement.
• Compliance status — one of three options: fully compliant, partially compliant or not compliant.
• Non-accessible content — with the reason: content that does not comply with the standard, content left temporarily on grounds of disproportionate burden, or content outside the scope of the legislation; plus an accessible alternative, if any.
• Preparation of the statement — the date it was prepared, the evaluation method used and the date of the last review.
• Feedback and contact — the route by which users can report content they cannot access, and the contact details of the unit handling those reports.
• Enforcement procedure — the authority users can turn to if the response is unsatisfactory.

The model also gives a list of optional sections: an intention to go beyond the legal minimum, a remediation plan and timeline, approval of the statement by management, the publication and last major update dates of the site, a link to the evaluation report and additional telephone support for users with disabilities.

When can you write “fully compliant”?

The model’s footnotes define the three statuses explicitly. “Fully compliant” is chosen only if all requirements of the standard or technical specification are met without exception. “Partially compliant” is chosen if most requirements are met but there are exceptions. “Not compliant” applies if most requirements are not met. In addition, the statements must be based on an actual evaluation — the organization’s self-assessment or a third-party assessment — and the method used is written in the statement. The model specifically recommends that an organization declaring full compliance link to its evaluation report.

WCAG’s own conformance rule points in the same direction: a level must hold for the entire declared scope (WCAG). If a single criterion fails on a single page, that scope does not conform to that level. That is why a narrow but accurate scope is more defensible than a broad but partly accurate one.

Full compliance is not an adjective but the conclusion of an evaluation report.

How do you write known gaps?

Both W3C and the EU model ask for the same thing: describe the gap in non-technical language, as the user will encounter it. “Violation of 1.3.1” tells the reader nothing; “the product catalog PDFs have no heading structure, so sections cannot be navigated with a screen reader” does. The model’s own example works the same way: it states that the login form of a document-sharing application cannot be fully used with a keyboard. The relevant criterion number can be added in parentheses, but the sentence itself is written for the user.

Two more things should be written next to the gap: an accessible alternative, if there is one (where else is the same information?), and a remediation plan. A statement with its gaps and plan written out plainly becomes a roadmap rather than a promise; a statement that lists no gaps at all contradicts itself at the first user complaint.

How often should an accessibility statement be updated?

The EU model recommends reviewing the accuracy of the statements regularly and at least once a year, and carrying out a new evaluation and updating the statement after a major revision of the site. It asks that the statement be reachable from every page — for example through a fixed link in the header or footer — and, where possible, also be offered in a machine-readable format. In practice, the date on the statement is the schedule for the next audit.

Sample statement: this site’s own status

The sample below was written with this site’s current status and follows the skeleton of the EU model. It contains only what we measure. Because it is not based on a full manual evaluation, it gives no compliance verdict — neither “fully” nor “partially.” This is not the weak side of the sample but the side it wants to show: a verdict is not written if there is no evaluation to carry it.

• Commitment — www.murattunali.com.tr aims to be usable by everyone, including people with visual, hearing, motor or cognitive differences.
• Scope — the Turkish, English and German website on the www.murattunali.com.tr domain. There is no mobile application.
• Target standard — WCAG 2.2, level AA.
• Compliance status — because this statement is not based on a full manual evaluation, no “fully compliant” or “partially compliant” verdict has been given.
• Evaluation method — self-assessment. Before release, every version passes an automated accessibility audit (axe) and a test suite of 1462 tests. The suite measures the 2-pixel thickness of the focus ring, touch targets of at least 44 pixels, the AA contrast thresholds and that animation layers are not set up when the operating system’s reduce-motion preference is on.
• Known limitations — the automated audit does not scan every page individually but pages representing each page template. Automated tools can test only part of the WCAG criteria. This statement rests only on the two automated layers above; a screen reader walkthrough and user testing are not part of this statement.
• Feedback — if there is content or a function on the site you cannot access, report it through the form on the contact page.
• Prepared — 23 September 2026 (draft).

The most valuable line in this sample is “known limitations.” It tells the reader not what was measured but what was not measured, and that is exactly where the statement’s credibility comes from. On one day in this site’s own history when the automated report was green, the borders of the fields in the contact form were below WCAG’s 3:1 threshold against the background; the tool was not asking that question. The border was fixed and a guard was added, but the lesson carries over to the statement too: where a tool passes and where a tool never looks are not the same thing (the limits of automated testing).

What should a statement not say?

• An unmeasured compliance verdict — a sentence like “our site is fully accessible” with no evaluation behind it.
• Treating a plugin as proof of compliance — an accessibility plugin loaded on the page does not replace a conformance evaluation; the difference is in the comparison overlay or fixing it in the source.
• Criterion numbers only — a technical list that does not describe the problem the user will encounter.
• An undated statement — a statement that does not say when and with what method it was prepared cannot be verified.

What do you need before writing the statement?

An evaluation. If you fall under the circular, the Ministry’s level A checklist is worked through question by question; if you serve consumers in the EU, the basis on the web side is the web section of EN 301 549, that is, the A and AA criteria of WCAG. The evaluation is done template by template: not every page, but every page type and every critical flow — contact, quote request, checkout. The result gives the statement three things: which criteria are met, which are not and how they were measured. If you have these three, the statement is a few paragraphs; if you do not, the statement should not be written — measure first.

If you want to know whether your site meets these criteria, the web accessibility audit measures every template against WCAG 2.2 point by point, fixes problems at the source and documents the result.