Accessibility tools that suggest the fix
A small WCAG 2.2 toolkit, designed and built by me. Free, public, and used in my own lessons.
- Problem
- Accessibility checkers say that something fails, not how to fix it without breaking the design.
- My role
- Designer and developer, solo.
- Team and time
- Solo · 2026
- Delivered
- Five free, public tools: contrast, fluid type, colour blindness, touch targets and moving backgrounds.
- Result
- Used in my own lessons. No cookies and no tracking.
| Type | Interaction design · accessibility · front-end |
|---|---|
| Year | 2026 |
| Built with | HTML, CSS, JavaScript, OKLCH and OKLab colour models |
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.
Every failure comes with a fix.
-
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.
Five free, public tools.
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.