Color, contrast, and motion

The problem: a UI that only works for perfect eyes

Picture a team shipping a new checkout page. The designer picked a soft gray for helper text, #999999 on white, because it looks calm. Form errors show as a red border and nothing else. A success toast slides in from the side with a springy bounce.

The layout was tested on a 1440 px wide laptop at 100% zoom. Every screen reader test passes, every button is reachable by keyboard.

Then real people use it. A 68-year-old customer with age-related low vision cannot read the helper text: the gray has a contrast ratio of about 2.85:1 against white, well under the 4.5:1 minimum. A customer with red-green color blindness (about 1 in 12 men of Northern European descent) cannot tell which field has an error, because the red border looks the same as the gray one.

A customer who zooms to 400% to read gets a page that scrolls both ways, so every line of text needs a sideways scroll to finish. A customer with a vestibular disorder (an inner ear condition where on-screen motion can cause dizziness and nausea) feels sick from the bouncing toast. A customer on Windows with a high contrast theme sees the custom checkboxes vanish, because they were drawn with background colors that the theme throws away.

What visual accessibility covers

None of these bugs show up in a screen reader test or a keyboard test. They are visual accessibility problems: problems with how the page looks and moves for people who see differently, or who changed their system settings to see better. This lesson covers them in six groups.

• Contrast: is text and every meaningful shape different enough in lightness from what sits behind it? (WCAG 1.4.3, 1.4.6, 1.4.11)
• Color alone: is any meaning carried only by hue, like red for error and green for success? (WCAG 1.4.1)
• Zoom and reflow: does the page still work at 200% text size, at 400% zoom, and with wider letter and line spacing? (WCAG 1.4.4, 1.4.10, 1.4.12)
• Target size: are buttons and links big enough to hit with a shaky hand? (WCAG 2.5.8)
• Motion: does the page respect people who asked the system to reduce motion? (prefers-reduced-motion, WCAG 2.3.3)
• User themes: does the page survive dark mode, a request for more contrast, and the forced colors of Windows high contrast? (prefers-color-scheme, prefers-contrast, forced-colors)

WCAG, the Web Content Accessibility Guidelines from the W3C, is the standard most laws point to. Version 2.2 (October 2023) is current. Each rule is a numbered success criterion with a level: A is the floor, AA is what laws and contracts usually require, AAA is stricter and used for specific content. When this lesson says "AA", it means the level most products must meet.

The good news: almost all of it is cheap if you design it in. Contrast is a token decision, made once in the design system. Reflow comes from a responsive layout you already need for phones. Motion and themes are a few media queries.

The expensive path is retrofitting after launch, page by page. The rest of this lesson shows how each piece works, how to check it with numbers, and how to talk about it in a system design interview.

The mental model: lightness carries the information, the user holds the dial

Keep two ideas in your head for the whole lesson. The first: the eye reads shapes from lightness, not from hue. The second: the user, not the designer, has the final say on size, color, and motion. Almost every rule below follows from one of these.

Idea 1: lightness, not hue

Your visual system splits what the eye sees into a lightness signal and two color-difference signals (red against green, blue against yellow). The lightness signal carries the fine detail you use to see edges, letters, and shapes. The color signals carry less detail, and they are the part that differs in color blindness. So text is readable when its lightness differs enough from the background, almost no matter what the hues are.

A quick test makes this concrete: convert a screenshot to grayscale. Whatever is still readable has enough lightness contrast. Pure red #ff0000 on pure green #00ff00 looks loud in color, but in grayscale both turn into similar mid-grays, and the measured ratio is only 2.91:1. Black on mid-gray #808080 looks dull, yet it measures 5.32:1 and reads fine.

This is why the WCAG contrast formula ignores hue entirely. It converts each color to one number, its relative luminance (how much light it gives off, from 0 for black to 1 for white, weighted by how sensitive the eye is to each channel), and compares the two numbers. It is also why "don't use color alone" is a separate rule: if two states differ only in hue, the lightness channel sees no difference.

Idea 2: the user holds the dial

Your design is a suggestion. The person on the other side can zoom the page to 400%, raise the default font size, override line spacing with a browser extension, switch the OS to dark mode, ask for more contrast, ask for less motion, or turn on a forced color theme that replaces every color you chose. Each of these is a setting real people rely on every day.

Think of your UI as a recipe, not a photograph. A photograph has one fixed size and fixed colors. A recipe says "text in the body color, with this much contrast, on the surface color, wrapping to fit", and the browser cooks it for whatever kitchen it lands in. Code that fixes heights in pixels, draws meaning with background images, or plays animation no matter what is a photograph: it breaks as soon as the user turns a dial.

How the contrast ratio is computed, step by step

The WCAG contrast ratio compares the relative luminance of two colors. It runs from 1:1 (the same color twice) to 21:1 (black on white). The formula is short, and every frontend engineer should be able to write it from memory, because it explains why some colors that look fine fail and others that look dull pass.

The four steps

1. Split the color into channels and scale each to 0 to 1: #767676 is red, green, and blue all equal to 118, so each is 118 / 255 = 0.463.
2. Undo the sRGB gamma to get linear light. Screens store values on a curve so that dark tones get more of the 256 steps. For a channel value c: if c is at most 0.04045, linear = c / 12.92; otherwise linear = ((c + 0.055) / 1.055) raised to the power 2.4. For 0.463 that gives 0.181.
3. Weight and add the channels: L = 0.2126 R + 0.7152 G + 0.0722 B. Green counts most because the eye is most sensitive to it, blue least. For a gray all three are 0.181, so L = 0.181.
4. Compare: ratio = (L lighter + 0.05) / (L darker + 0.05). White is L = 1, so #767676 on white is 1.05 / 0.231 = 4.54:1.

The + 0.05 in step 4 stands for flare: the light reflected off a real screen in a real room. It stops the ratio from going to infinity for pure black and is why the maximum is 21: (1 + 0.05) / (0 + 0.05) = 21.

// contrast.mjs: run with `node contrast.mjs`
const linear = (c8) => {
  const c = c8 / 255;
  return c <= 0.04045 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4;
};

export function luminance(hex) {
  const [r, g, b] = [1, 3, 5].map((i) => linear(parseInt(hex.slice(i, i + 2), 16)));
  return 0.2126 * r + 0.7152 * g + 0.0722 * b;
}

export function contrast(a, b) {
  const [hi, lo] = [luminance(a), luminance(b)].sort((x, y) => y - x);
  return (hi + 0.05) / (lo + 0.05);
}

console.log(contrast("#767676", "#ffffff").toFixed(2)); // 4.54
console.log(contrast("#777777", "#ffffff").toFixed(2)); // 4.48
console.log(contrast("#ff0000", "#ffffff").toFixed(2)); // 4.00 (3.998 before rounding)
console.log(contrast("#000000", "#ffffff").toFixed(2)); // 21.00

Worked examples you will meet in real design systems

Here are colors you see every day, measured with the code above. Notice how close the pass and fail colors are. #767676 passes at 4.54:1 and #777777, one step lighter, fails at 4.48:1. You cannot judge this by eye, and you should never round up: 4.48 is a fail.

Try it yourself in the lab below. Pick any two colors and a text size, and watch which levels pass. Then switch to the simulated forced colors view to see that, in that mode, your colors stop mattering: the user's palette decides the contrast, and what matters is whether your shapes survive.

Two patterns stand out. First, saturated mid-tone colors like red-500 and green-600 with white text tend to land between 3 and 4.5: fine for big bold labels, failing for normal button text. Going one shade darker almost always fixes it. Second, the light grays used for input borders and dividers (around 1.3:1) fail the 3:1 rule for UI components, which the next chapter explains.

The contrast rules in detail: text, large text, UI, and what is exempt

WCAG has three contrast criteria. Knowing exactly what each covers, and what it does not, is the difference between a vague "make it accessible" and a review you can act on.

What counts as large text

Large text is at least 18 point, or at least 14 point and bold. In CSS that is about 24px regular, or about 18.66px bold (1 point is 4/3 of a CSS pixel). Large letters have thicker strokes, so they stay readable with less contrast. A common mistake is to treat 18px regular as large: it is not, so 18 px body copy still needs 4.5:1.

Weight matters only from bold up, which means font-weight: 700 or heavier. A 600 semibold at 16 px is normal text. Thin weights (300 and below) are not exempted by anything, yet they read worse than the formula suggests, so treat 4.5:1 as the floor for them, not the goal.

Non-text contrast: the 3:1 rule for controls and graphics

Criterion 1.4.11 asks that anything you need to see to use a control has 3:1 against what is next to it. That covers the border of a text input when the border is the only thing showing where the field is, a checkbox outline, the thumb of a slider, the focus indicator, and the checked state of a toggle. It also covers parts of charts and icons that carry meaning, like the lines of a line chart or a standalone icon button.

• Input borders: a #e5e5e5 border on white is 1.26:1 and fails if the border is the only cue. Either darken it (a #767676 border passes easily) or give the field a filled background that itself has 3:1 against the page.
• Buttons: a button whose text is readable but whose shape is invisible is fine. The text is what identifies it. An icon-only button has no text to identify it, so the icon itself needs 3:1 against the background.
• States: the difference between checked and unchecked, on and off, selected and not selected must be visible at 3:1. A toggle that changes from light gray to slightly darker gray fails.
• Focus rings: covered here and, more strictly, by 2.4.13 Focus Appearance (AAA). The keyboard navigation lesson covers 2.4.7 and 2.4.11 for focus that is visible and not hidden.

What is exempt, and what people wrongly think is exempt

Real exemptions: text in a logo or brand name, text that is purely decorative or not visible to anyone, and text in an inactive (disabled) control. Photos where text is incidental, like a street sign in a picture, are exempt too.

Not exempt: placeholder text (if it shows information, it must meet 4.5:1, and it should not be the only label anyway), helper text and captions in small gray, text over images or gradients (measure against the worst spot behind the text), and the hover or focus state of a control. Disabled controls being exempt is also a reason to avoid them: a user who cannot read why the Submit button is gray is stuck. Prefer an enabled button that explains what is missing.

APCA: a possible future, not today's rule

The WCAG 2 formula has known weak spots. It is too strict for some white text on saturated mid-tones like orange and too lenient for some dark-on-dark pairs, and it ignores font size and weight beyond the one large-text switch. APCA, the Accessible Perceptual Contrast Algorithm, is a newer model that gives a lightness contrast value (Lc) depending on which color is the text and which is the background, and pairs it with font size and weight lookup tables.

APCA has been discussed as a candidate for WCAG 3, which is still an early working draft with no settled contrast method and no date. Laws and audits in 2025 and 2026 reference WCAG 2.1 or 2.2, so the 4.5:1 and 3:1 rules are what you must meet. A sensible position: pass WCAG 2 for compliance, and use APCA as an extra check for dark themes and thin fonts where WCAG 2 is known to mislead.

Never color alone: meaning that survives grayscale

Criterion 1.4.1 Use of Color (level A, the floor) says color must not be the only way to convey information, show an action, ask for a response, or tell elements apart. Color can still be used, and it helps most people. It just needs a second cue: text, an icon, a shape, a pattern, position, or an underline.

Who cannot rely on hue

• Red-green color vision deficiency (protan and deutan types): about 8% of men and 0.5% of women of Northern European descent. Reds, greens, oranges, and browns can look alike.
• Blue-yellow deficiency (tritan): rare, often estimated at around 1 in 10,000 people or fewer, but it confuses blue with green and yellow with pink.
• Low vision and aging eyes: yellowing of the lens with age makes blues and greens harder to tell apart.
• Situations: a phone in bright sun, a cheap projector, a grayscale e-ink reader, a printed page, a night-shift filter that turns the screen orange.
• Forced colors and screen readers: in forced colors your hues are replaced; a screen reader never hears the color at all.

The common failures and their fixes

The link rule is worth a closer look. WCAG technique G183 allows links without underlines if the link color has 3:1 contrast with the surrounding body text and the link gets a non-color cue like an underline on hover and on keyboard focus. That is hard to meet with the text itself also at 4.5:1 against the background, so the simplest choice is to keep underlines on links inside paragraphs. Navigation menus and buttons are fine without them, because their position and shape already say they are interactive.

Note how this rule ties to the screen reader lesson. A second cue that is visible text, like "Failed", also gives the screen reader something to read. An icon alone is not enough for a screen reader: it needs an accessible name (aria-label, or visually hidden text) or it must be marked decorative next to real text. One fix serves both groups when you choose text first.

Zoom, reflow, text spacing, and target size

People with low vision mostly do not use a screen reader. They make things bigger. This chapter covers the four rules that make bigger work: resize text, reflow, text spacing, and target size.

1.4.4 Resize Text and 1.4.10 Reflow

1.4.4 Resize Text (AA) says text must scale to 200% with no lost content or features, using only the browser. 1.4.10 Reflow (AA, added in WCAG 2.1) goes further: at a width of 320 CSS pixels, content must fit without scrolling in two directions. Vertical scrolling is fine; a sideways scroll to read each line is not.

Why 320? Browser zoom makes every CSS pixel bigger, so the viewport gets narrower in CSS pixels. A 1280 px wide window at 400% zoom is 1280 / 4 = 320 CSS px wide, the same as a small phone.

Your media queries fire exactly as they would on that phone. That is the key insight: if your layout is truly responsive down to 320 px, reflow at 400% comes almost for free.

For content that scrolls sideways by design, like a horizontal carousel or a vertical-text language, the rule applies to height instead: 256 CSS px. Some content is allowed to need two dimensions: maps, large data tables, diagrams, video, games, and toolbars that must keep their layout. A data table may scroll sideways inside its own container, but the page around it must not.

• Fixed widths: width: 960px on a wrapper forces sideways scrolling. Use max-width with fluid inner widths.
• Fixed heights with text: height: 48px on a box with text clips or overlaps the text once it wraps. Use min-height and padding.
• Sticky headers and footers: at 400% on a laptop the viewport is about 180 to 250 CSS px tall. A 64 px sticky header plus a 56 px cookie bar can cover half of it. Make them static, or shrink them, below a height breakpoint (@media (max-height: 400px)).
• Disabling zoom: maximum-scale=1 or user-scalable=no in the viewport meta tag can block pinch zoom on mobile. Leave both out.
• Text in px only: browser zoom still scales px, but the default font size setting does not. Size text in rem so both dials work.

/* Fluid layout that reflows to one column at narrow widths */
.page {
  max-width: 72rem;
  margin-inline: auto;
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(18rem, 100%), 1fr));
  gap: 1.5rem;
}

/* Let long words and URLs wrap instead of pushing the page wide */
.prose { overflow-wrap: anywhere; }

/* Short viewports (400% zoom on a laptop): stop the header from sticking */
@media (max-height: 25rem) {
  .site-header { position: static; }
}

1.4.12 Text Spacing

Many people with dyslexia or low vision read better with more space. 1.4.12 Text Spacing (AA) says nothing may be lost when a user sets: line height to 1.5 times the font size, paragraph spacing to 2 times the font size, letter spacing to 0.12 times, and word spacing to 0.16 times. You do not have to ship these values; you have to survive a user style sheet or extension that applies them.

What breaks: buttons and tabs with a fixed height and overflow: hidden, badges with fixed widths, and truncated text with text-overflow: ellipsis that now hides the important word. To test it, paste a small bookmarklet that sets the four values with !important on every element, then look for clipped or overlapping text.

2.5.8 Target Size (Minimum)

WCAG 2.2 added 2.5.8 Target Size (Minimum) at level AA: pointer targets must be at least 24 by 24 CSS px. People with tremors, arthritis, or limited dexterity, and anyone on a bumpy bus, miss small targets. The stricter 2.5.5 (AAA) asks for 44 by 44, which matches Apple's long-standing touch guidance.

• Spacing exception: a smaller target passes if a 24 px circle centered on it does not overlap any other target or the circle of another small target. In practice, a 16 px icon button with enough empty space around it can pass.
• Inline exception: links inside a sentence are exempt, since their size comes from the text.
• Equivalent and essential: exempt if another control on the page does the same thing at full size, or the size is essential (like pins on a map).
• User agent controls: default browser checkboxes and radios are exempt, but once you style them yourself the rule applies.

Motion: prefers-reduced-motion and vestibular disorders

Motion on screen can make people physically ill. With a vestibular disorder, the inner ear's sense of balance is affected, and large on-screen movement that the body does not feel creates a mismatch. The result can be dizziness, nausea, or a migraine that lasts hours.

Concussion, inner ear infections, and some migraine conditions cause the same sensitivity. Motion also distracts people with attention disorders and can slow readers with cognitive disabilities.

What kind of motion is the problem

Not all animation is equal. A 150 ms color fade on a button is harmless. The triggers are motion that covers a large part of the view or moves in a way the eye reads as the world moving:

• Parallax scrolling: background and foreground moving at different speeds.
• Large zoom and scale: a page transition that zooms the whole view in or out.
• Scroll-jacking: the page scrolls at a different speed or direction than the wheel.
• Spinning and wobbling: rotating hero graphics, shaking error fields, bouncing elements.
• Auto-playing background video and long looping animations.

The media query and the OS settings behind it

Every major OS has a switch: Reduce motion on macOS and iOS, Animation effects off on Windows, Remove animations on Android. Browsers expose it as the media feature prefers-reduced-motion, with the values reduce and no-preference. It is supported in all current browsers.

The safest pattern is motion as an opt-in: write the static version by default, and add the motion inside a no-preference query. If the query is unknown or the user asked for less, they get the calm version.

/* Default: no slide, just appear */
.toast { opacity: 1; }

@media (prefers-reduced-motion: no-preference) {
  .toast { animation: slide-in 300ms ease-out; }
  html { scroll-behavior: smooth; }
}

/* Reduced: swap the movement for a short fade instead of dropping all feedback */
@media (prefers-reduced-motion: reduce) {
  .toast { animation: fade-in 150ms linear; }
}

const query = window.matchMedia("(prefers-reduced-motion: reduce)");

function scrollToResult(el) {
  el.scrollIntoView({ behavior: query.matches ? "auto" : "smooth", block: "start" });
}

// The user can flip the setting while the page is open
query.addEventListener("change", () => carousel.setAutoplay(!query.matches));

Some teams add a global reset under reduce that sets animation-duration and transition-duration to 0.01ms !important on every element. It is a decent safety net, and the tiny duration (not zero) matters: a transition of zero length never runs, so its transitionend event never fires and code waiting on it would hang. It is not a design: it also kills harmless fades and spinners that tell the user something is loading. Use it as a backstop, then design reduced versions of the motions that matter.

The WCAG criteria for motion

2.3.3 is AAA, so it is not in most legal targets. Still, honoring prefers-reduced-motion is the way you meet it, it costs a few lines, and the people who turned the setting on did it for a reason. Treat it as required in any modern design system.

User themes: dark mode, more contrast, and forced colors

Three media features tell you how the user wants colors handled. They are different in kind. prefers-color-scheme and prefers-contrast are preferences: you decide how to respond. forced-colors is a fact: the browser has already replaced your colors, and your job is to make sure nothing important disappears.

prefers-color-scheme and dark mode contrast

prefers-color-scheme is light or dark, following the OS setting. Many people with light sensitivity, migraine, or some eye conditions read far better on dark surfaces; others, including some people with astigmatism, find light text on black blurrier. That is why it should follow the user, with a manual override in settings.

The accessibility trap: a dark theme is a new set of color pairs, and each one needs checking again. Brand blue #2563eb is 5.17:1 as a white-text button on light, but as link text on a #121212 surface it is only 3.62:1, a fail. A lighter blue like #60a5fa reaches 7.37:1 there.

Gray text is the same story: #6b7280 on a near-black #111827 is 3.67:1, while #9ca3af is 6.99:1. Shadows also vanish on dark surfaces, so elevation needs lighter surfaces or borders instead.

:root {
  color-scheme: light dark;   /* native controls and scrollbars follow too */
  --surface: #ffffff;
  --text: #111827;            /* 17.74:1 on surface */
  --text-muted: #6b7280;      /* 4.83:1 */
  --link: #1d4ed8;            /* 6.70:1 */
}

@media (prefers-color-scheme: dark) {
  :root {
    --surface: #121212;
    --text: #e0e0e0;          /* 14.19:1, softer than pure white */
    --text-muted: #9ca3af;    /* 7.38:1 */
    --link: #60a5fa;          /* 7.37:1 */
  }
}

prefers-contrast

prefers-contrast reports more, less, custom, or no-preference. On macOS and iOS, the Increase contrast setting makes it more. A good response is small and targeted: darken muted text to the body color, make faint borders solid, drop translucent backgrounds, and thicken focus rings. You do not need a third full theme; a few overrides on the tokens are enough.

@media (prefers-contrast: more) {
  :root {
    --text-muted: var(--text);
    --border: currentColor;
    --focus-ring-width: 3px;
  }
  .glass-panel { backdrop-filter: none; background: var(--surface); }
}

Forced colors mode (Windows contrast themes)

Windows contrast themes (once called High Contrast Mode) let users pick a tiny palette, often white or yellow text on black, or black on white. Chromium browsers and Firefox on Windows then apply forced colors: they override color, background-color, border-color, outline-color, text decoration colors, and SVG fill and stroke with a few system colors.

They also remove box-shadow, text-shadow, and gradient backgrounds. Images loaded by URL stay as they are. The media query forced-colors: active tells you it is on, and prefers-color-scheme switches to match the lightness of the user's background.

What disappears is anything drawn only with a background color or a shadow: a custom checkbox whose check is a colored square, a toggle whose state is a background change, a focus ring made with box-shadow, an icon drawn as a CSS mask filled by background-color (it turns into the page color), a selected tab marked only by a tinted background. Things drawn with borders, outlines, text, and currentColor survive.

Two more details: the browser draws a solid backplate behind text so it stays readable over images, and it picks system colors from native HTML semantics, so a div with role="button" gets text colors, not button colors.

/* Focus ring drawn with box-shadow: add a transparent outline as a fallback.
   Transparent is invisible normally, but forced colors paint it in a system color. */
.button:focus-visible {
  box-shadow: 0 0 0 3px #1d4ed8;
  outline: 2px solid transparent;
}

.icon { fill: currentColor; }        /* follows the forced text color */

@media (forced-colors: active) {
  .switch[aria-checked="true"] .thumb { background: Highlight; }
  .tab[aria-selected="true"] { border-bottom: 3px solid Highlight; }
  .swatch { forced-color-adjust: none; } /* a color picker must show real colors */
}

forced-color-adjust: none opts an element out, so it keeps your colors. Use it only where the real color is the content, like a color swatch, a product photo frame, or a chart legend key, and never on whole components: you would be undoing a choice the user made because they need it. Test with Chrome DevTools: Rendering, then Emulate CSS media feature forced-colors. On a real Windows machine, try at least one dark and one light contrast theme.

At scale: design tokens, CI checks, and what breaks in production

A product with 400 screens cannot be fixed one color at a time. Visual accessibility scales when it lives in the design system: a small set of tested tokens and components that every screen uses. The goal is that a product engineer cannot easily build a failing pair, because the only colors on offer are pairs that pass.

Three layers of tokens

1. Primitive tokens: the raw palette, like blue-600: #2563eb. Nobody uses these in components.
2. Semantic tokens: roles, like text-default, text-muted, surface, border-control, focus-ring, danger-text. Each has a light value, a dark value, and optionally a more-contrast value.
3. Component tokens: only where a component needs its own, like button-primary-bg, pointing at semantic tokens.

Contrast is a property of a pair, so the system should list the pairs that are allowed: text-muted on surface and on surface-raised, danger-text on surface and on danger-bg, and so on. A unit test then computes every allowed pair in every theme with the formula from chapter 3 and fails the build under 4.5:1 for text roles and 3:1 for UI roles. This catches the dark mode bug where someone changes one surface color and silently breaks ten pairs.

import { contrast } from "./contrast.mjs";
import { themes, pairs } from "./tokens.mjs";

// pairs: [{ fg: "text-muted", bg: "surface", min: 4.5 }, { fg: "border-control", bg: "surface", min: 3 }]
for (const [name, t] of Object.entries(themes)) {
  for (const { fg, bg, min } of pairs) {
    const ratio = contrast(t[fg], t[bg]);
    if (ratio < min) {
      throw new Error(`${name}: ${fg} on ${bg} is ${ratio.toFixed(2)}, needs ${min}`);
    }
  }
}

Failure modes that slip through

The theme flash deserves a picture, because it is a timing bug. If the theme is chosen by JavaScript in your app bundle, the browser has already painted the light page by the time the bundle runs. The fix is to make the decision before the first paint.

Automated tools catch only part of this. axe and Lighthouse compute text contrast well for solid backgrounds, but they cannot judge text on images, cannot tell if color alone carries meaning, and do not test reflow, motion, or forced colors. The accessibility testing lesson covers how to combine them with manual checks.

How real products handle it

• GOV.UK Design System: links are underlined in body text, and the focus state is a yellow #ffdd00 background with a thick black underline, which works on every page color and survives most color deficiencies because it changes lightness, not only hue.
• GitHub (Primer): ships light and dark high contrast themes and color-blind themes (protanopia and deuteranopia, and tritanopia) that replace the red and green used in diffs and status checks. Users pick them in settings, in addition to following the OS.
• Apple platforms: the system honors Reduce Motion, Increase Contrast, and Bold Text, and the Human Interface Guidelines recommend 44 by 44 point touch targets.
• Windows: contrast themes are built into the OS, which is why forced-colors exists; Microsoft Edge and Chrome both apply them to web pages.

Using it in a system design interview

Visual accessibility rarely gets its own question. It comes up inside "design a component library", "design a dashboard", "design a news feed", or when the interviewer asks "how would you make this accessible?" A strong candidate brings it up briefly and concretely, at the level of the system, not as a list of slogans.

When to bring it up and what to say

• Design system or component library: this is the main place. Talk about semantic tokens per theme, the allowed pairs, the contrast test in CI, prefers-reduced-motion built into the motion tokens, and forced colors support in every control.
• Dashboards and charts: color alone. Say you will label series directly, use patterns or markers, and offer a table view.
• Forms: errors with icon and text, not just a red border; input borders at 3:1; targets at least 24 px.
• Feeds, media, landing pages: auto-playing video and carousels need pause controls and must respect reduced motion; text on images needs a scrim.
• Any responsive layout: mention that supporting 320 px wide covers 400% zoom.

How deep to go by level

What to draw: a small token diagram (primitives, semantic tokens per theme, components), plus a note on the CI contrast test. If the question is a dashboard, sketch one chart with direct labels and a toggle to a table. Keep it to a minute or two unless the interviewer digs in.