Accessibility in web design: the WCAG decisions designers own

Why accessibility in web design matters

Disabled people are a large share of every audience, and many more people have temporary or situational limits: a broken wrist, a phone in bright sun, a noisy train, a slow connection, tired eyes late at night. Designs that work for them work better for everyone.

There are hard reasons too. Laws in the US, the EU, the UK, India and elsewhere expect WCAG AA (see ADA website compliance). Clear structure and real text help search engines. And every barrier a designer prevents is one a developer never has to fix later.

WCAG meaning in design: the criteria designers own

Spelled out, WCAG is the set of Web Content Accessibility Guidelines. In design, it is the checklist behind many visual and interaction decisions. These are the ones that start in a design file:

The full list, with filters for level and version, is in our WCAG checklist.

Color and contrast choices

Contrast is the most common failure on the web, and it is entirely a design decision. Test text and background pairs with our contrast checker; for the rules behind the numbers see contrast ratio rules.

• Mid grey #767676 is the lightest grey that passes 4.5:1 on white; anything paler fails for body text.
• Placeholder text, disabled-looking buttons that are actually active, and text over photos are frequent failures.
• Input borders and icon-only buttons need 3:1 so people can find them.
• Never use color alone for meaning: an error field needs a message and an icon, not just a red border. The rule is 1.4.1.

WCAG responsive design: type, spacing and reflow

A CSS pixel is the unit browsers use for layout, not a physical screen pixel. WCAG asks that content works at 320 CSS px wide, which is what a 1280 px wide window shows at 400 percent zoom. Low vision users rely on this.

• Design a single column version of every template and check that nothing is cut off or overlaps.
• Avoid fixed heights on boxes that hold text; text spacing changes and larger fonts will overflow them.
• Use real text instead of images of text, so it can zoom, reflow and be read aloud.
• Keep line length moderate and body text at a comfortable size; WCAG sets no minimum font size, but users notice.

Details live on our pages for reflow (1.4.10) and text spacing (1.4.12).

Focus, targets and interaction states

Keyboard users need to see where they are. Design a focus state for every interactive element with the same care as the hover state, for example a thick outline whose color reaches 3:1 next to the surrounding colors. Check that sticky headers, cookie banners and chat buttons never cover the focused item.

Tap and click targets should measure 24 CSS px each way or more, and small links in a row need room between them. Tooltips and menus that appear on hover must stay open as the pointer travels over them, and close with Esc. Our pages on visible focus (2.4.7) and target size (2.5.8) go further.

Forms, links and content structure

• Put a visible label above or beside every field. Placeholder text disappears when people type and often fails contrast.
• Mark required fields in text, and show error messages in words next to the field.
• Write link text that makes sense on its own, such as "Download the price list (PDF)" instead of a bare "More". More on that under link purpose (2.4.4).
• Use a clear heading hierarchy that matches the visual hierarchy, so screen reader users can skim.

Motion, media and reduced motion

Autoplaying carousels and background videos distract some users and can make others feel ill. Anything that moves for more than five seconds next to other content needs a visible pause button. Also respect the operating system setting that asks for less motion:

@media (prefers-reduced-motion: reduce) {
  .hero-slider { animation: none; }
  .card { transition: none; }
}

Plan captions and transcripts while you design the media player, not after launch.

Handing designs to developers

Most accessibility gets lost between the design file and the code. Add annotations for:

• heading levels and landmarks (header, nav, main, footer);
• the reading and focus order where it is not obvious;
• alt text for informative images and a note for decorative ones (see alt text);
• the accessible name of every icon-only button;
• what screen readers should announce after an action, such as "Item added".