GitHub (opens in a new tab)
Mode
Themes
Color-vision friendly
High contrast

Built in, not bolted on

Most of what WCAG asks for, the platform already ships — HTML and modern CSS meet the bar natively, before any JavaScript arrives. That claim runs live on every page here: criteria you can break and restore, craft decisions shown against the mistakes they replace, tests you can rerun. Written for developers who already ship UI; nothing here repeats what the rest of the web teaches well. One argument, in four parts — start anywhere, the thread runs through all of them.

What changed

The platform and the standards keep moving. This is what moved lately and what it changed here, newest first.

  1. Craft

    The validation section now keeps its submit button live: dimmed while the form is invalid, a button looks dead from first paint, and disabled, it also takes away the browser’s own report of what is wrong.

  2. Showcase

    The scroll-driven animations showcase gained a reveal and the rule behind it: a global duration reset never reaches a scroll timeline, so every reveal needs its own prefers-reduced-motion gate.

  3. Craft

    The craft chapter’s scrollbar section now tints every thumb on the site from the page’s own tokens at 3:1 and turns it to the accent while keyboard focus is inside, so the thumb says which region the arrow keys will scroll.

  4. Showcase

    The scroll-state showcase gained its third state: a strip shades its edges only while there is more to scroll that way, a hint that never lies at the end.

  5. Proof

    The listening room: a press kit a scanner passes, eleven barriers you hear before you see, answers included.

  6. Showcase

    Safari 27 ships Customizable <select>, so that showcase now runs in two engines.

Subscribe to the feed Every commit on GitHub

Accessibility

This site practises what it shows. It targets WCAG 2.2 AA, works with a keyboard and a screen reader, and honours your motion, contrast, and colour-scheme preferences — and it never leans on colour alone to carry meaning.

It also leans on genuinely new platform features — anchor positioning, scroll-driven animation, container queries, contrast-color(). Each is a progressive enhancementProgressive enhancementBuild the accessible baseline first, then layer richer behavior on top where the browser supports it — so missing support means a plainer page, never a broken one.: where your browser supports it you get the richer version; where it doesn't you get an accessible fallback, not a broken page. New features extend the baseline here — they never replace it.

What that means in practice

View source: the argument is in the HTML. 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.

It's a demo, not a dependency. This is a playground for showing how the modern web platform answers accessibility natively, with little to no JavaScript — made to be explored and learned from, not installed into a production app.

Some showcases want a recent browser. The demos under “Limited availability” use features still landing across engines. On an older browser they quietly fall back to a simpler, still-usable form — that degradation is the design, not a defect.

Tested where it counts. Verified against current Chrome, Firefox, and Safari, with a keyboard, forced-colours mode, and the reduced-motion and reduced-transparency preferences.

Found a barrier? Accessibility work is never finished. If something gets in your way, open an issue — that feedback is welcome and acted on.

Built by Thomas Sweet — a front-end developer sharpening an accessibility-first craft in the open, one experiment at a time. This whole site is the sketchbook. ☕

ProjectAccessible by default© 2026
TitleIndex
Drawn byThomas Sweet
Scale1:1
Sheet00