Search topics
Accessibility statements that are missing or say nothing
A shop has no page saying what works with assistive technology, what is known not to, or whom to tell, or has one that only claims to meet WCAG.
The problem
People who meet a barrier can't find out whether it is known, how to get round it, or whom to tell, so they leave without what they came for.
Fernleaf Tea, a small online shop, asks for a delivery date at checkout. The date is picked from a calendar that opens only on a mouse click and is never read by a screen reader. The shop's own team knows: it came up in their last test, and the fix is planned for the new year.
A keyboard user reaches the calendar and can't open it. They look for help where sites usually put it, at the bottom of the page, and find only the copyright line. Nothing says the calendar is a known problem, that leaving the date empty gets the first available day, or that the shop takes orders by email. They leave with the basket full.
The shop could have done this in a second way that is just as common. Its footer does have an Accessibility link, but the page behind it holds one sentence: "Fernleaf Tea is committed to accessibility. Our website conforms to WCAG 2.1 Level AA." It names no barrier, no other way to order, no contact and no date, and it claims a conformance the calendar breaks.
No WCAG success criterion asks for an accessibility statement, so a site can pass every WCAG check and still fail here. The requirement comes from the procurement standards and the laws built on them:
- EN 301 549 12.1.1 asks that the documentation of a product list its accessibility and compatibility features and explain how to use them, and 12.2.2 asks that its support services give the same information.
- Section 508 602.2 asks the same of support documentation: the built-in accessibility features, and those that work with assistive technology, listed and explained.
- In the EU, public sector bodies must publish a statement in the form the Commission set out in Implementing Decision 2018/1523, and the European Accessibility Act, in force since 28 June 2025, asks the services it covers, online shops among them, to publish how they meet its requirements.
These clauses were written for products and their manuals, and for a website the statement is where that information lives. Both broken pages fail them: the first says nothing at all, and the second describes no feature, no barrier and no support. The second is also worse than silence. A claim of full conformance tells someone who is stuck that the fault must be theirs.
Every site has barriers somewhere, and a statement is the one place that tells people which ones and what to do instead. Without it, each person who meets a barrier finds it alone, and the shop never hears about it.
10 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (affected)
- No hearing (affected)
- Hard of hearing (affected)
- No speech (affected)
- Motor (affected)
- Reach, strength (affected)
- Cognitive (affected)
- Seizures (affected)
- Limited manipulation A keyboard user who can't open the delivery calendar has no way to learn that leaving the date empty works, or that the shop takes orders by email, so the basket is abandoned.
- Without vision A screen reader user who meets the same calendar can't tell whether it is broken or they are doing something wrong, and finds no one to ask.
- Limited vision Someone who zooms in until the checkout scrolls sideways can't learn whether that is known, or how else to order.
- Without hearing A deaf visitor who finds a product video with no captions can't learn whether a transcript exists, and a phone number as the only contact shuts them out.
- Limited hearing Someone who can't follow a video's quiet narration can't find out whether captions are coming, or where to ask for the words.
- Without perception of colour Someone who can't tell which size is chosen, because only colour marks it, finds no page that says so or offers another way to check.
- Without speech Someone who can't speak can't use a phone line, so with no written contact listed anywhere they have no way to report the barrier.
- Limited reach and strength Someone who can't reach or press a control the way the page expects finds no other way to finish the order, and no one to tell.
- Limited language, cognitive and learning abilities A page that only says the site meets WCAG tells someone who is stuck that the problem must be theirs, and gives them nothing to do next.
- Photosensitive seizures Someone who must avoid flashing content can't learn beforehand whether any page has it, because nothing says what was checked.
Because no WCAG rule asks for a statement, page checkers such as axe never mention one. This audit looks across all the pages it was given for a link to a statement: a link named Accessibility, Accessibility statement or a similar name in English or Japanese, or one whose address has "accessibility" in it. When none of the pages has one, it sends a review lead rather than a finding, since the statement may be linked from a page the audit was not given, or sit in a help page that the footer links as Help. It can't judge what a statement says: whether the barriers listed are the real ones, whether the claim matches the tests, or whether anyone answers the email.
AI tools and statement generators write a tidy page in seconds, and that is the risk. Asked for "an accessibility statement", they write the commitment and the WCAG claim, because those are the parts that need no facts. The parts that help someone who is stuck, the known barriers, the other ways round them and a contact who answers, can only come from testing the site and from the people who will answer.
Try it
Imagine the delivery calendar won’t open for you. Find out what to do instead, and whom to tell.
Look at the bottom of the shop, and follow what you find there. The panel under the window says what you found. Broken 2 has an Accessibility page that only makes a claim. Choose Fernleaf Tea to go back to checkout.
Broken Can you fix this?
Checkout
What you have found
- Whether the calendar problem is known
- Another way to order
- Whom to tell, and how soon they reply
- When it was last checked
The fix
Publish what works, what doesn't and how to reach you, and link it from every page.
- 1Link the accessibility information, or the help page that holds it, from the same place on every page.
- 2List each known barrier in plain words, with another way to do the task.
- 3Give a way to reach you, a reply time and the date it was last checked.
No page about accessibility
<footer> <p>© 2026 Fernleaf Tea</p></footer>A statement page linked from every page
<footer> <a href="/accessibility">Accessibility</a> <p>© 2026 Fernleaf Tea</p></footer> <!-- /accessibility --><h1>Accessibility</h1><p>We want everyone to be able to shop at Fernleaf Tea. This page says how well the site works with assistive technology, what we know doesn't work yet, and how to reach us.</p> <h2>How accessible this site is</h2><p>We aim to meet WCAG 2.2 Level AA. The site partially meets it: the parts listed under “What doesn't work yet” do not.</p> <h2>What works</h2><ul> <li>Everything but the calendar listed below can be used with a keyboard alone.</li> <li>Text can be enlarged to 200% without losing anything.</li> <li>Product videos have captions, turned on with the CC button.</li></ul> <h2>What doesn't work yet</h2><ul> <li>The delivery date calendar at checkout can't be used with a keyboard or a screen reader. Leave the date empty to get the first available day, or email us the date you want. We expect to fix it by 31 January 2027.</li></ul> <h2>Tell us about a problem</h2><p>If anything on the site stops you, email <a href="mailto:[email protected]">[email protected]</a> or call <a href="tel:+15550100">+1 555 0100</a>. We reply within two working days, and we can take your order by email or phone at the same price.</p> <h2>How we tested</h2><p>Our own team tested the site with automated checks, a keyboard and the NVDA screen reader.</p><p>Last reviewed: <time datetime="2026-09-30">30 September 2026</time>.</p>Nothing on any page says how the site works with assistive technology, what is known not to work, or how to get help, so the calendar's barrier has no way round it that anyone can find.
The page answers what someone who is stuck needs to know, in the order they need it: whether the problem is known, another way to do the task, whom to tell and how soon they will hear back. Linked under the same word from the footer of every page, it is found from wherever someone gets stuck.
Both pass, and both say the same things. A page of its own has room for a longer list of barriers, the features explained one by one and how the site was tested, and it is what EU public sector bodies must publish, in the Commission's model form. A section in the help page costs one heading in a page the shop already keeps, and it sits where people go when something breaks, which suits a small site with one or two known barriers. Choose the page when a law asks for a statement or the list is long; choose the section when the help page is already where people look.
Write it from the latest test, not from the target. The list of barriers is the audit's open findings in plain words, each with what to do instead and, where you can, when it will be fixed. Take an item off when the fix ships, and change "partially" to "fully" only when a test says so.
Offer more than one way to reach you where you can, since each channel shuts someone out.
- Email reaches people who can't hear or speak on the phone, and leaves a record of what was asked.
- A phone line reaches people for whom writing, or the site itself, is the barrier.
- A form must work with a keyboard and a screen reader itself, and must not sit behind a CAPTCHA.
Say who answers and how soon, and make sure that person can help: take the order by email at the same price, send the document in another format, or pass the barrier to whoever can fix it.
Name the parts the shop doesn't build. A payment page, a chat widget or a booking tool from another company can carry its own barriers: say which, what you have asked its maker for, and the other way to do that task meanwhile.
Keep the link in the same place on every page, as help that moves between pages explains for help links in general, and in plain words: Accessibility, or Help when the help page holds the section, not hidden in a menu or behind an icon. A site in several languages needs the statement in each of them.
Where a law sets the form, follow it. EU public sector bodies use the model statement, which adds the enforcement procedure and the body to complain to. Other sites can start from the W3C's statement generator, which asks for the same parts. In Japan, businesses have had to provide reasonable accommodation when asked since April 2024, and the statement's contact routes are where such requests arrive. Don't publish a "fully compliant" badge or statement written by an overlay vendor: it claims what nobody tested.
Review it on a date you set: after each accessibility test, after a redesign, and at least once a year, and change the date on the page each time.
Fixing this with an AI coding assistant? Get this guide as Markdown
Verify the fix
4 checks, no mouse.
Test with: Keyboard, Screen reader, Zoom
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after each accessibility test and each release that fixes or adds a barrier.
Limits
This is a starting pattern, not legal advice: what a statement must contain, and who must publish one, depends on the country and the kind of organisation. A statement doesn't fix a barrier or make a site conform, it only stops people meeting it alone. This guide covers the information a website gives about its own accessibility. It doesn't cover manuals for hardware or software, their accessible formats (EN 301 549 12.1.2, Section 508 602.3 and 602.4), or how a help desk meets callers' communication needs (Section 508 603.3). Test the complete journey with your target assistive technology.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- w3.org: statements (opens in a new tab)
- w3.org: generator (opens in a new tab)
- etsi.org: en_301549v030201p.pdf (opens in a new tab)
- access-board.gov: ict (opens in a new tab)
- eur-lex.europa.eu: oj (opens in a new tab)
- eur-lex.europa.eu: oj (opens in a new tab)
- gov.uk: sample-accessibility-statement (opens in a new tab)
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.