Using AI tools to drive an accessible dev process

I have been working in digital accessibility for decades, and as a blind user I still run into accessibility barriers every day; buttons with no label, forms that make no sense when read out of visual order, interfaces that change state without telling my screen reader, and custom controls that look polished but fall apart the moment you try to use a keyboard. More than two decades after digital accessibility became a legal requirement here in the UK, that remains a normal part of daily life.

That is the backdrop to any conversation about AI and accessibility. This is not a theoretical problem. It is not a niche concern for a specialist team. It is the difference between being able to do something independently and being shut out by design decisions that should never have made it into production.

That is why I think this moment matters. For the first time, the tools are starting to exist that could materially improve the accessibility of digital products at scale, provided we use them in the right way. The opportunity is not simply that AI can generate code faster. It is that AI can sit much closer to the points where accessibility is won or lost: design systems, component libraries, testing pipelines, internal standards and day-to-day developer workflows.

Prompting is useful, but it is not enough

A lot of current practice still starts with prompting. Ask an AI coding assistant to produce accessible HTML. Tell it to use semantic elements. Remind it about labels, contrast and keyboard support. You will usually get a better result than if you say nothing at all.

That matters. Prompting can improve outcomes and it is often the easiest first step for teams experimenting with AI-assisted development. But it should not be mistaken for a strategy.
The evidence is already pointing in that direction. A W4A 2025 study comparing accessibility-agnostic and accessibility-oriented prompts found that accessibility-oriented prompts improved results, but persistent barriers remained, particularly around semantic structure. Microsoft’s A11y LLM Eval report also makes the same broader point from a different angle. Its control baseline reported a 12% overall pass rate on the automated checks used in the harness, while a reusable accessibility skill reached an 86% average final-turn pass rate on those same checks. That is a meaningful lift, but the report is careful to say that passing those automated checks does not mean the result is fully WCAG conformant or fully accessible.

In other words, prompts help, structured guidance helps more, and neither removes the need for better context, better tooling and human judgement. If a model is still drawing mainly on generic training data and whatever you managed to squeeze into a prompt window, it will keep reproducing the weaknesses of the web it learned from. That may be faster than manual development, but it is not the same as building accessibility in with confidence.

What changes when AI can query live sources of truth

The more promising pattern is to stop treating accessibility as something the model should remember and start treating it as something the model can query. That is where Model Context Protocol, or MCP, becomes interesting for technical teams.

The core idea is simple. Instead of relying on a static pre-prompt, an AI agent can connect to structured sources of truth while it is working. Figma’s MCP server, for example, is designed to bring design information and context directly into AI-supported development workflows. Figma says this allows agents to extract design context such as variables, components and layout data directly into the IDE, while Code Connect helps generated code stay consistent with the real codebase. That is a very different proposition from asking a model to infer your design intent from a screenshot or a paragraph of instructions.

The same principle can be applied to accessibility. If the assistant can query current component definitions, tokens (your reusable design values), patterns, accessibility guidance, audit rules and project conventions while writing code, the conversation shifts. The model is no longer guessing what your team probably means by an accessible dialog or a compliant card component. It has live context.

Layer 1 - connect the design system, not just the prompt

The first layer is the design system itself. In practical terms, that means exposing components, variables, tokens and usage guidance to the AI inside the development environment.

This matters because a large proportion of accessibility defects are variations of the same problem. Teams depart from known good patterns. They recreate controls instead of reusing them. They hardcode values instead of using tested tokens. They translate design artefacts into production code by hand and lose important semantics on the way.

When AI is connected to the design system, it has a much better chance of assembling from the approved building blocks rather than improvising. Figma explicitly positions its MCP server as a way to extract design context and generate code from selected frames, while Code Connect is there to keep generated output aligned to the actual components in the codebase. 

Atlassian has publicly shown the practical effect of this approach. In one example, it described wiring together Figma MCP, its Atlassian Design System MCP and Rovo Dev so an AI agent could read design context, query component APIs and accessibility guidance, generate React code and then run tests against the output.

For accessibility leaders, that should ring alarm bells in a good way. We have spent years asking teams to be consistent, to reuse components, to shift left and to stop reintroducing known problems. AI can reinforce that discipline, but only if it is drawing from the real system rather than from the statistical average of the (very flawed) public internet.

Layer 2 - make accessibility testing part of the generation loop

The second layer is automated checking in the loop, not after the fact. This is where the workflow becomes much more interesting than simple code completion.

A more mature pattern looks like this: the AI generates code, runs accessibility checks against it, receives the failures, applies revisions and reruns the checks before the pull request is even raised. 
Accessibility stops being something that waits for QA, audit or user complaint. It becomes part of the act of authoring.

The tooling is already credible enough to support that direction. For example, Microsoft’s evaluation harness also uses automated checks and curated test cases to assess how well models generate accessible HTML. Again, that does not mean automation catches everything. We know it does not. But closed-loop testing inside the engineering workflow is far better than treating accessibility as a downstream clean-up exercise. It can catch missing labels, broken heading structures, contrast failures and some keyboard-related issues before they settle into the codebase and start spreading across products.

Layer 3 - give the model access to your internal accessibility knowledge

The third layer is where many organisations will find the deepest value over time. Design systems and automated rules can cover a lot, but not everything. There are always local patterns, past audit findings, exception handling approaches, fallback rules, content guidance and accessibility decisions that live outside the component library.

That is why a curated internal knowledge layer matters. If your AI assistant can query WCAG mappings, house rules, examples from previous audits and explanations written by your accessibility team, it can do more than flag an issue. It can explain the issue in the language of your organisation, suggest a fix that fits your stack and help developers understand why the rule exists in the first place.

This is especially important for teams who do not have accessibility specialists embedded in every sprint team. Most developers are trying to do the right thing, but they do not always have immediate access to the detail behind a failed check or a nuanced interaction pattern. If AI can pull from trusted internal guidance at the moment of need, it becomes a practical bridge between specialist knowledge and everyday delivery.

Why this matters so much to me as a blind user

There is also a very human reason why I find this so compelling. Accessibility failures tend to be discussed as defects, risks or compliance gaps. For disabled users they are interruptions to ordinary life. They are tiny moments of doubt and dependency, repeated over and over again. Can I complete this form on my own. Can I trust this button. Has the page actually updated. Is there a way through this process that does not involve asking someone else.

For years, the frustrating part has been that many of these failures were avoidable. They were not caused by some unsolved scientific problem. They happened because accessibility knowledge arrived too late, was spread too thinly, or was treated as a specialist checkpoint instead of normal engineering practice.

That is why I believe AI could be genuinely consequential here. Used carelessly, it could absolutely accelerate bad patterns. Used well, it could finally put accessible thinking, accessible components and accessible checking directly inside the flow of design and development, where they belong. For someone like me, who still encounters inaccessible experiences every week, that is not a marginal improvement. It is the possibility of changing the background level of friction that disabled people live with every day.

What technical teams should do next

If you lead design systems, frontend engineering, accessibility or digital governance, the practical next step is not to ask whether AI can write accessible code in the abstract. The better question is where your current sources of truth live, how reliable they are, and whether your AI tooling can use them. 

Start by looking at your design system and component library. Are the accessible patterns mature enough to be reused confidently. Do your tokens and component APIs express the decisions you want teams to implement. Is there a clear connection between design artefacts and production components. If not, AI will simply expose the weakness faster.

Then look at testing. Which accessibility checks can run automatically during generation, review and continuous integration. Where are the obvious feedback loops you could tighten. Which failures should block progress and which should trigger guided remediation.

Finally, look at knowledge. If a developer or an AI agent needs to understand your expectations for focus management, live regions, validation, motion, timing, labelling or error recovery, where does that guidance live today. Is it central, maintained and machine-readable, or is it scattered across wiki pages, slide decks and old audit reports.

The change is real, but human judgement still matters

None of this removes the need for human oversight. Accessibility is not a ‘lint rule’. It involves language, interaction design, cognition, trust, assistive technology behaviour and context of use. Automated checks can catch some failures. Design systems can prevent many more. AI can help teams apply patterns with much greater consistency. But lived experience still matters, expert review still matters and disabled user testing still matters.

That is not a weakness in the approach. It is the point of it. The goal is not to automate accessibility away. The goal is to remove avoidable errors earlier, free specialists to focus on harder problems, and give delivery teams a much better default starting point than they have today.

How AbilityNet can help

If your organisation is exploring AI-assisted design and development, this is exactly the moment to put the right foundations in place. AbilityNet can help you review AI components and high-risk journeys, carry out full WCAG audits where needed, run inclusive user research with disabled participants, and shape the broader accessibility strategy around your design systems, governance and delivery processes.
We are also helping organisations think through a newer question: how to make AI itself accessible, and how to use AI in a way that strengthens accessibility rather than weakening it. If you want expert help connecting design, development and accessibility in a more joined-up way, talk to us.

To explore support from AbilityNet, see our accessible AI integration and consultancy services, AI accessibility services and broader digital accessibility consultancy.

Talk to us about accessible AI integrations 

More from Robin Christopherson

Explore more of Robin's thinking on AI, accessibility, trust, governance and inclusion.

AI could make financial services more inclusive. But only if accessibility is part of the infrastructure

Published 27 July 2026. Why accessibility must be treated as core infrastructure if AI is to improve financial inclusion.

The end of the interface? What AI means for accessibility and inclusion

Published 13 July 2026. How conversational AI could reshape digital accessibility and the user experience.

AI skills are becoming critical infrastructure. Not optional learning.

Published 6 July 2026. Why AI literacy is becoming essential and what organisations must do to ensure inclusive outcomes.

The trust gap: why AI's edge cases matter to customer loyalty

Published 30 June 2026. Why accessibility and edge cases are critical to building trust in AI-powered services.

The delicious irony at the heart of trusting AI

Published 17 June 2026. A personal reflection on trust, accessibility and the unexpected ways AI can both help and hinder.

Executive briefings for senior leaders

Robin offers invite-only executive briefings exploring AI, accessibility, governance, customer trust, regulation and digital inclusion.

Contact us to discuss how a briefing can help give accessibility a place in your AI roadmap

See our range of AI integration services and contact us for more information.