Color, Contrast & Visual Design

Web Accessibility — Color, Contrast & Visual Design
Web Accessibility (a11y)
Chapter 6 · Color, Contrast & Visual Design

🎨 Color, Contrast & Visual Design

Chapter 5 covered forms. This chapter covers what's actually visible — color, contrast, and motion — Chapter 1's Perceivable principle made concrete for users with low vision, color blindness, or motion sensitivity.

WCAG Contrast Ratio Requirements

Content TypeMinimum Ratio (Level AA)
Normal text4.5:1
Large text (18pt+/24px+ regular, or 14pt+/18.66px+ bold)3:1
UI components & graphical objects3:1

The exact math isn't something to memorize — the thresholds and why they exist matter: low vision, aging eyes, and glare on mobile screens outdoors all make marginal contrast genuinely unreadable for a meaningful share of real users.

🚫 Never Relying on Color Alone

Any information conveyed via color must also be conveyed through at least one other channel — Chapter 1's own red/green form-error example is the classic case. This applies broadly:

Links in Body Text

Color alone doesn't reliably distinguish a link from surrounding text for a color-blind user — an underline or other non-color cue is needed too.

Status Indicators

A colored dot alone for "online/offline" needs an accompanying text label or icon — color-coded charts need patterns or direct labels, not just a color-keyed legend.

Color Alone vs Color Plus Another Channel

Color Only

A green dot means "online" — invisible information for anyone who can't distinguish that specific color.

Color + Text/Icon

A green dot and the word "Online" — the same information reaches everyone, regardless of color perception.

Text Resizing & Zoom Support

Users must be able to zoom or resize text up to 200% without losing content or functionality (WCAG 1.4.4). Common failures: fixed-height containers that clip text once font size increases, and text set with no responsive fallback at all.

<!-- Actively blocks a core accessibility feature — never do this --> <meta name="viewport" content="width=device-width, user-scalable=no"> <!-- Correct: leaves zooming fully enabled --> <meta name="viewport" content="width=device-width, initial-scale=1.0">

🌀 prefers-reduced-motion

A CSS media feature reflecting a user's OS-level preference to minimize animation — relevant for vestibular disorders, where parallax scrolling, large animated transitions, or auto-playing carousels can genuinely trigger motion sickness:

.carousel { animation: slide 8s infinite; } @media (prefers-reduced-motion: reduce) { .carousel { animation: none; } }

Respecting this preference means providing a reduced or eliminated-motion alternative for any significant animation — not just pure decoration, but often necessary functional transitions too.

💻 Coding Challenges

Challenge 1: Fix a Color-Only Status Indicator

A dashboard shows server status as only a colored circle (green = healthy, red = down), with no text or icon. Propose a fix that satisfies the "never color alone" principle.

Goal: Practice adding a second channel of information alongside an existing color signal.

→ Solution

Challenge 2: Identify the Contrast Failure

A button uses white text (#FFFFFF) on a light gray background (#D3D3D3) for its normal-size label. Explain why this likely fails WCAG AA, referencing this chapter's threshold table.

Goal: Practice reasoning about a contrast failure without needing to compute the exact ratio by hand.

→ Solution

Challenge 3: Respect Reduced Motion for a Functional Animation

A page uses a sliding animation to reveal a notification banner from off-screen. Write CSS that respects prefers-reduced-motion while still functionally showing the banner (not hiding it entirely) for users with that preference set.

Goal: Practice distinguishing "remove the motion" from "remove the content" for a functional (not purely decorative) animation.

→ Solution

⚠️ Gotcha: Disabling Zoom With user-scalable=no

Adding user-scalable=no (or maximum-scale=1) to the viewport meta tag explicitly disables pinch-to-zoom — one of the most direct, active violations of WCAG's zoom requirement possible. It's usually added by a developer trying to prevent "accidental zooming" during mobile interactions, without realizing it strips away a core, browser-provided accessibility feature that users with low vision genuinely depend on just to read the page at all. Never disable user scaling — if accidental zoom is a real concern, that's a UI/gesture-handling problem to solve some other way, not a reason to remove zoom entirely.

🎯 What's Next

With visual design covered, the next chapter goes directly to the assistive technology itself: Screen Readers in Practice — the accessibility tree vs the DOM, and testing with a real screen reader.