Accessibility Guide for UI Designers: WCAG, Contrast, and Practical Fixes

Accessibility isn't a checklist you run through at the end of a project. It's a set of design decisions you make throughout the design process. Most accessibility problems are design problems — they're fixable in Figma long before a developer writes a line of code.

Here's the practical foundation you need.

WCAG 2.1 basics

WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility. It has three conformance levels:

• Level A — the minimum. Not meeting A means significant access barriers.
• Level AA — the standard target for most products. Required by law in many jurisdictions for public-facing products.
• Level AAA — the highest level. Not required for entire sites, but individual components can target it.

As a UI designer, target Level AA. That's what "accessible" means in practice.

WCAG 2.1 organizes all criteria under four principles, known as POUR:

Perceivable — users can perceive all content. Information isn't conveyed by color alone. Images have alt text. Video has captions. Text has sufficient contrast.

Operable — all functionality is accessible via keyboard. Focus is visible. No time limits trap users. No content flashes more than three times per second.

Understandable — language is clear. Forms explain what's expected and give useful error messages. Navigation is consistent.

Robust — the product works with current and future assistive technologies. Semantic HTML is used correctly. ARIA is used when necessary.

Your design decisions primarily affect Perceivable and Operable. The Robust principle is mostly an engineering concern, though your design specs influence it.

Contrast ratios

The most common accessibility failure in UI design is insufficient color contrast.

WCAG 2.1 AA requires:

• 4.5:1 contrast ratio for normal text (under 18pt regular weight, or 14pt bold)
• 3:1 for large text (18pt regular or 14pt bold and above)
• 3:1 for non-text elements that convey information: icons, input borders, chart elements, buttons that are identified only by color

How to read a contrast ratio: 21:1 is maximum contrast (black on white). 1:1 is no contrast (white on white). The higher the number, the better.

Common fails:

• Gray placeholder text in inputs (often fails 4.5:1 on white)
• Secondary text in cards and tables
• Disabled state text (deliberately low contrast — this is an exception for disabled elements in most interpretations, but check your own style guide)
• Icon-only buttons without a visible border or background

Checking contrast in Figma with Stark

The Stark plugin is the fastest way to check contrast in Figma. Select a text layer or a UI element, launch Stark, and it calculates the contrast ratio between the foreground and background color.

Try Stark for Figma

Use Stark's Vision Simulator to preview your designs with different types of color vision deficiency — protanopia, deuteranopia, tritanopia, and achromatopsia. This quickly reveals whether you're relying on color alone to communicate information.

The most important rule about color: never use color as the only way to convey information. If an error state is indicated only by red text, users who can't distinguish red from other colors miss the message. Pair color with a text label, an icon, or a border.

Focus states

Every interactive element needs a visible focus state. This is one of the most commonly skipped design decisions — designers design the default state and forget that keyboard users tab through the interface.

WCAG 2.1 AA (and particularly 2.2's criterion 2.4.11) requires focus indicators with a minimum contrast ratio of 3:1 between the focused and unfocused states.

Design your focus state as an explicit style: a high-contrast outline, typically 2-3px, offset slightly from the element. Many design systems use a blue or brand-colored ring. The exact style is flexible — what matters is that it's clearly visible.

Apply focus states to: buttons, links, form inputs, checkboxes, radio buttons, toggles, dropdowns, tabs, navigation items, and any custom interactive component.

Touch target sizes

For mobile and touch interfaces, interactive elements need to be large enough to tap accurately. WCAG 2.1 Success Criterion 2.5.5 (Level AAA) recommends 44x44px minimum touch targets. WCAG 2.2's updated criterion 2.5.8 (Level AA) requires 24x24px as the absolute minimum, with exceptions.

In practice, use 44x44px as your design target. This matches Apple's Human Interface Guidelines and Google's Material Design recommendations.

A common mistake: an icon is 24x24px visually, but it's placed in a 44x44px tappable area using padding. That's fine — the tappable area is what matters, not the icon size. Make sure your designs communicate the intended touch target area to developers.

Designing for screen readers

Screen readers navigate using semantic structure. As a designer, you don't write HTML, but your decisions affect it:

Heading hierarchy. Your visual hierarchy should map to a logical heading structure. The page title is H1. Section titles are H2. Sub-sections are H3. Don't use heading styles for decorative purposes or choose heading levels based only on visual size.

Image descriptions. Every meaningful image needs an alt text description. Decorative images (purely visual, no information) should be marked as decorative (alt="") so screen readers skip them. Communicate this intent in your design specs.

Form labels. Every form field needs a visible, persistent label — not just placeholder text. Placeholders disappear on input and are often low-contrast. The label should remain visible when the field has content.

Error messages. Error messages must be text, not just a red border. They should be specific: "Password must be at least 8 characters" not "Invalid password."

Button labels. Icon-only buttons need accessible names. Add tooltip text and communicate to developers that the button needs an aria-label attribute. "Close dialog" is better than "X" for a screen reader.

Try Figma Free

Common mistakes to fix right now

1. Text below 4.5:1 contrast on any background — check every color combination
2. Placeholder text used instead of labels in forms
3. Focus states missing from components
4. Errors conveyed by color change alone
5. Touch targets under 44x44px on mobile
6. Icon-only interactive elements without text labels
7. Modals that don't trap focus (mention to developers)

Accessibility is fixable. Most of it comes down to contrast, labels, and focus. Get those right and you're most of the way to AA compliance before engineering touches a line of code.