By Mehdi HassanWhat are the basics of accessible web design?
The basics of accessible web design are contrast, readable typography, visible focus, adequate target sizes, not relying on color alone, and motion people can turn down. Those six areas cover most of the visual success criteria in WCAG Level AA, the standard behind US and EU accessibility rules. Get them right in your design system and every page you build inherits them.
This guide is about the design side: the decisions made in Figma before any code exists. Code and content matter just as much, and our overview of website accessibility compliance shows how the pieces fit together. For a full criterion-by-criterion list split by role, use the WCAG 2.2 checklist.
One principle runs through all of it: accessible UI design is about removing guesswork. A visitor shouldn't have to squint at gray text, hunt for where keyboard focus went, or guess which field has the error. Clear design is accessible design, and it makes pages easier to use for everyone.
Does accessible design make a website look plain?
No. Accessible design limits a few measurable things, like contrast ratios and target sizes, and leaves almost everything that makes a brand distinctive alone: type choice, layout, imagery, illustration, color palette, motion and tone. A site can look premium and still pass WCAG AA; visitors notice the brand, not the contrast ratios.
The 'accessibility makes sites ugly' idea usually comes from two places. One is low-contrast gray-on-white text that designers like because it looks soft; making it pass means darkening it slightly. The other is patching an existing site late, when the only quick fix is a crude one. Designed in from the start, accessible choices look intentional.
How do you meet WCAG color contrast without a dull palette?
You meet WCAG color contrast by checking each text and UI color pairing against the required ratio, then adjusting tones, not abandoning hues. Keep your brand color; build a ladder of lighter and darker tones around it, and use the tones that pass for text and the ones that don't for backgrounds, illustrations and large fills.
Element | Minimum contrast (WCAG AA) | Design note |
|---|---|---|
Body text | 4.5:1 against background | Includes captions, labels and placeholder text you rely on |
Large text | 3:1 | Roughly 24px regular or about 19px bold and above |
Icons that carry meaning | 3:1 against adjacent colors | Decorative icons are exempt |
Input borders and toggles | 3:1 | A pale field outline often fails |
Focus indicator | 3:1 against its surroundings | Check on every background it can appear on |
Disabled controls | No requirement | But make sure people can tell why it's disabled |
Logos and brand marks | No requirement | Exempt by WCAG |
Bright brand colors like yellow, lime, light orange and cyan rarely pass as text on white, but they work well as button fills with dark text on top. That's often the best of both: the brand color stays loud, the label stays readable. Our deeper guide to accessible brand colors shows how to build a palette that passes without losing personality.
Worked example: fixing a brand green that fails
For example, suppose a brand uses a bright green for buttons with white labels, and the pair fails 4.5:1. There are three common fixes.
First, keep the green and switch the label to near-black, which usually passes easily on bright colors. Second, keep white labels and darken the button green a few steps, then use the original bright green for illustrations and highlights. Third, keep the green for large display text only, where 3:1 applies.
Most teams pick the first or second, and the brand still reads as green.
What makes typography accessible?
Accessible typography is readable at the browser's default size, survives zoom to 200%, keeps lines a comfortable length and doesn't break when users increase spacing. Typeface choice matters less than people think; size, weight, contrast and spacing matter more.
- Size. Set body text at or above the browser default of 16px, in relative units so user font settings work.
- Weight. Avoid very thin weights for body text, especially in mid-gray; thin strokes lose contrast on many screens.
- Line length. Keep paragraphs to a comfortable measure; full-width text on wide screens is hard to track.
- Spacing. WCAG asks that text still works when users increase line height, letter and word spacing, so don't fix heights on text containers.
- Real text, not images of text. Headlines baked into images can't be resized, translated or read aloud.
- Hierarchy. Make headings visibly different by size and weight, and match them to real heading levels in code.
If you're designing for several languages, longer translations put more pressure on all of this; see designing for multiple languages for text expansion and right-to-left layouts.
How do you design focus states that look good?
Design focus states as part of the component, not as a browser default you hope nobody sees. A good focus state is clearly visible on every background it can appear on, consistent across the site, and styled to match the brand. Keyboard users rely on it to know where they are.
A reliable pattern is a two-tone ring: a solid outline in a dark color with a thin light gap or second ring, offset slightly from the element. It stays visible on light sections, dark sections and photos. In code, using the focus-visible selector shows it for keyboard users without showing it on every mouse click, which removes the main reason designers hide focus styles.
- Never remove outlines without a replacement. It's one of the most damaging accessibility mistakes.
- Check sticky elements. WCAG 2.2 adds that focus can't be fully hidden behind sticky headers or cookie banners.
- Design hover and focus together. If hover changes a card's border, focus can use the same style plus an outline.
How big should buttons and links be?
Buttons, links and other targets should be at least 24 by 24 CSS pixels under WCAG 2.2 AA, or spaced so neighboring targets don't crowd each other. Comfortable designs go bigger for primary actions, especially on touch screens. Small icon buttons in navigation, footers and modal close buttons are where this usually fails.
Two more rules work alongside size. Links inside paragraphs need a cue beyond color, usually an underline, because color alone fails people who can't tell the hues apart. And every state that matters, like an error, a selected option or a required field, needs a second signal: an icon, text or a pattern.
How should accessible design handle motion and interaction?
Accessible design keeps motion purposeful and gives people a way to turn it down. Large parallax effects, zooming backgrounds and auto-playing carousels can trigger dizziness or nausea for people with vestibular disorders, and content that moves for more than five seconds needs a pause control under WCAG.
The fix isn't removing motion. Design a reduced-motion version of each animation, typically a fade instead of a slide or zoom, and let the operating system setting choose it. Small, responsive feedback is fine and often helpful; our guide to micro-interactions that make a website feel premium covers the kind that adds polish without harming anyone.
How do you build accessibility into a design system?
Build accessibility into the design system by making the accessible choice the default one: color tokens that already pass, components with every state designed, and type styles that scale. Then designers and editors can't easily make a page that fails.
Audit the palette
Check every text and UI color pair against WCAG ratios, and mark which tokens are safe for text.
Design all component states
Default, hover, focus, active, disabled, error and loading for every interactive component.
Set type in relative units
Define a scale that works at 200% zoom and at phone width.
Annotate for developers
Note heading levels, focus order, labels and reduced-motion behavior in the handoff file.
Test the build
Check the result with a keyboard and a screen reader, using our guide on how to test website accessibility.
It also helps to start with the words. When copy exists before layouts, as in copy-first web design, headings, labels and link text are written for meaning rather than squeezed into boxes. Product teams can take the same approach into the app with accessible web app UI design.
