Can AI Adapt an Accessible Figma Design System? Testing the DesignA11y Design System
This weekend, I put the workflow I’d been writing about into practice.
In my specs workflow article, I explored how accessibility requirements could travel from guidance into product-specific specifications, reusable components, and validation. The next question was whether an AI agent could use that structure to make changes without losing the decisions that mattered.
So I gave it something concrete to work on.
I built out the DesignA11y Design System in Figma, connected the work to specifications on GitHub, and tested an AI-guided workflow for adapting the system to another brand.
The public beta is now available. And the most useful part of the weekend was finding the gap between a convincing result and a completed one.
How is the DesignA11y Design System different from DesignA11y?
DesignA11y is my broader platform for exploring inclusive design, accessibility, and AI through articles, experiments, and practical resources.
The DesignA11y Design System is a specific resource within that platform: a reusable Figma system with companion specifications on GitHub and a guided AI brand-adaptation workflow.
The system brings together reusable components, responsive and editorial patterns, motion guidance, and accessibility requirements.
The distinctive part is how those pieces work together around one question: what should an agent change, and what does it need to preserve?
Colors, typography, imagery, and corner treatments should be adaptable. Accessibility requirements need to remain explicit throughout that process.
The system is designed to give both people and agents a shared reference for those decisions, plus a way to inspect the outcome. That is the ambition we started testing this weekend.
How does the DesignA11y Design System address motion accessibility?
The DesignA11y Design System includes motion guidance alongside its visual foundations, so movement and reduced-motion alternatives can be considered as part of the system and its adaptation requirements.
I design motion. I also know what it feels like when movement on a screen makes an experience physically difficult to use.
That perspective matters to this work. Motion carries personality, explains relationships, and creates emphasis. Its behavior also needs requirements: where it appears, how it behaves, and what happens when someone needs less of it.
The motion work brings those considerations into the system alongside the visual examples and brand assets. Reduced-motion alternatives need to be part of the design conversation, and agents need clear instructions about preserving them.
When an agent adapts the system for another brand, it needs to preserve the motion accessibility requirements as it changes the visual expression. Updating the artwork and checking how it moves are separate tasks.
What worked when AI adapted the design system?
The strongest results came from the structure already built into the system.
Shared variables and styles gave the agent meaningful places to make changes. Typography could propagate across components. Colors could flow through semantic roles. Central decisions could affect many parts of the file without treating every element as a separate redesign.
The specifications gave us something concrete to evaluate. We could inspect relationships, check color pairs, and compare the results against requirements.
In one adaptation pass, all 44 checked token pairs passed their contrast checks.
That is useful evidence with a specific scope. It tells us those pairs passed those checks. It does not establish that every screen, state, interaction, or eventual implementation is accessible.
We also had a productive feedback loop: test an adaptation, identify a gap, improve the source system and instructions, then test again.
What did the AI adaptation get wrong?
The agent updated visual foundations more consistently than brand-specific content and assets. It also missed layout problems that became apparent during visual review.
The first adaptation looked promising at a glance. Then I started opening pages and reading them.
The new brand had inherited colors and typography, but parts of the file still contained DesignA11y language, imagery, backgrounds, and motion graphics. Some responsive templates and resource patterns had adapted more completely than others.
Longer names wrapped awkwardly. Documentation overlapped parts of the design. Corner-radius behavior exposed decisions we had not made sufficiently configurable.
The agent had changed enough to create the impression of a finished adaptation. The file still needed work.
For example, some motion examples still contained the original DesignA11y artwork after the colors and typography had changed. The agent had updated the styling but had not replaced all the branded assets.
That was a gap in brand adaptation. It showed us that the instructions needed to explicitly cover artwork replacement across the file, including the motion examples.
Brand identity lives in content, assets, examples, and naming as well as tokens. Those all need explicit treatment in an adaptation workflow.
We also had a less productive round in which the agent spent too much time researching the brand online and too little time applying the information already available.
That was a workflow lesson: research needs a scope and a stopping point. More activity does not necessarily mean more progress.
What did we change after testing?
These tests made the system’s assumptions visible.
We refined the central controls for corner treatments, clarified which names should remain stable and which should follow the brand, and tightened the guidance around content and asset replacement.
We also improved the starting instructions. Even identifying the target file needed care: an agent working inside the currently open Figma duplicate needs different directions from an external assistant accessing that duplicate by URL.
The important decision was where the fixes belonged. The QA copy preserved evidence of what happened. The master system and adaptation instructions needed the improvements so the next person duplicating the file could benefit.
How do Figma and GitHub support the specs workflow?
The Figma file provides the visual system. The GitHub repository makes the companion specifications available for review, versioning, and contribution.
It gives us a place to explain expectations in detail, track changes, and document validation limits alongside the requirements.
The challenge is keeping those expectations aligned with the design as it evolves. Publishing both gives people more of the work to inspect, question, and improve.
Can AI adaptation replace human accessibility review?
No. These tests showed why automated checks, human visual review, and implementation testing serve different purposes.
I needed to look at the work.
Read the labels. Inspect the templates. Notice the old graphic sitting in an otherwise updated layout. Compare the completion report with the actual file.
The automated checks and my visual review found different kinds of problems. Both were necessary.
There is also validation that a Figma file cannot settle: browser reflow, keyboard behavior, assistive technology support, and the behavior of an implemented product. The system can document those expectations. Implementation still has to demonstrate them.
This weekend moved the specs workflow from an idea into a public beta that people can try.
It also reinforced why the verification step matters. Making requirements available to an agent is the beginning. We need to make them actionable, preserve them through changes, and collect evidence that they were followed.
The failures showed us where our assumptions stopped being instructions.
That is what I’m continuing to build into the DesignA11y Design System. If you try the system, I’d love to hear what adapts well, what gets missed, and what would make the workflow more useful.
Where can you try the DesignA11y Design System?
The DesignA11y Design System public beta is available in Figma Community, with companion specifications on GitHub. The AI Accessibility Toolkit is a separate, related resource within DesignA11y; it is linked below too.
Duplicate the DesignA11y Design System public beta in Figma Community
