📋 Accessibility statement

How accessible this site is

A site that teaches accessibility should say plainly how accessible it is, what was actually tested, and what was not. This page does that, and then shows you how to write the same thing for your own site.

Statement prepared 7 September 2026, based on a self assessment carried out on the same day. Reviewed whenever the site changes materially.

1. Conformance status

The target is WCAG 2.2 level AA. Against that target this site is partially conformant.

Partially conformant is the honest label, and it is worth explaining why rather than reaching for a nicer word. There are two reasons.

  1. Parts of the site are inaccessible on purpose. The lessons work by showing a broken version of a component beside a fixed one. The broken half genuinely fails, because that is the point of it. Section 4 explains how those are marked.
  2. The assessment was partial. It was thorough on the things that can be measured, and it did not include a person listening to every page with a real screen reader, or testing with disabled users. Claiming full conformance on that basis would be a claim the evidence does not support.

Worth knowing: a great many accessibility statements say "fully conformant" on the strength of an automated scan alone. Automated tools find roughly a third of what is really there, so that claim is usually wrong. A statement that says what was checked is more useful, and more defensible, than one that says everything is fine.

2. What was tested, and how

All 22 pages were checked, in both the light and the dark theme, at six viewport widths from 390 to 1440 pixels. The scripts that do it are in the repository, so anything below can be rerun and checked rather than taken on trust.

What was checked, how it was checked, and the result.
Checked How Result
Visible focus Tabbed through every stop on every page, comparing the pixels around each control with and without focus 1432 stops, all with a visible change
Accessible names Read from the browser's own accessibility tree, not guessed from the markup No unnamed controls
Colour contrast Computed against the real painted background, compositing every translucent layer up the tree No failures outside the demonstrations
Target size Measured against the 24 by 24 minimum, applying the exception for a link inside a run of text No failures outside the demonstrations
Headings One h1 per page and no skipped levels, parsed from the source Clean
Images and form fields An alt attribute on every image, a label on every input Clean apart from the deliberate example
Duplicate ids Checked in the rendered page, so script generated content is included None
Reflow and overflow Every page at six widths in both themes, then again at the 320 pixels WCAG 1.4.10 actually names, at 200 percent zoom, and with the four WCAG 1.4.12 text spacing values forced on None. Three pages did fail at 320 until this check was written, because the sweep used to stop at 390
Links and anchors Every internal link and every fragment resolved against the real target All resolve

Beyond the automated passes, the site was built and reviewed by hand throughout. Every interactive component follows the published ARIA pattern for its type, the diagrams carry a title, a description and a visible caption, and nothing is communicated by colour alone.

3. What was not tested

This is the section most statements leave out, and the one a reader actually needs. If you rely on any of the following, do not assume this site has been proved to work for you. Please tell me if it does not.

  • No screen reader listening session. Names, roles and states were read from the accessibility tree, which is what a screen reader announces, but nobody has sat and listened to every page with NVDA, JAWS, VoiceOver or TalkBack. Reading the tree tells you a control has a name. It does not tell you the whole page makes sense spoken end to end.
  • No testing with disabled users. Nothing here has been through a usability session with the people it is written for. That is a real limitation, and it is the gap I would close first with a budget.
  • No independent audit. This is a self assessment. It has not been reviewed by anybody else.
  • No voice control or switch access testing. Visible labels and accessible names generally match, which is what voice control needs, but that was not verified by driving the site with either.
  • No braille display testing.
  • Cognitive accessibility has not been formally assessed. The writing aims to be plain, but plain language was a goal rather than a measured result.

4. The deliberately inaccessible parts

This site teaches by contrast. Almost every lesson shows the same component built two ways, one broken and one fixed, side by side and live, so you can feel the difference rather than read about it. The broken half really is broken. A button with no focus ring really has no focus ring.

That creates an obvious problem. A screen reader user landing in the middle of a lesson could reasonably conclude the site is simply bad. So every broken example is marked:

✕ How it would be confusing

A broken demo dropped into the page with nothing to say what it is. Someone using a screen reader meets a run of unlabelled controls and has no way to know it is intentional.

✓ What is actually there

Every broken example sits in a container with role="group" and an accessible name saying so, along the lines of "Inaccessible example, shown for demonstration". It is announced before the controls inside it, and each pair carries a visible badge as well.

The affected areas are the ten lesson demonstrations on the home page, the do and do not pairs on the social media pages, the low contrast sample on the colour page, and the before and after code blocks on the developer page. Everywhere else, the site is trying to be right rather than to be instructive.

If you are copying this idea, mark your bad examples the same way. An intentional failure that is not announced as intentional is just a failure. This is the one place where "we did it on purpose" is a valid answer, and it is only valid if you said so in the page.

5. Report a problem

If something here does not work for you, I want to know, and I will fix it. You do not need to know the name of the rule it breaks or explain it in technical language. "The menu does nothing when I press Enter" is a perfect bug report.

Useful things to include, if you can, though none of them are required:

  • The page you were on
  • What you were trying to do
  • What happened instead
  • Your browser, and any assistive technology you use
Email an accessibility problem

Direct: [email protected]

I aim to reply within five working days. If a fix is going to take longer than that, I will say so and tell you roughly when, rather than going quiet.

6. Technical details

Accessibility here depends on the following technologies working in your browser.

  • HTML and CSS, which everything depends on.
  • WAI-ARIA, used only where native HTML has no element for the job.
  • JavaScript, for the interactive demonstrations, the theme toggle, the glossary search, the quiz and the contents panel.

With JavaScript turned off, twenty of the twenty-one pages still deliver their full content and every link still works. The theme follows your system preference. The glossary keeps all 102 terms and its A to Z, though its search box stops filtering. The interactive demonstrations sit still, and the contents panel on the long pages does not appear, but the jump links at the top of those pages do the same job.

The one exception is the quiz, whose questions are built entirely by script. With JavaScript off it says so and points you at the pages the questions come from, all of which read fine without it.

Found while writing this page: the claim above was not true when it was first drafted. The entrance animation set content to zero opacity in CSS and script brought it back, so with JavaScript off most of the site was present in the markup and invisible on screen. Writing down what a site does is a surprisingly good way of finding out what it actually does. It is fixed: the animation now only applies where script is running to undo it.

The site is plain static HTML with no build step and no framework. There is no tracking, no analytics and no cookies. The one thing stored in your browser is your light or dark theme choice, kept in localStorage on your own device.

7. Writing your own statement

Under the EU Web Accessibility Directive a public sector body has to publish one of these, and under several other regimes it is expected even where it is not compelled. Beyond compliance it is simply good manners. It tells a disabled visitor what to expect before they waste twenty minutes finding out.

A usable statement has six parts. Most published ones have two.

1

A conformance claim, with the standard named

Fully, partially or not conformant, against a named version and level. "WCAG 2.2 level AA" rather than "accessible". If you are not sure, partially is nearly always the right answer.

2

What you actually did

Which tools, which pages, which browsers, which assistive technology, and when. A claim with no method behind it is an opinion.

3

What you know is wrong

List the known problems in plain words, and say when each will be fixed. This is the part people are most afraid of and it is the part readers trust you for.

4

A way to complain, and a response time

An email address that a person reads, and a commitment you can keep. A form is fine only if the form itself is accessible, which is a funnier failure than it sounds.

5

An escalation route

Where someone goes if you do not reply, or if your answer is unsatisfactory. In the EU that is a named enforcement body. Elsewhere, say honestly what recourse exists.

6

Dates

When the statement was prepared, when it was last reviewed, and when the assessment behind it was done. A statement with no date could be a decade old.

A skeleton to start from

Copy this, then replace every square bracket. If you cannot fill one in truthfully, that gap is the next piece of work rather than something to word around. 

Accessibility statement for [site or service name]

[Organisation] is committed to making [site] usable by everyone,
including disabled people.

Conformance status
This site is [fully / partially / not] conformant with the Web
Content Accessibility Guidelines version 2.2, level AA.
[If partially: name what falls short, in plain words.]

How this was tested
Assessed on [date] by [who: us, or the auditor's name].
Pages tested: [all, or the list, or the sample and why].
Tested with: [browsers, screen readers, other assistive technology].
Method: [automated tools named, plus what was checked by hand].

Known problems
- [Plain description of the problem, where it appears, and the
  effect on someone using the site.] Expected fix: [date].
- [Repeat for each known problem.]

Content that is not accessible
[Anything out of scope, and why. Third party embeds, archived
documents, deliberately broken examples.]

Feedback
If you find a problem, contact [name] at [email or phone].
We aim to reply within [timeframe].

If you are not satisfied
[Escalation route: named enforcement body, ombudsman, or the
honest position if there is none.]

Statement prepared [date]. Last reviewed [date].

One last piece of advice, from having read a great many of these. Do not write it in legal language. The person most likely to read your accessibility statement is somebody who has just hit a wall on your site and is deciding whether it is worth telling you. Write it for them.

The checks behind this statement are four scripts in the repository, and they are documented in the README. If you want to run the same ones against your own site, part 4 of the training explains the method by hand: testing what you build.

↑