Creating an effective accessibility statement for your organization’s website
An accessibility statement explains how an organization is making its website usable for people with disabilities. It should describe current accessibility features, known limitations, support options, and the process for reporting barriers. When written clearly, it becomes a practical communication tool rather than a legal formality.
A strong statement helps visitors understand what to expect before they encounter a problem. It also gives developers, content teams, customer service staff, and leadership a shared reference point for improving digital access.
Creating an effective accessibility statement requires accuracy, plain language, and a commitment to ongoing work. The statement should reflect the real website experience, acknowledge gaps without defensiveness, and make it easy for users to request assistance.
Start with a clear purpose
The first section should explain the organization’s commitment to digital accessibility. Use direct language that recognizes disabled users as an important part of the audience, rather than presenting accessibility as a favor or an optional enhancement.
Mention the standards or guidance used to evaluate the website, such as the Web Content Accessibility Guidelines (WCAG). If your organization is working toward a particular level of conformance, name it carefully. Do not claim full compliance unless the website has been assessed thoroughly and the claim can be supported.
A useful opening might state that the organization aims to provide an accessible digital experience for people using screen readers, keyboard navigation, voice control, magnification, captions, alternative input devices, and other assistive technologies. This establishes a broad understanding of access without reducing disability to a single technical checklist.
Describe the experience users can expect
Visitors need practical information more than general promises. Explain which accessibility features are currently available, including keyboard-operable menus, meaningful heading structures, text alternatives for images, accessible forms, captions for video, readable color contrast, and compatibility with common assistive technologies.
Be specific about the scope of the statement. Say whether it covers the main website, online forms, customer portals, mobile applications, embedded documents, third-party services, or downloadable files. A statement that covers only selected pages should identify those boundaries plainly.
Avoid vague claims such as “our website is fully accessible to everyone.” Digital access depends on browser settings, assistive technology, content formats, and ongoing changes to the site. Accurate wording builds more trust than an absolute promise that users may quickly disprove.
Acknowledge barriers with useful detail
Every organization should identify known accessibility issues when they exist. This could include inaccessible PDF documents, missing captions, inconsistent heading levels, unlabeled form fields, low-contrast text, complex data visualizations, or third-party booking systems that the organization does not control directly.
A limitation should be paired with useful context. Explain which content is affected, how users may encounter the barrier, whether an alternative is available, and what work is underway. For example, a statement could say that older documents are being remediated and that users may request an accessible version while that process continues.
The following comparison shows how wording can change the usefulness of an accessibility statement:
| Less useful wording | More effective wording |
|---|---|
| We are committed to accessibility. | We are improving keyboard navigation and form labels across the events section. |
| Some content may not be accessible. | Several older PDF brochures may not work reliably with screen readers. |
| Contact us if you have trouble. | Email our access team at the published address, and include the page title or document name if possible. |
| We meet all accessibility standards. | The site is partially conformant with WCAG 2.2 AA, with known issues listed below. |
| We will fix problems soon. | We review reported barriers monthly and publish progress as fixes are released. |
This approach turns an abstract accessibility commitment into information users can act on. It also gives internal teams a clearer basis for prioritizing repairs.
Provide a reliable feedback process
An accessibility statement should make reporting a barrier simple. Include a dedicated email address, contact form, telephone option, or postal address, depending on the needs of your audience. Make sure the reporting channel itself is accessible and monitored by people who can respond appropriately.
Tell users what information is helpful, such as the page address, the type of device or assistive technology used, and a description of the difficulty. Avoid making these details mandatory if they create an extra burden. A person should be able to report a problem without completing a complicated form.
Explain what happens after a report is received. Include an expected response time, an escalation route, and the name of a department or role responsible for follow-up. If the organization has a formal complaints or dispute process, link to it from the statement while preserving a straightforward route for informal feedback.
Feedback should be treated as valuable evidence rather than as a nuisance. Reports from Deaf, hard-of-hearing, blind, low-vision, neurodivergent, mobility-impaired, and cognitively disabled users can reveal barriers that automated tools and internal reviews may miss.
Use inclusive language and communication
Accessibility statements should be understandable to a broad audience. Use short paragraphs, descriptive subheadings, familiar terms, and direct sentences. Define technical expressions such as WCAG, conformance, or assistive technology when they are necessary.
Consider how Deaf and hard-of-hearing visitors may access the information. A telephone-only contact option is insufficient. Offer written communication, accessible online contact, and captioned or transcribed media where relevant. Do not assume that all Deaf people communicate in the same way or use the same technology.
Organizations that serve the public can benefit from guidance grounded in lived experience. Christopher Tester’s accessibility expertise brings together Deaf education, interpreting, performance, and disability awareness, all of which can inform more respectful communication practices.
Review the statement for language that frames disabled people as problems to be solved. Prefer terms such as “barrier,” “access requirement,” and “disabled person” according to the language preferences of your community and organization. Cultural awareness matters as much as technical accuracy.
Make accessibility an ongoing practice
An accessibility statement becomes misleading if it is published once and forgotten. Add a review date and update the page when major changes occur, such as a redesign, new content management system, migration to a new learning platform, or adoption of a third-party payment service.
Assign responsibility for maintaining the statement. The owner might be a digital accessibility lead, web manager, communications director, or cross-functional accessibility group. Responsibility should include reviewing reports, tracking remediation work, testing new features, and updating public information.
Combine automated scanning with manual testing. Automated tools can identify missing alternative text, contrast failures, and some structural issues, but they cannot reliably judge whether instructions are understandable, captions are accurate, focus order makes sense, or a service works well with real assistive technologies.
Include disabled people in usability testing and procurement decisions. Their feedback can clarify whether a technically conformant interface is genuinely efficient and understandable. Accessibility should be considered throughout design, writing, development, training, and customer support.
Publish a practical statement
Before publishing, check that the statement is easy to find. A link in the website footer is common, but it should also be available from help pages, contact pages, account areas, and relevant service sections. Use a meaningful link label such as “Accessibility” rather than hiding the information behind a generic phrase.
The page itself must be accessible. Confirm that it can be reached by keyboard, works with a screen reader, has a logical heading structure, uses sufficient color contrast, and remains readable when text is enlarged. Keep the layout simple so users can quickly locate limitations, contact details, and the last review date.
Publication checklist
- Name the website, applications, or services covered by the statement.
- Identify the accessibility standard and the current level of conformance.
- List known barriers in plain language, including affected content and available alternatives.
- Provide accessible contact methods, response expectations, and an escalation route.
- Add the publication date, review date, responsible team, and links to progress information.
A credible statement reflects actual practice. Before publishing it, verify every claim with the people responsible for web development, content, customer support, legal review, and accessibility testing. Remove language that sounds reassuring but cannot be demonstrated.
Use the page as a living record of improvement. When a reported barrier is fixed, update the relevant information. When a new limitation appears, acknowledge it promptly and explain how users can obtain support in the meantime.
An accessibility statement should give people confidence that their access needs will be taken seriously. Publish yours where visitors can find it, connect it to a responsive feedback process, and use the information you receive to make the website more usable for everyone.