Accessibility statement

Where it stands

accessible-by-default.dev targets WCAG 2.2 AA. That is a target, not a conformance claim: the whole site has not been evaluated against it, the first known gap below fails it, and two practice pages fail on purpose.

There is no accessibility overlay, no analytics, no third-party embed, and no audio or video.

What runs on every change

A change goes live only after these pass in the engines behind Chrome, Firefox and Safari:

• axe, set to the WCAG A and AA rules, on every content page.
• Keyboard paths: the skip link, dialog focus, popovers and theme persistence.
• The checks package, which presses the widgets and walks the dialogs.
• Layout at 320 CSS pixels, with WCAG text spacing, and at 200% text.
• Contrast of the glass surfaces and the text field in every theme, and focus rings that no box clips.
• Emulated forced colours and reduced motion, plus reduced transparency in Chromium, the only engine that reads it.

The CI workflow and the tests are public, and the proof chapter says what each layer can and cannot catch. A green run does not prove conformance: the first known gap below got past all of it.

What is checked by hand

VoiceOver on the Mac, an iPhone and Safari itself are checked by hand from time to time, not before every change. NVDA, JAWS, TalkBack, voice control and switch access are not part of that, so this statement says nothing about how the site works with them.

The announcements in the listening room are predictions worked out from the accessibility tree, not recordings of a running screen reader. The room says so.

Known gaps

• Demo control edges fail WCAG 1.4.11. Eight form controls in demos on the standard, showcase and proof chapters have edges far under the 3:1 this AA criterion asks for, most of them about 1.3:1. Measured in Chromium on 1 November 2026.
• Forced colours flatten control states. Every control gets the same thin border, so the invalid, pressed and disabled edges disappear. Error messages keep their warning sign, but no page shows one yet. Measured in Chromium and Firefox on 29 October 2026.
• Chapter headings skip a level. The standard, craft, showcase and proof go from the h1 straight to h3, so a heading list starts one level deep. Not a WCAG failure. Measured in Chromium on 1 November 2026.
• On phones the contents come first. A chapter’s contents sit before its title, in the reading order too, so the h1 starts 345 to 667 pixels down a 402 pixel wide screen. Measured in Chromium on 1 November 2026.
• Small labels on phones. The links in the chapter bar are 9 pixel capitals at the default text size. Measured in Chromium on 1 November 2026.
• Some lists may lose their semantics. Sixteen components remove list markers without restoring the list role, so Safari may not expose them as lists. Not measured.
• The carousel demo ignores the theme chosen here. Its slides follow the operating system’s colour scheme instead.
• The contents highlight can fade. After a jump to a tall section, the clicked link in the chapter rail can stay faint. Visual only: the links carry no aria-current. Seen in all three engines on 29 October 2026.

Barriers here on purpose

Some things on this site are broken to teach something. They are not gaps:

• The audit room and the listening room each frame a page with planted barriers. Nothing outside the frame is broken.
• The break-it toggles on the standard turn a criterion off so you can feel what it prevents.
• Escape does not close the takeover dialog on the showcase, because closedby="none" is the point of that demo.

What it depends on

Every page is rendered to markup at build time, so its content is there before any JavaScript runs. The script only wakes up what is already on the page.

The site is written for current Chrome, Firefox and Safari, and honours your motion, contrast, transparency and colour-scheme preferences. Demos under “Limited availability” use features still landing across engines: on an older browser they fall back to a simpler, still-usable form.

It is a playground for showing how the web platform answers accessibility natively, made to be explored and learned from, not installed into a production app.

Found a barrier?

File a barrier report on GitHub, or email hello@accessible-by-default.dev if you would rather not use GitHub. No report is too small.

This statement lives in the repository, so its history is public. It changes in the same pull request as any gap it names.