(Case 03)
Interaction design · Accessibility · Front-end
Accessibility tools that fix, not just flag
A small WCAG 2.2 toolkit, designed and built by me. Free, public, and used in my own lessons.
| Type | Interaction design · accessibility · front-end |
|---|---|
| Year | 2026 |
| My role | Designer & developer (solo) |
| Built with | HTML, CSS, JavaScript, OKLCH and OKLab colour models |
(Challenge)
Teaching accessibility
Checkers say that it fails, not how to fix it.
I teach accessibility to design and front-end students. Most checkers tell you that something fails, not how to fix it without breaking your design. Students then darken a brand colour until it turns muddy grey, or ignore the warning altogether. I wanted tools that teach while they check.
(Decisions)
Five choices
Fix, don’t just flag.
-
Suggest the fix
When a colour pair fails, the contrast checker suggests the nearest passing tints of your own colour.
-
Perceptual colour
Only lightness changes, in OKLCH. Hue and colourfulness stay intact, unlike in HSL.
-
Show, don’t tell
Touch targets at real size, with 3× zoom and the dashed 24 px WCAG circles.
-
Explain the why
Every tool names the WCAG criterion, who it helps, and gives CSS you can copy.
-
Practise what it preaches
No cookies, no tracking, runs in the browser, and a rule of thumb without JavaScript.
(Outcome)
Five tools
Five free, public tools.
(Reflection)
What I learned
Accessibility as a design material.
Accessibility is often treated as a checklist at the end of a project. These tools try to move it to the start, as a design material instead of a constraint.