A streaming service marks each downloaded title as ready, expiring or failed using only green, amber and red dots on TV and web; how do you fix its functional status roles?

## What is actually wrong In the scenario, a streaming service's downloads screen shows each title with a small dot: green for ready, amber for expiring, red for failed. Nothing else changes between the three states. That design breaks in several ways at once: - **It fails WCAG 2.2 Success Criterion 1.4.1 Use of Color (Level A).** Color is the only visual means of conveying the status, which is exactly what 1.4.1 rules out. - **Red and green are the classic confusion pair.** The most common forms of color-vision deficiency affect red-green discrimination, commonly estimated at around one in twelve men, so for a real share of users ready and failed look alike. - **The TV makes it worse.** Televisions vary widely in calibration, often run vivid picture modes that shift hues, and are watched from across a room, where a small dot is only a few pixels of color. - **The dot says nothing on its own.** Even a user with typical color vision has to learn a private legend: does amber mean downloading, expiring or paused? The local fix - add a label to this one screen - is necessary but not enough. The same hue-only habit will reappear elsewhere unless the functional palette itself changes. ## Fixing the status roles, not just the screen The durable fix is to redefine each status role as a **bundle** that cannot be used partially: | Status role | Color | Icon shape | Text pattern | |---|---|---|---| | success, shown as ready | green family | check mark | Ready to watch | | warning, shown as expiring | amber family | clock | Expires in 2 days | | error, shown as failed | red family | exclamation mark in a triangle | Download failed, retry | Then: 1. **Make shapes distinct.** Three circles in three colors are still hue-only; a check, a clock and an exclamation mark differ in silhouette, so they survive grayscale. 2. **Make lightness distinct.** Choose status values that also differ in lightness, so even the colored part reinforces the difference rather than relying on hue. 3. **Keep a text label where the status matters.** The words remove the need for a legend, and they give assistive technology something meaningful to announce. 4. **Ship it as one status indicator in the system**, whose contract requires the label, so a team cannot express just a red dot without deliberately leaving the system. 5. **Update the guidance**: color reinforces the status; the shape and the words carry it. ## What 1.4.1 does and does not ask It is worth being precise in the interview. 1.4.1 does not ban color: color may remain one of the means, and it is valuable reinforcement for users who perceive it. It asks that color not be the **only** visual means. WCAG's guidance also treats contrast, a difference in lightness, as something other than hue: for inline links it documents a technique in which link text differs from surrounding text by at least 3:1. That is a narrow case, though; for three statuses on a busy TV row, an icon and a word are the robust answer. A second criterion sits close by. If the colored dot or icon is itself needed to understand the status, WCAG 1.4.11 Non-text Contrast (Level AA) asks for at least 3:1 against adjacent colors. Getting each status value to that threshold on each surface is accessible-pairing work; the functional palette's job is to make sure the status never depends on hue in the first place. ## Rolling it out - **Audit** every place a status role is used across TV and web, and list the ones that rely on color alone. - **Fix the system first**, then migrate screens, so new work picks up the bundle by default. - **Verify** with grayscale screenshots and color-vision simulation as a quick smoke test, then with real users where possible; the detailed method belongs to accessibility testing. - **Watch for regressions** in design and code review: any new status that arrives as a color swatch without an icon and a label is a design bug. ## Why this is a palette question Treating it as a one-off bug gets one screen fixed. Treating it as a flaw in how status roles were defined fixes the downloads screen, the subscription-state label, the profile-lock indicator and every future status in one change. That leverage is the reason a design system has a functional palette at all: it is the one place where a rule about meaning can be made once and inherited by every team, on every platform the service ships to.