From Figma to Prod: Fixing Accessibility at Design Handoff

Designers create beautiful, thoughtful interfaces in Figma. They consider user flows, visual hierarchy, and interaction patterns. Then somewhere between design approval and production deployment, accessibility disappears. The heading structure gets flattened. Focus states vanish. Screen reader experiences become afterthoughts—if they're considered at all.

This isn't a people problem. It's a process problem. Figma accessibility intent doesn't automatically translate to accessible code because the information developers need simply isn't in the design files. Visual mocks show what things look like, not how they should behave for keyboard users, screen reader users, or users who need reduced motion.

The accessible UI design handoff isn't about adding more work—it's about making accessibility information as explicit as colors and spacing. When semantics, focus order, and interaction states are documented alongside visual specs, developers can implement accessibility correctly the first time instead of retrofitting it later.

What Needs to Be Explicit in Design Files

Semantics and Structure

Visual hierarchy is obvious to sighted users scanning a Figma mockup. A screen reader user navigating the implemented page experiences something entirely different: the underlying semantic structure that HTML provides.

Headings and landmark regions. Designers know which text is a "title" visually, but do they specify whether it's an H1, H2, or H3? Do they indicate which areas are navigation, main content, or complementary sidebars? The W3C's guide to page structure explains why this matters: screen reader users navigate by headings and landmarks the way sighted users scan visually.

Naming conventions that signal hierarchy. Establish Figma naming patterns that communicate structure: "H1 - Page Title," "H2 - Section Header," "nav - Primary Navigation." When layer names communicate semantics, developers don't have to guess.

Lists and grouped content. When items are visually arranged as a list or a group of related options, call that out explicitly. Should this be a <ul>, <ol>, or a group of radio buttons? The visual representation doesn't make this clear.

Region labels for repeated patterns. If your design has multiple card sections or content areas, specify how each should be labeled for assistive technology users who can't see the visual distinction.

Focus Order and Interaction States

Keyboard users interact with interfaces sequentially, tabbing through focusable elements. The visual layout doesn't dictate focus order—and designers often create layouts where the logical reading order differs from visual arrangement.

Mapping tab order through screens. For any complex layout, annotate the expected focus sequence. When users press Tab, what gains focus first? Second? Third? The WebAIM keyboard accessibility guide documents standard expectations, but custom layouts need explicit specification.

Focus states for every interactive element. Buttons, links, form fields, and custom controls all need visible focus indicators. Specify what focus looks like—not just hover states. Many designers create hover states but forget that keyboard users need focus states that are at least as prominent.

Interaction states beyond hover and focus: Document pressed, disabled, selected, expanded, and error states. For components like accordions, tabs, or toggles, specify the full state matrix and how transitions work.

Modal and overlay focus management. When a modal opens, where does focus go? When it closes, where does focus return? These behaviors significantly impact keyboard and screen reader users but are rarely specified in designs.

Alt Text and Non-Text Content

Images, icons, and charts need text alternatives—but which ones, and what should they say? Designers understand the intent behind visual content better than developers deciphering images later.

Use Figma's notes panel for alt text suggestions. For meaningful images, write the alt text you'd want a screen reader to announce. For decorative images, indicate they should be hidden from assistive technology. The W3C alt text decision tree provides guidance on which images need descriptions and what those descriptions should include.

Specify whether icons need labels. Icon-only buttons need accessible names. Does the icon have adjacent visible text? If not, what should the accessible label be? Don't make developers guess your design intent.

Document complex visualizations. Charts, graphs, and data visualizations need text alternatives that convey the same information. Should there be a summary? A data table alternative? A detailed description? Designers who understand the data story should guide how it's communicated non-visually.

Handoff Rituals That Protect Accessibility

Documentation alone isn't enough. Teams need structured touchpoints where accessibility gets explicit attention.

Accessibility Design Critiques

Add a standing agenda item or separate session focused specifically on accessibility review:

Weekly or biweekly accessibility-focused review. Design critiques typically focus on visual aesthetics and UX flow. Reserve time specifically for accessibility questions: Is the heading hierarchy logical? Are touch targets large enough? Are color combinations contrast-compliant?

Invite accessibility expertise when available. If your organization has accessibility specialists, include them. If not, rotate the role of "accessibility advocate" among team members, giving someone explicit responsibility to raise accessibility questions.

Use structured checklists. Create a design accessibility checklist covering semantics, focus management, color contrast, touch targets, and motion. Microsoft's Inclusive Design toolkit provides frameworks that can be adapted for design review.

Joint Design–Dev Reviews

The handoff moment itself needs attention. Don't throw designs over the wall—walk through them together with accessibility in mind.

Walk through prototypes with keyboard-only navigation. In the design review meeting, have a developer try navigating the prototype using only keyboard. Where does the expected focus sequence break? Where are focus traps? This surfaces issues before code is written.

Talk through screen reader experience. Even without a screen reader running, discuss what the audio experience should be. "When you reach this section, the screen reader should announce 'Product Details, heading level 2, followed by price and add-to-cart button.'" This verbalizing process catches assumptions.

Identify components that need special attention. Flag any non-standard interactions: custom dropdowns, drag-and-drop, tab panels, auto-complete. These need explicit ARIA implementation discussion, not just visual specs.

Annotated Specs

Formalize accessibility information in exported specs and developer documentation:

Include accessibility annotations in your handoff tool. Whether you use Figma's dev mode, Zeplin, or another tool, add accessibility annotations: heading levels, landmark roles, focus order, accessible names. Figma's accessibility annotation plugins can streamline this process.

Create component-level accessibility documentation. For each component in your design system, document: semantic element to use, required ARIA attributes, keyboard interaction pattern, and focus behavior. Reference patterns from the ARIA Authoring Practices Guide.

Specify responsive behavior that affects accessibility. Mobile layouts often change navigation patterns, hide content, or alter interaction modes. Document how accessibility requirements change across breakpoints.

Ensuring Design Systems Carry Accessibility by Default

The highest-leverage accessibility intervention is building it into your design system. When base components are accessible, everything built from them inherits that foundation.

Accessible Components in Figma Libraries

Design system components should encode accessibility requirements:

Document expected behavior, not just appearance. For a button component, specify: semantic element (<button>), states (default, hover, focus, pressed, disabled), keyboard interaction (Enter and Space activate), and focus indicator appearance.

Include focus states in all component variants. It's common for design systems to include hover states but omit focus states. Ensure every interactive component has a visible, high-contrast focus indicator variant. The Focus Visible specification and the :focus-visible CSS pseudo-class guide implementation.

Provide accessible color combinations. Design token libraries should flag or prevent color combinations that fail WCAG contrast requirements. At minimum, document which text colors are safe on which backgrounds.

Create accessible pattern examples. For complex components like modals, accordions, tabs, and carousels, provide fully specified patterns covering ARIA attributes, keyboard navigation, and focus management.

Mapping Design Tokens to Code Tokens

Design tokens should encode accessibility-relevant values that transfer cleanly to code:

Color tokens with contrast metadata. Structure color tokens so developers know safe combinations. Consider tokens like text-on-primary that explicitly define accessible pairings rather than separate text-color and background-color tokens that can be mismatched.

Spacing tokens that ensure touch target compliance. Minimum touch target size is 24x24px per WCAG 2.2 Target Size criteria. Spacing and sizing tokens should make meeting this requirement the default path, not an exception.

Typography tokens that support readability. Font size, line height, and letter spacing tokens should default to accessible values. Minimum font sizes, adequate line height (1.5 for body text), and scalable units (rem, not px) support users who need larger text.

Automating Validation Once Designs Hit Code

Even with perfect handoffs, implementation can drift. Automation catches issues before they reach production.

CI/CD accessibility checks on every pull request. TestParty integrates into your deployment pipeline to catch accessibility regressions. When a developer implements a component without the specified focus state, automated checks flag it before merge.

Visual regression testing combined with accessibility scanning. Visual regression tools catch when designs aren't implemented correctly visually. Pair them with accessibility scanning to catch when accessibility requirements aren't implemented correctly either.

Component library documentation site scanning. If your design system has a documentation site or Storybook instance, scan it regularly. This validates that your canonical component examples are accessible before they're copied across your products.

Monitoring for regressions in production. Continuous scanning of your live sites catches issues that slip through. When new code breaks accessibility that was previously working, you'll know immediately rather than discovering it in an audit months later.

Conclusion – Handoff as an Accessibility Superpower, Not a Weak Link

The design-to-development handoff is where most accessibility work either succeeds or fails. Figma accessibility details that aren't documented don't get implemented. Interactions that aren't specified get improvised—often inaccessibly.

But when teams treat accessible UI design as a first-class handoff requirement—when semantics, focus order, and alt text are as specified as colors and spacing—accessibility becomes the default rather than the retrofit.

The investment is modest: annotation time in Figma, focused review discussions, and documented component requirements. The return is substantial: fewer accessibility bugs, faster development (because developers aren't guessing), and products that work for everyone from launch.

Ready to align your design system and codebase on accessibility? Talk to TestParty about integrated scanning that validates your implemented components match your accessible design intent.

Related Articles:

• Equitable Design: Beyond Accessibility Compliance
• Building Accessibility Checks Into Modern CI/CD Workflows
• Automated Accessibility Remediation: Everything You Need to Know