How a single accessibility oversight in a medical dashboard could cost a life — and what the Paul Tol colour scheme taught me about designing for the 8%
There is a specific kind of design failure that never shows up in usability tests. It does not cause a crash. It does not trigger an error message. The interface loads perfectly, the buttons work and the animations are smooth. But somewhere in the room, a dispatcher stares at a screen full of incident cards: red ones, green ones, amber ones and sees something entirely different from what you designed.
For approximately 8% of men and 0.5% of women, red and green are not opposites. They are the same brownish-yellow blur. And in an emergency dispatch system where red means cardiac arrest and green means stable patient, that is not a design inconvenience. It is a clinical risk.
I spent time recently working through the UI architecture of a medical dispatch dashboard, the kind of system a dispatcher uses to triage incoming emergencies, allocate paramedic units and monitor patient vitals in real time. The system needed to communicate severity at a glance. And like almost every dashboard I have seen in this space, the initial design used colour as the primary and only channel for that communication.
This is the story of why that was wrong and what I did about it.
The Problem with Colour-Only Communication
WCAG 2.1 Success Criterion 1.4.1 (Web Content Accessibility Guidelines) is one of the most frequently violated accessibility guidelines in existence. It states, plainly, that colour must not be used as the only visual means of conveying information.
Most designers know this in the abstract. Few apply it rigorously.
In a standard consumer app, violating 1.4.1 means a colourblind user might miss a sale badge or misread a chart. In a medical dispatch system, it means a dispatcher with deuteranopia, the most common form of red-green colour blindness might look at a triage card marked T-1 Critical and perceive it with the same visual weight as a Stable patient two cards below it.
The stakes are not equivalent to a misread pie chart.
The original dashboard used four semantic colours:
Colour palette — original
Every incident card, status badge, and severity strip used these colours as its sole differentiator. A critical cardiac arrest had a red left strip. A stable asthma case had a green one. The visual hierarchy was entirely chromatic.
For a dispatcher with deuteranopia, the red and green strips are perceptually identical.
Understanding the Three Types of Colour Vision Deficiency
Before building a solution, I needed to understand what I was actually solving for. Colour vision deficiency is not one condition, but it is several, each affecting colour perception differently.
Deuteranopia is the most common variant, affecting roughly 6% of men. It involves reduced sensitivity to green light. The classic red-green confusion: traffic lights, danger indicators, health bars in video games. Most people when they imagine colour-blindness are imagining deuteranopia.
Protanopia is less common (around 2% of men) and involves the complete absence of red-light receptors. Where deuteranopia causes red and green to blur together, protanopia causes red to effectively disappear, becoming very dark, nearly black. A bright red alert card becomes a dark grey card. The urgency signal vanishes entirely.
Tritanopia is rare (less than 0.01% of the population) and affects blue-yellow discrimination. It is less relevant for most UI work but still present, and a complete accessibility solution should address it.
In aggregate, these conditions affect a significant enough portion of the population that in any shift of dispatchers across a regional emergency service, statistically, at least one person in the room will have some form of colour vision deficiency.
The Paul Tol Colour Scheme
The standard approach to accessible colour in data visualisation and scientific UI is not widely known outside specialist circles. It is the work of Paul Tol, a scientist at SRON (the Netherlands Institute for Space Research), who spent years developing colour palettes that remain perceptually distinct across all forms of colour vision deficiency.
Tol’s palettes are not simply “colourblind-friendly” in the vague marketing sense that some design tools use. They are mathematically verified against simulation models of each deficiency type, tested for distinguishability across all three major variants, and designed to maintain adequate contrast ratios under each condition.
I adapted three of Tol’s palettes for the dispatch system:
Deuteranopia palette:
Deuteranopia palette
The key insight here is that orange and teal are perceptually opposite even when red and green are not. A dispatcher with deuteranopia sees orange and teal as clearly as a person with standard vision sees red and green.
Protanopia palette:
Protanopia palette
Tritanopia palette:
Tritanopia palette
Each palette was built as a named style collection in the design system, meaning a single settings toggle could propagate the entire palette change across every component simultaneously. Change the collection, every card, badge, strip and button updates instantly.
The Shape Indicator Problem
Swapping colour palettes addresses the chromatic discrimination problem. But it does not fully solve the communication problem.
Consider a dispatcher who has been using the system for three years. Their eyes have learned to scan the left strips of incident cards before reading the text — a subconscious pattern recognition that experienced dispatchers develop. Colour is not just a label for them; it is a pre-attentive signal that triggers action before conscious reading begins.
If you change the palette, you disrupt that learned pattern. The dispatcher who learned that red-strip-means-reach-for-the-dispatch-button now has to relearn the association with a new colour.
The more robust solution is redundant encoding — communicating the same information through multiple simultaneous channels so that disrupting any one channel does not break the signal.
For the dispatch system, this meant adding shape indicators alongside the colour strips:
These appear as small icons at the top of each severity strip, visible in all colour modes. A dispatcher with any form of colour vision deficiency can identify severity through shape alone. A dispatcher with standard vision gets both channels simultaneously, which actually speeds up pattern recognition compared to colour alone.
This approach follows the Universal Design principle of providing multiple means of representation — designing not for the average user but for the full range of users, so that no single accessibility accommodation creates a worse experience for anyone else.
The Settings Panel Architecture
The practical implementation required a settings panel with four selectable palettes and a toggle for the shape indicator mode.
The palettes were built as component properties rather than hardcoded styles. Each component in the library, incident cards, unit cards, status badges, alert banners referenced a semantic colour token rather than a raw hex value.
Changing the active palette in settings updated the token values, which propagated instantly to every component using those tokens. No manual overrides. No hunting through layers to find every red rectangle.
This is the practical argument for semantic design tokens that most design system tutorials describe in the abstract. Here is the concrete case, you cannot retrofit accessibility into a design system that uses raw hex values. You can only build it in from the start, at the token level.
The settings panel offered four options displayed as small colour swatches, the actual palette colours rendered as 12×12px squares, labelled with the deficiency type they address. A dispatcher could select their palette once during onboarding and never think about it again.
The shape indicator toggle was separate, defaulting to off for users with standard vision and on for users who had selected an accessible palette. The logic: if you have selected an accessible palette, you have indicated a need for additional accommodation, and the shape indicators provide that second channel.
What This Changes About How I Think About Colour
The most valuable thing this work surfaced is not a technique. It is a reframing.
Colour in UI design is almost universally treated as an aesthetic decision with some functional implications. You choose your brand colour, you apply it to primary buttons, you use semantic colours for feedback states, and you run your design through a contrast checker to confirm you have met WCAG AA ratios.
That framing positions accessibility as a compliance exercise — something you check at the end to make sure you have not failed a test.
The reframing that emergency dispatch design forces is this. C olour is a communication channel, and like any communication channel, it can fail. Signal loss, interference, receiver variation. When a communication channel fails in a consumer app, users are mildly frustrated. When it fails in an emergency dispatch system, the consequences cascade outward in ways no post-launch patch can undo.
Designing for colour vision deficiency from the architecture level, semantic tokens, redundant encoding, palette switching is not about making your design accessible to a minority. It is about making your communication robust to failure. Every designer working on interfaces where decisions matter should be thinking this way.
The 8% is not an edge case. It is a signal that your communication architecture has a single point of failure.
Practical Starting Points
If you are working on a data-dense UI and want to apply these ideas:
Start with the Paul Tol technical note. It is available at Paul Tol’s Notes and provides ready-to-use palettes with simulation data for each deficiency type. It is more rigorous than anything produced by the mainstream design tools.
Audit your semantic token usage. Every colour in your system should be reachable through a named token with a semantic meaning. If you have raw hex values in your components, you cannot switch palettes at scale.
Test with a simulation tool before building. Figma has a built-in colour blindness simulator under View → Accessibility Settings. Run every key screen through Deuteranopia and Protanopia modes before finalising your palette. What looks clearly differentiated in standard vision often collapses immediately in simulation.
Add shape or pattern as a second channel for any colour that carries meaning alone. This does not require visual noise. A small geometric icon in a corner, a border pattern change, a subtle texture, any secondary channel reduces your single point of failure.
Make accessibility a setting, not an override. A palette switcher in settings is more respectful than a separate accessibility mode that users have to enable because the default experience was not designed for them.
The dispatcher who sat down at a terminal and saw a screen of incident cards that all looked the same colour, they did not file a bug report. They adapted. They read the text labels more carefully. They developed workarounds. They did their job.
They always do.
That is not a reason to keep designing systems that require adaptation. It is a reason to be more precise about what we are actually asking people to work around.
If you found this useful, the Paul Tol colour scheme technical note is the single best resource I have found for accessible data visualisation colour. For Figma-specific implementation, the combination of semantic tokens and component properties is the architecture that makes palette switching feasible at scale.
Top comments (1)
Have you tested whether the shape indicators remain distinguishable at small sizes and under fast scanning? Redundant encoding only helps if the silhouettes stay clearly separable.