Figma Specs: Put Accessibility Into the Instructions Agents Build From
Figma’s new Specs feature caught my attention because it gives written design intent a home alongside the visual work—and a way to reach agents through MCP.
My immediate question: what accessibility context are we putting in those specs?
An agent can reproduce a screen and still miss how someone is supposed to use it.
A screenshot doesn’t explain where keyboard focus goes after a dialog closes. A color token doesn’t establish contrast across every state. A loading animation doesn’t describe what happens for someone who has reduced motion enabled.
If those decisions aren’t documented, we leave the agent to infer them.
“Make it accessible” is not enough context.
The opportunity I see is to connect accessibility guidance to the design system itself: its foundations, tokens, components, and flows, through implementation and testing.
A gap I’ve already encountered
I’ve run into a version of this problem with my own AI A11y Toolkit.
When I adapted it into a Figma skill, the character limit in that workflow forced me to compress the guidance. In my testing, that condensed version performed worse than the fuller Markdown toolkit.
That matters because accessibility guidance becomes less useful when specific requirements turn into broad reminders. The details explain what to implement, which exceptions matter, and how to verify the result.
Specs makes me curious about a different approach: keep a short instruction in the skill that directs the agent to retrieve the full guidance from a Spec, alongside the relevant design-system requirements.
Could that preserve the detail I lost when compressing the toolkit?
Potentially. But that is my next test, not a conclusion I can draw from the announcement.
More room for context addresses one limitation. Whether the agent retrieves that context, follows it, and produces better results is what we need to evaluate.
Give each layer a clear job
I would structure the workflow around four connected sources:
The toolkit: shared accessibility requirements that apply across the work.
Design-system Specs: product-specific decisions about tokens, components, content, and behavior.
The implemented component library: the actual components agents should reuse.
Validation evidence: what has been tested, what failed, and what remains unresolved.
These sources need to agree. A Spec describing keyboard behavior is useful only if the implementation provides it. An implemented component needs documentation that accurately describes its capabilities and limitations.
Here is how I would build that relationship.
1. Establish the foundations before generating components
Start by identifying the platform, existing component library, design tokens, and accessibility requirements.
Bring the toolkit into the system’s foundational guidance. Then document the product-specific context it cannot know: supported platforms, content needs, user research, assistive technology considerations, and implementation constraints.
The foundational Spec should establish expectations for semantic structure, keyboard operation, visible focus, contrast, text resizing and reflow, descriptive content, and user preferences.
It should also explain how to resolve conflicts.
If matching a visual treatment would break contrast or keyboard access, the agent should identify the conflict and propose a correction. It should not quietly prioritize visual fidelity.
Give this guidance an owner and a version. Accessibility requirements need the same maintenance as the rest of the system.
2. Build accessibility into the tokens
A palette is a collection of possibilities. A token system needs to describe intended use.
Document approved foreground and background pairs, focus treatments, control boundaries, and interaction states. Include the contrast calculations and the contexts in which each pairing works.
Check the less prominent tokens too: secondary text, helper text, borders, placeholders, and disabled states where applicable. A strong primary palette does not resolve every contrast decision.
Do the same for typography, spacing, and motion.
Specify how text can grow, how layouts reflow, and how controls retain usable targets. Describe which effects change or disappear when a user requests reduced motion, increased contrast, or reduced transparency.
An agent should understand why a token exists and where it belongs. A variable name and a hex value provide only part of that instruction.
3. Give every component a behavioral contract
Each component needs a Spec connecting its visual design to its purpose and behavior.
Document what the visual design cannot reliably communicate:
Meaning: What is the element? What is its accessible name? Is an image meaningful or decorative?
Interaction: How does it work with a keyboard? Is there an alternative to dragging or hovering?
Focus: Where does focus enter, move, and return? What happens when an element disappears?
Feedback: How are loading, success, errors, and changes communicated without relying on color or motion alone?
Adaptation: What changes with user preferences, smaller screens, or enlarged text?
For a button, this includes its action, label, states, and focus treatment.
For a dialog, the requirements are more involved: its name, initial focus, keyboard behavior, dismissal rules, and where focus returns when it closes.
Identify the tested component implementation the agent should use. Connect it to the corresponding design component through the available design-to-code workflow, such as Code Connect.
Where a suitable implementation exists, the agent should reuse it rather than recreate its behavior from a drawing.
The toolkit supplies shared requirements. The component Spec makes them concrete.
4. Specify how components work together
Individually well-built components can still create a difficult experience when assembled into a flow.
A checkout Spec, for example, needs to explain reading order, validation, error recovery, progress, and what happens after submission.
What does the user hear while payment is processing? Where does focus go after an unsuccessful attempt? Is their information preserved? Can they complete the task without dragging, hovering, or remembering information from an earlier screen?
These are design decisions. They belong alongside the flow.
The same applies to content. Specify meaningful headings, descriptive links, clear instructions, and error messages that explain how to recover.
An agent needs enough context to build the experience between the screens, too.
5. Write requirements that can be verified
Compare these two instructions:
“Support reduced motion.”
“When reduced motion is enabled, do not initialize the decorative particle layer or attach its pointer-tracking listeners. If the preference changes while the page is open, remove the layer and stop its interaction work.”
The second describes a specific product decision. It gives the agent an implementation requirement and the reviewer something observable to verify.
The same applies to forms.
Instead of “show an accessible error,” specify the error text, its relationship to the field, how it is announced, what happens to focus, and whether the user’s entered information is preserved.
“Keyboard accessible” is similarly incomplete.
“The user can open the dialog, reach every control, close it with Escape, and return focus to the trigger” provides a much clearer acceptance criterion.
The goal is to make the consequential decisions explicit.
6. Make retrieving the guidance part of the workflow
Putting guidance in a Spec does not prove that an agent retrieved or followed it.
The shorter skill could instruct the agent to:
Read the foundational accessibility guidance.
Retrieve the relevant token, component, and flow Specs.
Identify the existing implementation to reuse.
Summarize the applicable requirements and flag missing decisions.
Implement the work and report the validation performed.
Keep product-wide guidance consistent with the instructions in the code repository. Avoid maintaining competing copies that gradually diverge.
For my toolkit experiment, I would compare the condensed skill against that same skill connected to fuller guidance through Specs, using the same tasks and evaluation criteria.
Did the agent retrieve the requirements? Did it implement them? Did the resulting experience perform better?
That would tell me whether Specs meaningfully closes the gap I encountered.
7. Validate the implementation against the Spec
A written requirement is a starting point. The implemented experience is what people use.
Run automated accessibility checks against the rendered components and flows. Confirm that the intended content actually loaded before interpreting the results.
Then test what automation cannot establish on its own: keyboard operation, focus order, text resizing, reflow, assistive technology behavior, the accuracy of alternative text, and whether the instructions make sense.
Record what was tested, what failed, and what still needs human evaluation.
An agent’s statement that it followed the Spec is not evidence that the result works. Neither is a clean automated scan.
8. Feed discoveries back into the system
When testing uncovers an issue, fix the implementation and update the relevant guidance.
If an agent repeatedly misunderstands a requirement, improve the instruction. If a component has a limitation, document it where the next person—or agent—will encounter it.
Review changes to a Spec alongside changes to its component. Keep the written intent, design representation, and shipped behavior aligned.
That is how this becomes a maintained design system rather than another collection of documents that quietly ages.
The opportunity is in the connections
What interests me about Specs is the possibility of making accessibility intent easier to carry from design into implementation.
My toolkit can describe shared requirements. A design system can turn them into reusable, product-specific decisions. Specs could help make those decisions available at the moment an agent needs to act on them.
That still leaves us responsible for the quality of the guidance, the choices we make, and the testing that follows.
If our specs document only how an interface should look, we are leaving a significant part of the design unfinished.
