Fernleaf Tea is committed to accessibility. Our website conforms to WCAG 2.1 Level AA.
``` The link is there, but the page describes no feature, no barrier, no other way to order, no contact and no date, and its claim is not true while the calendar fails. ## After: a statement page linked from every page ```htmlWe 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.
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.
If anything on the site stops you, email help@fernleaf.example or call +1 555 0100. We reply within two working days, and we can take your order by email or phone at the same price.
Our own team tested the site with automated checks, a keyboard and the NVDA screen reader.
Last reviewed: .
``` 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. ## After: an accessibility section in the help page, when the site already has one ```html…
…
We aim to meet WCAG 2.2 Level AA, and the site partially meets it. Everything but the calendar below can be used with a keyboard alone, text can be enlarged to 200%, and product videos have captions, turned on with the CC button.
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.
If anything on the site stops you, email help@fernleaf.example or call +1 555 0100. We reply within two working days, and we can take your order by email or phone at the same price.
Last reviewed: , by our own team, with automated checks, a keyboard and the NVDA screen reader.
``` The same answers, in the page people already open when something goes wrong, beside delivery and returns. The footer's Help link is where people already look when they are stuck, and the Accessibility heading in the page is found there, by eye or from a screen reader's list of headings. ## Which option to use 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. ## Implementation decisions 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](/learn/consistent-help) 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. ## Verify the fix 1. From three different pages, such as the home page, a product page and checkout, find the link named Accessibility, or Help when the help page holds the section, in the same place on each, and follow it to the accessibility information. 2. Compare the barriers listed with the latest audit. Every open failure is there in plain words with another way to do the task, and the status claims no more than was tested. 3. Send a short test message by each contact route given, and confirm a reply within the stated time from someone who can help. 4. Check that the date matches the last review, and that the statement itself works with a keyboard, a screen reader and 200% 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.