Accessibility is often treated as a development concern — something to fix after the design is implemented. But most accessibility issues originate in the design phase: insufficient color contrast, small touch targets, missing heading hierarchy, unclear focus states. By the time a developer discovers these problems, fixing them means redesigning.
This guide covers the key accessibility checks you should run on every Figma design, and how to use Subtree's A11y tool to automate them.
Why audit in design, not development
Catching accessibility issues in Figma is 10x cheaper than fixing them in code. A color contrast failure in Figma takes seconds to fix — adjust the color token. The same failure in production might require updating CSS, testing across themes, verifying against the design, and deploying. The feedback loop is shorter when the designer can fix it before handoff.
More importantly, some accessibility decisions are design decisions. Whether a button is 44px or 32px is a visual choice with accessibility implications. Whether text is #999 or #666 is a design choice that determines WCAG compliance. These should be intentional, not accidental.
The five checks that catch 80% of issues
1. Color contrast
WCAG 2.1 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18px+ regular or 14px+ bold). This is the single most common accessibility failure on the web.
Common culprits in design:
- Placeholder text that's too light (often #999 or #aaa on white)
- Subtle gray labels on light backgrounds
- White text on pastel or light-colored buttons
- Text over images or gradients without sufficient overlay
Subtree's A11y tool checks every text node against its background and flags failures with the exact contrast ratio and a suggested minimum color value.
2. Touch target size
Interactive elements should have a minimum touch target of 44x44 pixels (WCAG 2.5.5) or 24x24 pixels (WCAG 2.5.8 minimum). This applies to buttons, links, toggles, checkboxes, and any other clickable element.
Small icons used as buttons are the most common offender. A 16px icon might look clean, but without padding, it's nearly impossible to tap accurately on mobile. The fix is simple: keep the visual size small, but ensure the tappable area meets the minimum.
3. Heading hierarchy
Screen readers use heading levels (h1 through h6) to navigate page structure. Headings should follow a logical order — h1 first, then h2, then h3, without skipping levels. A page that jumps from h1 to h4 creates a confusing experience for screen reader users who rely on heading navigation.
In Figma, heading hierarchy isn't enforced — it's just text with different sizes. Subtree's audit infers heading levels from font size and weight, then validates the order. If your "Section Title" at 24px is followed by a "Subsection" at 14px with no intermediate level, it flags the skip.
4. Focus indicators
Every interactive element needs a visible focus state for keyboard navigation. This is often the most overlooked accessibility requirement in design, because designers test with a mouse.
A good focus indicator should:
- Be visible against all backgrounds (not just one theme)
- Have sufficient contrast (3:1 minimum against adjacent colors)
- Not rely solely on color change (add an outline, border, or shadow)
- Be at least 2px thick
Consider designing focus states for every interactive component in your design system. It's easier to do once at the component level than per-instance.
5. Alt text and meaningful labels
Images need alternative text. Icons used as buttons need aria-labels. Decorative elements need to be marked as such. While these are technically implemented in code, the content decisions happen in design.
When designing, annotate:
- What each image conveys (not what it looks like, but what information it provides)
- What each icon button does (e.g., "Close dialog", not "X icon")
- Which images are decorative and can be hidden from screen readers
Running an audit with Subtree
Subtree's A11y tool automates these checks. Here's how to use it:
- Select the frame you want to audit in Figma
- Open Subtree and switch to the A11y tab
- Click "Run Audit" — the tool analyzes every node in the selected frame
- Review the results by category: contrast, touch targets, headings, alt text, focus indicators
- Each issue includes the specific node, the current value, and what it should be
The audit produces a composite score from 0 to 100, but the score matters less than the individual findings. A score of 85 with one critical contrast failure is worse than a score of 75 with only minor spacing issues.
Building accessibility into your process
Three habits that help:
- Audit early. Run an A11y check after creating each major section, not after the whole page is done. Small issues are easier to fix before they cascade.
- Fix at the system level. If a color token fails contrast, fix the token in your design system rather than the individual instance. This prevents the same issue from recurring.
- Document decisions. When you intentionally deviate from WCAG guidelines (e.g., a decorative element below contrast threshold), annotate it. This saves developers from "fixing" things that are intentional.
Accessibility isn't a feature — it's a quality attribute, like performance or security. The earlier you address it in the design process, the less costly and disruptive it is. Tools like Subtree's A11y audit make the feedback loop fast enough that checking becomes effortless.