In the first of a series, Chris Pigden, our Accessibility Engineer, writes about how we built the accessibility Skill for Figma Make: the problem it solves, why AI-generated prototypes fall short on accessibility by default, and how the Skill and its toolbar get you from a design to a testable, far more accessible prototype in minutes.
A coded, working prototype used to be a luxury. You needed a developer and time. With Figma Make, you can describe a design, or hand over an existing one, and get a working HTML prototype back in minutes.
Static Figma designs are not HTML, so assistive technology users cannot meaningfully test them to reveal issues users would face if the design were coded and deployed. Figma Make changes this; you can send a design to Make to generate a prototype and then take that into user testing with people who use assistive technology early, while changes are still cheap. And you can spin up several variations to test just by describing them.
There’s a catch, though. By default, a prototype from Make or any AI coding tool contains accessibility issues, some serious enough to make testing with assistive technology users difficult. This issue gave Intopia and Figma a chance to collaborate on making the code generated by Make more accessible. This article describes the Agent Skill we built. A follow-up by my colleague Claire Webber will cover how we tested it.
Why AI output isn’t accessible by default
AI coding agents have become very good at writing code. What they’re not good at is proactively thinking about accessibility while they write it. Unless you ask, they generally won’t.
That comes down to training data. Accessible code almost certainly exists in the data, but there’s far less of it than inaccessible code, so the model treats the accessible code as the exception rather than the norm. Two things reinforce this for us:
- WebAIM’s 2026 testing of one million home pages found accessibility issues on 95.9% of them. Nearly every site has problems.
-
At Intopia, we do a lot of accessibility audits. We see a clear link between the types of mistakes that AI makes and those many developers have made, such as missing headings, interactive elements without accessible names or roles, inaccessible forms (everything from missing attributes to form validation), keyboard and focus management, poor contrast, and layouts that break when zooming.
So the average developer’s code still has plenty of accessibility issues in it. Train an AI on a large body of that unvetted code, and it’s not surprising it reproduces the same failures. AI lets us build faster than ever, but it scales those problems just as fast.
The encouraging part is that the fix might not be a better model. You can improve things a lot right now by giving the tool better context. Give it the rules, and a way to check itself, at the right point in the process.
On the back of our web accessibility skill
Back in March we shared an early web accessibility skill on the Intopia blog. A skill is a set of instructions an AI agent follows for a task. Ours combined accessibility principles with an index of acceptance criteria and code examples for common components, plus a colour contrast script. When we started the collaboration with Figma we were able to use the skill as a foundation.
Making it work in Make
Make supports skills, but it implements them differently to most other tools, so we couldn’t just drop our existing skill in.
Most coding agents load a skill as a folder: they include a SKILL.md file that has instructions for the agent, plus references, scripts and templates.
Make uses a single file. You can’t split guidance into references to load only relevant parts, so we packed the key information into one file. We kept the Skill under 500 lines to avoid burning through Figma credits.
How the Skill works
The Skill works to a plan. It starts by writing an accessibility.md file, which records every accessibility decision as it goes and keeps the agent on track across Make’s turn-by-turn iteration. Next it builds a palette.json of your colour combinations and runs a contrast script over it. The script finds contrast issues, suggests fixes, applies them, then retests to confirm they pass. From there it builds the page against the plan. And finally it reports every decision it made, and tells you how to check the result with a toolbar.
A toolbar for manual verification
As well as improving the model’s output, we also had to think about who uses Make. Its users are more often designers than developers, some lack the materials knowledge to verify the code output, and those using the desktop app cannot access developer tools to check the output.
That led us to build a toolbar. When the skill finishes running, it injects a small accessibility toolbar into the prototype. The toolbar annotates the page in place, exposing properties you’d otherwise need to inspect the DOM to see, and covers the most common issues: heading structure, name, role and value, images and alt text, colour contrast, touch targets, keyboard operation and responsive reflow. Where a check needs a human, such as keyboard and responsive behaviour, it gives you the manual steps. Each finding can be copied as an editable prompt to paste straight back to the agent.
The toolbar allows a designer to see and better understand what an assistive technology sees, and fix it, without leaving the canvas.
Where it fits
The skill gets the code much closer to accessible. The toolbar lets you see that for yourself. Together they take you from a design to an accessible prototype quickly and cheaply, ready to put in front of people with disability for user testing. In our benchmarks, pass rates against our accessibility tests roughly doubled with the skill in place with many rising from 47% to 97% pass rates. Claire will share the full numbers soon.
The skill is no silver bullet. Results vary with the model and the prompt, the skill uses more tokens, and it’ll occasionally overdo things, such as adding contrast to a decorative border. A bad design or user experience also won’t be rescued by semantic code. But as a way to raise the baseline early, when it’s cheapest to fix, the skill earns its place.
Two follow-ups are coming: Claire’s on how we tested this skill, and one on our web accessibility skill, backed by an evaluation suite that measures how it performs.
The Intopia A11y Guideline Skill for Figma is available to download now from GitHub. We’d like your feedback, so please open an issue and tell us what works and what doesn’t.