Accessibility Color Analyzer
Test every combination of a colour palette at once. Enter your colours with names and the analyzer builds a contrast matrix of each colour as text on every other colour, rates each pair for normal text, large text and UI components at WCAG AA or AAA, suggests the nearest shade that passes for text on your lightest and darkest backgrounds, and simulates protanopia, deuteranopia and tritanopia to find colour pairs that become hard to tell apart.
- Runs in your browser
- No sign-up
- Free to use
Everything is calculated in your browser with the WCAG 2.2 relative-luminance formula. Colour-vision simulations use the Machado, Oliveira & Fernandes (2009) model.
How to use Accessibility Color Analyzer
- Enter your palette, one colour per line.
- Choose AA or AAA.
- Read the contrast matrix and suggestions.
- Check the colour-blindness results.
Accessibility Color Analyzer features
Contrast matrix
Every text/background pair.
AA and AAA
4.5:1, 3:1, 7:1 thresholds.
Nearest passing shade
Same hue, adjusted lightness.
Colour-blindness
Machado 2009 simulation.
Confusable pairs
Measured with CIE Lab ΔE.
Private
Calculated in your browser.
When to use Accessibility Color Analyzer
- Design systems and brand palettes.
- UI component libraries.
- Charts and data visualisation colours.
- Accessibility reviews.
Accessibility Color Analyzer FAQ
What contrast does text need?
WCAG AA: 4.5:1 for normal text, 3:1 for large text (24 px or 18.66 px bold). AAA: 7:1 and 4.5:1.
What about buttons and icons?
UI components and graphical objects need 3:1 against adjacent colours (WCAG 1.4.11).
How accurate is the colour-blindness simulation?
It uses the widely used Machado et al. model at full severity; real perception varies.
Can I use colour alone for errors?
No – WCAG 1.4.1 requires another cue such as text or an icon.
A palette that works for everyone
About 1 in 12 men and 1 in 200 women have a colour-vision deficiency, and many more people read screens in bright sunlight. Checking the palette once prevents contrast problems in every component.
How it works: a URL is fetched once by our server through a guarded client that only connects to public addresses; the HTML (and, where needed, the stylesheets) is then analysed in your browser as inert text – scripts on the page never run. Pasted HTML is analysed without any request. Nothing is stored.
Automated testing has limits: tools can reliably find missing names, invalid ARIA, broken references, skipped headings and similar code problems, but roughly two thirds of WCAG criteria need human judgement – whether alt text is meaningful, whether focus order makes sense, whether content is understandable. Every result says what still needs manual testing.
The checks follow WCAG 2.2 and WAI-ARIA 1.2, the standards behind the European Accessibility Act, the Americans with Disabilities Act guidance, Section 508 and EN 301 549. Each finding names the success criterion so you can look it up and include it in a report or ticket.
Related tools on this site cover the rest of an accessibility review: the HTML accessibility checker, WCAG contrast checker, accessibility colour analyzer, keyboard navigation checker, ARIA validator, alt text generator, heading structure checker and the accessibility statement generator.
Who it is for: front-end developers checking a release, designers reviewing a component library, content editors, QA testers and agencies preparing accessibility audits for clients. No account, plugin or installation is needed.