How to Design for Accessibility

Most accessibility guidance for designers starts and ends with color contrast. That's important — but it's one piece of a much larger picture. Designing for accessibility means designing for the full range of how people interact with interfaces.

There are four broad categories of disability to consider. Here's what each means for your design decisions.

Visual disabilities

This covers blindness, low vision, and color blindness. Color contrast is the obvious one — use the Stark plugin in Figma to check that your text and UI elements meet WCAG AA minimums (4.5:1 for normal text, 3:1 for large text and non-text elements).

Beyond contrast:

• Don't convey meaning through color alone. An error state that's only red fails users with red-green color blindness. Pair it with an icon, a text label, or a border change.
• Ensure text can scale up to 200% without breaking layouts. Users with low vision use browser zoom. Fixed-height containers that clip text at 200% zoom are an accessibility failure.
• Provide text alternatives for all meaningful images. This isn't just a developer task — you should spec the alt text in your design annotations.
• Design with sufficient visual separation between elements. Low-vision users benefit from clear boundaries, not just color-coded distinctions.

Try Stark for Figma

Motor disabilities

Motor disabilities include conditions that affect fine motor control, hand tremors, paralysis, and single-switch navigation. Users may not be using a mouse. They might be using a keyboard, a switch device, eye tracking, or voice control.

What this means for design:

• Touch target sizes. 44x44pt minimum on iOS (48dp on Android). Buttons that are too small are a motor accessibility failure, not just a UX annoyance.
• Spacing between interactive elements. Closely packed buttons are harder to hit accurately with any input device. Leave at least 8px between interactive targets.
• No time-limited interactions. If something requires hovering for more than a moment, users who can't hold a cursor steady will fail. Prefer click/tap over hover for critical functionality.
• Keyboard navigation. All interactive elements must be reachable and usable via keyboard. Tab order should be logical. Actions should be completable without a mouse.

Auditory disabilities

Auditory accessibility is most relevant for products with video, audio, or call features. For pure UI design:

• Don't rely on audio alerts for important notifications. Always provide a visual equivalent.
• If your product includes video, spec captions as a required feature.
• If your product includes voice features or calls, spec visible transcription or text alternatives.

For most SaaS or web app design, auditory considerations don't drive layout decisions — but they belong in your design annotations whenever audio is involved.

Cognitive disabilities

This category covers learning disabilities, attention and memory conditions, and cognitive load more broadly. These design decisions benefit everyone, not just users with diagnosed conditions.

Cognitive accessibility in practice:

• Use plain language. Error messages, tooltips, and instructions should be readable at a 6th-grade level when possible. "An unexpected error occurred (500)" is less useful than "Something went wrong on our end. Wait a moment and try again."
• Reduce choices. Decision fatigue affects everyone. Narrow choices in critical flows — don't put 12 options on a settings page that needs to walk users through three steps.
• Provide clear progress indicators. Multi-step flows should always show where the user is and how many steps remain.
• Consistent patterns. The same action should always look the same and live in the same place. Don't move navigation between screens.
• Avoid motion that can't be disabled. Vestibular disorders are triggered by excessive animation. Users should be able to reduce motion via system settings (the prefers-reduced-motion media query). Spec a static alternative for every significant animation.

Focus management

Focus is the browser's way of tracking which element the keyboard is currently controlling. Designing for keyboard accessibility means thinking about focus, not just static visual design.

Specify in your annotations:

• What gets focus when a modal opens (the first interactive element inside the modal, or the modal heading)
• Where focus returns when a modal closes (the element that triggered it)
• The focus ring style — make sure it's visible and styled to match your design system, not hidden or barely visible
• Tab order for complex components (if the visual order isn't the logical reading order)

Reading order

Screen readers read elements in the order they appear in the DOM, which should match the visual reading order. Designs with overlapping elements, visually complex grids, or elements that look related but aren't grouped together can produce reading orders that make no sense to a screen reader user.

When you create complex layouts in Figma, consider specifying the intended reading order in your annotations. Developers need to know which elements should be grouped, what the tab sequence should be, and which decorative elements should have empty alt text (so screen readers skip them).

Testing your designs for accessibility

Beyond Stark for contrast checking, a quick manual keyboard test catches most design-level accessibility issues. Open your prototype in a browser. Tab through every interactive element. Can you reach everything? Is the focus indicator visible? Can you complete every task without a mouse?

For more thorough testing: the axe DevTools browser extension runs automated accessibility checks on live pages. NVDA (Windows, free) or VoiceOver (Mac, built-in) let you test the actual screen reader experience.

Build accessibility checks into your handoff process, not as a final review step. Finding an inaccessible pattern at component design stage is fast to fix. Finding it in QA means engineering rework.