DESIGN NOTES / Accessibility handoff

A Figma accessibility checklist for design and handoff.

Check contrast, content, resizing, and interaction annotations in Figma. Separate design intentions from accessibility behaviour that must be tested in code.

Define what a design-file review can establish

A Figma review can uncover problems in visual choices, content, and specified interactions. It cannot prove that a browser will expose correct semantics, announce errors, or support keyboard navigation. Begin with a checklist that separates inspectable design decisions from implementation checks. Give unresolved items an owner and a verification method. Do not mark the whole product accessible because a plugin reports no contrast failures.

Use the current WCAG reference to understand the relevant requirements and exceptions, and confirm the target with the responsible team. A design checklist is not legal advice or a compliance certificate. Review plugins and their permissions before use, and never place sensitive participant or customer information in a shared file just to make an example look realistic.

Check actual colour pairs and meaningful states

List the text and background combinations used in components, including errors, selected states, and content over images. For WCAG 2.2 AA text contrast, normal text generally requires at least 4.5:1; large text requires 3:1. The large-text definition uses at least 18 point regular or 14 point bold, approximately 24 or 18.7 CSS pixels. These thresholds have defined exceptions; a large frame or bold-looking font alone does not qualify text as large.

Check relevant non-text controls and indicators against the applicable 3:1 requirement, using the W3C guidance to interpret boundaries and exceptions. Test gradients and variable image backgrounds where the text actually appears. Do not rely on colour alone for errors, status, or selected options. Add understandable labels, shapes, or other cues that remain meaningful without the hue.

Stress the layout with content and resizing

Replace ideal placeholders with synthetic long names, multiple-line labels, realistic errors, and translated text where relevant. Check narrow layouts and annotate how content should wrap, reflow, or remain available when enlarged. Figma auto layout is a design aid, not proof of browser reflow. Plan implementation checks with enlarged text and zoom, including the relevant WCAG resize and reflow criteria and their exceptions.

Keep essential instructions outside placeholders because entered values replace them. Specify useful link text and alternatives for meaningful images. Provide room around controls and consider people using touch, magnification, or limited dexterity. WCAG 2.2 AA includes a 24 by 24 CSS pixel minimum target criterion with exceptions, including spacing. A Figma measurement alone does not establish that criterion in the shipped interface.

Annotate the interactions that a screenshot cannot show

Describe semantic roles, accessible names, heading hierarchy, reading order, and expected keyboard behaviour. Specify how focus enters and leaves overlays, how it returns after dismissal, and how errors become discoverable. Include visible focus designs and states beyond hover. Prefer familiar native interaction patterns where suitable; adding an ARIA label later does not repair an incoherent control model.

Hand off a verification list, then check the build

Create a short handoff record containing the component, design decision, implementation requirement, and test still needed. Reference the particular frame or variant, not a vague instruction to “make it accessible”. Include reduced-motion behaviour when animation communicates a transition, and make sure essential content does not depend on motion. Keep unresolved questions visible alongside approved visual work.

In the implemented experience, test relevant tasks with keyboard navigation, zoom, appropriate assistive technology, and automated tools. Involve disabled participants where feasible and with informed consent; one participant cannot represent every access need. Record the environment, issue, and recheck result rather than converting a tool score into a certification claim. Accessibility depends on the actual experience, its content, and ongoing changes, not the design file alone.

PUT YOUR THINKING TO WORK

A resource. A next step. A fresh pair of eyes.

Try the free case-study learning path, browse original guides and templates, or bring a specific question for feedback.

Explore feedback options