Accessibility in UI/UX Design: A Practical Guide to WCAG

Accessible UI/UX design means making design decisions that let people of all abilities perceive and use a product. Designers own many of them: meeting WCAG contrast ratios (4.5:1 for normal text, 3:1 for large text and UI components at level AA), visible focus states, adequately sized touch targets, never using color alone to convey meaning, readable typography that scales, clear form labels and errors, restrained motion, and annotated reading order, labels and alt text for developers. Building these in from the start is far cheaper than fixing them later.

Developers implement accessibility, but many barriers are designed in: low-contrast text, invisible focus, tiny tap targets, color-only status indicators, placeholder-only labels. This guide covers the design decisions; the website accessibility guide covers implementation such as semantic HTML, keyboard support and screen readers.

The W3C's WCAG 2.2 organizes requirements under four principles: perceivable, operable, understandable and robust. Level AA is the common target for business products. The design-relevant criteria are summarized below.

Check text and interface contrast as you pick the palette, not after. Pay special attention to placeholder text, disabled-looking elements that are actually active, text over images, and thin fonts. Non-text contrast applies to input borders, icons and focus indicators too. Pair color with text or icons for errors, statuses and charts.

Use readable sizes, adequate line height and line length, and clear heading hierarchy. Designs should survive users enlarging text: plan how layouts reflow rather than truncating or overlapping. Avoid long passages in all caps or light weights.

Design a clear, consistent focus indicator for every interactive element, with enough contrast against its surroundings. Make sure sticky headers, cookie banners and chat widgets don't cover focused elements, which WCAG 2.2 addresses explicitly. Define a logical focus order in your annotations.

Meet WCAG 2.2's 24 by 24 CSS pixel minimum and aim higher on mobile, where Apple and Google recommend around 44 points and 48 dp. Provide alternatives to complex gestures such as dragging or multi-finger swipes, and avoid time limits users can't extend.

Use visible labels, not placeholder-only fields. Group related inputs, mark required fields clearly, and write error messages that say what's wrong and how to fix it, placed next to the field. Don't clear the form after an error.

Keep animation purposeful, avoid flashing content, and design reduced-motion alternatives that respect users' operating system settings. Plan captions for video and transcripts for audio, and ensure media controls are accessible.

Bake accessibility into tokens and components: accessible color pairs, focus styles, minimum target sizes and error patterns. Then every screen built from the system inherits it. See design systems.

This guide describes design best practice aligned with WCAG. Legal requirements differ by jurisdiction and sector, so confirm your obligations with qualified legal advice.

Many accessibility barriers are design decisions: contrast, focus, target size, color use, labels and motion. Design them in, annotate them for developers, and encode them in your design system. Then test with assistive technology and real users, as part of usability testing.