Can AI Agent Skills Help Developers Ship Accessible Code?

This is part one of a multi-part series on using AI agent skills to improve accessibility in code. Part two will put the Intopia Web Accessibility Skill to the test with real development challenges across Claude and Cursor.

For someone using a screen reader, a form with no labels isn’t just frustrating, it’s a dead end. For someone navigating by keyboard, a button that can’t be focused is a wall. These aren’t edge cases. They’re the everyday reality of the web, and vibe coding has the potential to make things worse.

Each year, WebAIM analyses one million home pages from some of the internet’s most popular sites using automated accessibility tests. In 2025, nearly 95% showed detectable failures, and those are only the issues a machine can catch. The true number is almost certainly higher. Now, as AI agents generate more of the code being shipped, those existing failures don’t just persist. They scale.

Describing what you want to build and letting an AI agent generate the code feels like it’s quickly becoming just… coding. But there’s a problem hiding in the training data.

Most model providers don’t fully disclose their training data, but public code repositories likely feature heavily. If so, the models behind AI coding agents may have learned patterns from a web that is already failing on accessibility.

As someone who’s completed many accessibility audits over the years, I see a direct correlation between the issues an AI agent produces and those of a typical web developer.

Clear accessibility acceptance criteria have always been one of the most practical ways to help developers ship accessible code. The difficulty has always been finding the right level of detail. What works for one team doesn’t always work for the next. A general list sitting in a knowledge base like Confluence sounds good in theory, but in practice, developers often forget to look at it.

In a world where AI agents are writing the code, does the same principle apply?

Can agents benefit from accessibility acceptance criteria just like human developers do?

Agent Skills were introduced by Anthropic in October 2025, initially as a Claude-specific feature. By December 2025, Anthropic released the specification as an open standard at Overview – Agent Skills, and adoption across the industry moved quickly.

A skill is a folder containing a SKILL.md file along with any supporting resources the agent might need. The SKILL.md itself is a plain text Markdown file you add to your project or AI agent configuration. When the agent starts a task, it scans short descriptions for each available skill to find ones relevant to the task at hand, then reads only those. This progressive disclosure keeps context lean and avoids chewing through tokens on guidance that doesn’t apply. Skills are not code. They’re plain language guidance, like a style guide for the agent.

At Intopia, we’ve been experimenting with large language models, combining them with our internal resources such as acceptance criteria, issue templates, test cases and training materials. Our goal has been to explore what’s possible and develop tools that help us work more efficiently, or that we can package and share with others.

The Intopia Web Accessibility Skill is one of those experiments. We’re releasing it as a free resource for anyone to download and try. The skill, along with all supporting references, is available for you to explore and use. Please note that it is still experimental and we’re keen for people to try it out and provide feedback.

The skill pairs a SKILL.md file with a library of supporting resources. When an agent is working on front-end tasks, it reads the skill first and then consults an INDEX.md file to find relevant guidance for the component it is building.

The skill is currently more prescriptive than we would typically be when working with human developers. This reflects the fact that we’re still testing and experimenting with how best to frame guidance for agents.

On one hand, the instructions need to be clear and forceful enough to guide the agent towards the correct implementation. On the other, like when working with people, the guidance needs to remain flexible enough to adapt to different contexts and scenarios.

Finding that balance is an ongoing area of research for us. We expect the skill to evolve as we learn more, and as the underlying models continue to improve.

For now, the scope is intentionally limited. It includes a small set of acceptance criteria covering the most common issues we see for each component, along with code examples for form elements, modals, tabs, and structural elements. This is enough to experiment with and see how it performs. We’ll expand the library over the coming weeks to include more content.

Let’s consider what happens when you ask an agent to build a contact form. Often it applies poor contrast to text and non-text elements like input borders, icons, and focus states. It skips semantic HTML, missing landmarks and list structure where they belong. And it tends to fumble validation entirely: errors aren’t associated with their fields, focus isn’t managed, and the form can fail silently in ways that leave keyboard and screen reader users stranded.

Now, if we apply a skill to guide the agent, it can look up each form element, read its accessibility acceptance criteria and refer to accessible code examples before it starts to build. This should help the agent make better choices as it codes, leading to a more consistent, accessible output.

As a quick illustration of the skill in action, here’s a single vibe coded prompt run through GPT-5.3 Codex in Cursor, with and without the Intopia SKILL.md file. This isn’t a controlled test. It’s a demonstration to show the difference the skill can make. Part two will test it more thoroughly.

• Multi-Step Contact Form – GPT 5.3 Codex (without SKILL)

• Multi-Step Contact Form – GPT 5.3 Codex (with SKILL)

Although this is a narrow data point, not a real finding,  it’s illustrative of the kinds of gaps the skill addresses.

Without the accessibility skill, even using a recent model like GPT-5.3 Codex, the agent made basic accessibility mistakes, especially around contrast, focus management, and validation scenarios.

With the accessibility skill, the agent considered accessibility as it reasoned, looking up what it could find to help make better choices. It ran the colour contrast script and checked the colours it selected, correcting ones that failed. It still made a mistake, not managing focus to the first invalid field on Step 3, but overall the generated code was in a much better state than without it.

Note, my testing here was timeboxed and not extensive. We’ll cover that properly in part two.

AI-generated code isn’t slowing down. Without accessibility guidance in the agent’s context from the start, that speed means more barriers shipped.

Today, a skill won’t eliminate that risk entirely or produce perfectly accessible code. What it does is force the agent to think about accessibility as it generates code, giving it concrete guidelines to work from. It’s no silver bullet, but could be a practical way to raise the baseline and get accessibility into the generation phase rather than the cleanup phase.

You can download the Intopia Web Accessibility Skill from our GitHub repository. It’s free to use, and we’ll continue updating the acceptance criteria and supporting references over the coming weeks.

In Part Two, we’ll test the skill more thoroughly across a range of models and development scenarios, looking at where it improves AI-generated code and where its limitations lie.

Want to embed accessibility into your AI-assisted development workflow? Get in touch with the Intopia team.