The Design Gap

Accessibility fails most often at the design stage — not in code. By the time a Figma file reaches engineering, the critical accessibility decisions — colour contrast, focus order, heading hierarchy, interaction patterns — have already been made and are expensive to undo. Treating accessibility as a developer or QA problem means fixing issues that were baked in months earlier, at the highest possible cost.

The uncomfortable truth: most WCAG failures are not developer mistakes. They're designer choices baked into the visual foundation. A designer picks a color palette that fails contrast requirements. A designer creates interactive components without defining focus states. A designer invents a custom accordion interaction without documenting keyboard navigation. The developer then inherits these decisions and has to either implement them as designed (failing WCAG) or risk deviating from the spec.

The design gap exists because designers aren't trained in accessibility. They weren't taught how to think about keyboard navigation in design school. They've never heard of ARIA roles. They don't know what a focus indicator should look like or why it matters. So they make decisions in isolation, driven purely by aesthetics or interaction flow, without considering the downstream impact.

Colour Decisions That Haunt You

Colour contrast is one of the easiest accessibility criteria to verify, but one of the hardest to fix after the fact. A designer spends three weeks perfecting a colour palette that looks beautiful on their screen. By the time QA runs it through a contrast checker and fails WCAG AA at 3.8:1 instead of 4.5:1, the entire visual identity has been locked in.

What happens next? Either the product ships non-compliant, or the designer and developer go back and forth trying to find a new shade that maintains the aesthetic while hitting the contrast target. Both outcomes are preventable.

The solution is built into design tools. Tools like Stark (a Figma plugin) let designers check contrast ratios in real time while they're building the palette. The A11y Annotation Kit helps designers document accessibility decisions directly in their Figma file. But most teams don't use these tools because they don't know they exist, or accessibility isn't part of the design workflow yet.

If you're leading a design team, adding contrast checking to your design system tooling is non-negotiable. It's not a nice-to-have. It's the difference between shipping compliant and shipping broken.

Missing Interaction States

Here's a pattern I see constantly: a designer hands off a button component with the default state and the hover state. That's it. What about the focus state? The active state? The disabled state? The error state? What does the button look like when it's loading?

If the design file doesn't define these states explicitly, developers have to invent them. And when developers invent interaction states without guidance, you get inconsistency. One button might have a 2px focus outline. Another might have a 3px outline. One might be blue. Another might be green. The focus indicator on one component might be too thin to see.

This sounds like a minor detail, but it's critical for accessibility. Users who navigate by keyboard rely entirely on visible focus indicators to know where they are. If the focus state is unclear or missing, they're lost. Users with mobility impairments who can't use a mouse depend on these states for feedback.

The fix is simple: document every interactive state in the design. If a component responds to hover, it needs a focus state in the same file. If a button can be disabled, show what that looks like. If a form field can error, design that state. This doesn't take much longer. It just requires thinking ahead instead of reacting later.

Component Assumptions

Many design systems create custom components that don't have a direct HTML equivalent. A custom accordion. A custom dropdown. A custom carousel. A custom date picker. When designers build these in Figma, they're thinking about the visual interaction: what happens when you click, how content reveals or hides. They're not thinking about ARIA.

An accordion in Figma looks like a stack of collapsed sections with arrows. But in the accessibility world, an accordion is a widget with specific roles and attributes. The container needs role="region". The button needs aria-expanded. The panel needs aria-labelledby and role="region" or correct nesting. If the designer doesn't document this, the developer has to guess or spend time researching ARIA patterns.

Icon-only buttons are another classic case. A designer creates a beautiful icon button with a magnifying glass. It looks great. But there's no visible text. When a developer implements it without an accessible label, screen reader users have no idea what it does. The button becomes <button><svg>...</svg></button> with no accessible name.

The rule of thumb: if your component doesn't have a clear semantic HTML structure, document the accessibility requirements in the design file. Don't rely on developers to figure it out. The best custom components have ARIA documentation attached.

Fixing It Upstream

The best time to plan accessibility is when you're designing, not after QA fails the audit. Here's a practical checklist for accessibility-aware design:

  • Document ARIA roles in Figma. If your component needs a role attribute, write it in the design file. Add a comment or use the annotation kit. Developers will thank you.
  • Include focus management notes. For modals, popovers, and complex interactions, document where focus should move. Should it trap inside the modal? Should it return to the trigger button when closed?
  • Create explicit keyboard navigation specs. Don't assume developers know that Tab moves through fields, Escape closes the modal, Arrow Keys navigate the menu. Write it down. Include it in the handoff.
  • Check colour contrast during design. Use Stark or similar tools. Don't hand off a palette that fails WCAG.
  • Define all interactive states. Include hover, focus, active, disabled, error, and loading states for every interactive element.
  • Label icon-only buttons and images. Add a note about what the accessible name should be. Don't make developers guess.

When accessibility is baked into the design workflow, it doesn't slow you down. It actually makes handoffs cleaner because developers have the information they need upfront. They don't have to send the design back asking questions about focus states or ARIA roles.

The product also ends up more accessible because the design was created with accessibility in mind from day one, not bolted on as an afterthought. That's the goal: make accessibility a design concern, not a developer burden.