(484) 867‑8419 [email protected] Client portal

Web & Accessibility

How to Write an Accessibility Statement (Using Ours as the Example)

Nathaniel Kober · · 7 min read

Part of our Website Development & Hosting work.

An accessibility statement tells visitors what standard your website aims for, how you check it, where it falls short and how to report a problem. Done honestly, it turns a frustrated visitor into a fixable request. Here's what to include, what to avoid, a template you can adapt, and a walk-through of our own statement.

An older man at a home desk leans toward a large monitor showing a website zoomed in so that a park photo and two large buttons fill the screen, his hand on the keyboard and his glasses beside a coffee mug.

Article

Somewhere on your website, a visitor will hit a barrier. A form a screen reader can't describe, a PDF that won't zoom, a menu that won't open from the keyboard. What happens next depends on whether they can find a way to tell you, and whether they believe you'll do anything about it.

That's the job of an accessibility statement. It's a short page that says what standard your site aims for, how you check it, what you know isn't working yet, and exactly how to report a problem.

The short answer: a good accessibility statement includes a commitment to accessibility, the standard you're working toward (usually WCAG 2.1 or 2.2 Level AA), how you test, any known limitations, and a real way to report problems with a response time you'll actually meet. Keep it honest and specific. Never claim your site is "fully compliant" or that a widget makes it so. The W3C, which publishes the accessibility guidelines, offers a free generator to get you started, and below is a template plus our own statement explained section by section.

Why bother with one

It gives people a way in. The Justice Department's guidance on web accessibility under the ADA recommends giving the public a way to report accessibility problems so they can be fixed. A statement with a clear contact route is the simplest way to do that.

It turns complaints into tickets. A visitor who can email a named address and get a reply within a day is a visitor whose problem gets fixed. A visitor who can't find anyone to tell is more likely to give up, or to call a lawyer.

It's required in some places. Public-sector bodies in countries implementing the European Union's Web Accessibility Directive must publish one. U.S. law doesn't require a statement by name, but for municipalities working toward the ADA Title II deadlines, it's one of the clearest signals of good faith. We explain those deadlines in website accessibility and the ADA in 2026.

It keeps you honest internally. Writing down how you test forces the question of whether you actually do.

What to include

The W3C's Web Accessibility Initiative lists three parts every statement should have, plus several more it recommends.

Parts of an accessibility statement, based on W3C WAI guidance
Part Required or recommended What it looks like in practice
A commitment to accessibility Should include One or two sentences on why accessibility matters to your organization. Skip the marketing language.
The standard you're working toward Should include Name it exactly: "WCAG 2.2 Level AA" or "WCAG 2.1 Level AA." Municipalities should note that WCAG 2.1 AA is the ADA Title II standard.
How to report a problem Should include An email address and a phone number, ideally role-based, plus a realistic response time and an offer to provide the content another way.
Known limitations Recommended Be specific: "Meeting packets before 2024 are scanned PDFs. Request a text version and we'll send one."
How you check accessibility Recommended Automated scans, keyboard testing, screen reader testing, and how often you do them.
What it's been tested with Recommended Browsers, screen readers and devices, such as VoiceOver on Safari or NVDA on Firefox.
Applicable laws and policies Recommended Especially for public bodies: the ADA, Section 504 or state rules that apply to you.
Date of the statement Good practice When it was last reviewed, so visitors know it's current.

What to avoid

  • "This website is fully ADA compliant." Very few sites can truthfully claim it, and an inaccurate claim can become evidence against you. Say what you're working toward and how.
  • Leaning on an overlay. If your statement credits an accessibility widget with making your site compliant, it's promising something the Federal Trade Commission has already penalized a vendor for claiming. In 2025, the FTC finalized a $1 million order against overlay company accessiBe over those claims.
  • A contact route that doesn't work. A form that itself isn't accessible, an inbox nobody checks or a phone number that goes to voicemail defeats the purpose.
  • A response time you won't meet. "Within one business day" is great if it's true. "Within 30 days" may be more honest for a small volunteer-run office. Either is better than silence.
  • Copying someone else's statement word for word. A statement describing tests you don't run is worse than no statement at all.
A woman wearing headphones reads a refreshable braille display with one hand while her other hand rests on a laptop at a sunlit home desk.
An accessibility statement is written for the person who just hit a barrier. Tell them exactly how to reach you.

Our statement, section by section

Our own statement lives at kosmicedge.com/accessibility. Here's what it says and why we wrote it that way.

What it says

The opening. We sell accessibility audits, so it would be indefensible for our own site not to meet the standard we hold clients to.

The standard. WCAG 2.2 Level AA on every page.

How it's tested. Automated checks on every change that block release on serious or critical violations; color pairs contrast-tested programmatically; manual keyboard-only and screen reader passes (VoiceOver on Safari, NVDA on Firefox) before template changes; checks at 320 pixels wide and 200% zoom.

A caveat. Automated tools catch only part of real accessibility problems.

Known limitations. Embedded content from other organizations is named on the page, with another route to the same information.

Reporting. Email or phone, a response within one business day, and the content in another format while the underlying problem is fixed.

Why we wrote it that way

The commitment is specific to us. It explains why accessibility matters to our business, not just that it does.

We name the exact standard. WCAG 2.2 is the current version and includes everything in 2.1, the ADA Title II standard.

We describe real tests. Each one is something a reader could check, including which screen readers and browsers we use.

We admit what tools can't do. Automated scans miss many problems, which is why we test by hand too.

We name what we can't control. Third-party embeds are a common blind spot. Saying so, and offering another route, is more useful than pretending they don't exist.

We commit to a response time and an interim fix. A visitor shouldn't have to wait for a code change to get the information they came for.

A template you can adapt

Replace the bracketed parts, delete anything that isn't true for your site, and have someone check that every claim matches what you actually do.

Accessibility statement

[Organization name] wants everyone to be able to use this website, including people with disabilities.

Our standard. We aim for this website to meet the Web Content Accessibility Guidelines (WCAG) [2.1 or 2.2] Level AA.

How we check. [For example: We test new pages with an automated accessibility checker, navigate key pages using only a keyboard, and review them with a screen reader. We review the site [quarterly / after each major update].]

Known limitations. [For example: Some older documents are scanned PDFs that may not work with screen readers. Our online payment portal is provided by [vendor], and we're working with them on accessibility. Contact us and we'll provide the information another way.]

Tell us about a problem. If something on this site doesn't work for you, email [role-based email address] or call [phone number]. Please tell us the page and what happened. We'll respond within [timeframe] and provide the information in another format while we work on a fix.

This statement was last reviewed on [date].

Where to put it, and how to keep it current

  • Link it from your site's footer on every page, labeled "Accessibility." That's where people look.
  • Make the statement page itself accessible. Plain text, real headings, a working email link. No PDF.
  • Review it at least once a year, and whenever you redesign, change vendors or add a major feature like online payments or a booking tool.
  • Track the requests you get. Each one shows you where the site needs work, which is what the statement was for.

For documents in particular, the requests you receive will often point to PDFs. We cover what to do about them in accessible PDFs, or why you should stop posting so many of them.

Frequently asked questions

Is an accessibility statement legally required in the U.S.?

U.S. law doesn't require one by name. But the Justice Department recommends giving the public a way to report accessibility problems, and a statement is the clearest way to do it. Public bodies in EU countries are required to publish one.

What should an accessibility statement include?

At minimum: a commitment to accessibility, the standard you're working toward, such as WCAG 2.2 Level AA, and how to contact you about problems. Known limitations, how you test and when the statement was last reviewed are also recommended.

Can I say my website is ADA compliant?

Only if you're confident it's true and can show your work. It's safer and more honest to say which standard you're working toward, how you check, and how people can report problems.

Is there a free accessibility statement generator?

Yes. The W3C's Web Accessibility Initiative offers a free generator that produces a statement you can customize. Make sure every claim in it matches what you actually do.


Sources

This article is general information, not legal advice. The illustrations are AI-generated.

Keep reading

Web & Accessibility

Site Speed for Small Websites: What Core Web Vitals Measure and What's Worth Fixing

Google measures how fast your pages load, how quickly they respond and whether they jump around while loading. Fewer than half of websites pass on phones. Here's what Core Web Vitals actually measure, how much they matter for search, and the handful of fixes that make the biggest difference on a small business or municipal site.

· 7 min read

Web & Accessibility

Accessible PDFs, or Why You Should Stop Posting So Many of Them

Agendas, minutes, fee schedules and permit forms: most borough and business websites are full of PDFs, and most of those PDFs are hard to read on a phone and impossible for many screen reader users. Under the ADA Title II rule, new ones have to be accessible. Here's which documents should become web pages, how to make the rest accessible, and what the old-document exception really covers.

· 10 min read

Web & Accessibility

Designing Websites for Older Adults: They're Online, So Build for Them

Older adults are online in large numbers, often on phones, and they're a prime target for online scams. Most websites still aren't designed for them. Here's what the data shows and how to build sites that work for older visitors and everyone else.

· 7 min read

Want this looked at on your own site?

A free accessibility audit tells you what fails and what it takes to fix, in plain language.