Many All of us are coding with AI these days. There is a lot of momentum; code is being produced at lightning-speed, and at immense scale. While many people get quite excited about the prospect of seemingly endless possibilities this development seems to hold, there’s a lot to unpack here:
As much as we’d like to think of coding agents or AI assistants in general as smart, eloquent problem solvers - in the end, they are probability machines. They return the statistically most likely response to your question or proposed problem, out of the massive data set that is the internet.
This sounds great in theory and has a lot of benefits, especially for coding, where recognizing patterns and reproducing logic is a highly demanded skill.
But when it comes to fixing accessibility issues or creating code which doesn’t introduce any new ones, there is a problem with our dataset: it’s full of accessibility issues and inaccessible patterns.
Existing Codebase
The WebAim One Million report looked at the one million most popular homepages and found accessibility issues on 96% of them, only using automated testing tools (which can only detect a fraction of the existing issues).
The most common issues were insufficient color contrast, missing alternative texts and labels, empty links and buttons as well as missing document language.
And these are the homepages of the most popular webpages, typically the most cared for pages, as they attract the most visitors.
With our data source providing such flawed information, expecting the coding agents to produce accessible code by default, would be very optimistic.
New Era: Shipping at lightning speed
Github user stats reveal not only a drastic increase in the amount of code being pushed to the platform (PRs increased by +23%, commits by +25.1% compared to the previous year), and previously unseen rise in new users (36 million new users in 2025!), but also show that the percentage of code which has been either AI generated or AI assisted has skyrocketed over the last two years.
When we are generating new code with AI, we are reproducing existing (inaccessible!) patterns. On top of this, according to WebAim, “Home pages are getting larger and more technologically complex at an alarming rate, making accessibility more difficult to achieve and maintain”.
The speed and sheer volume of this phenomenon is truly overwhelming. To ‘fix’ this (at scale), we need better systems and governance. The use of AI will not magically fix overnight, what we quietly eroded over decades.
“AI does not repair broken systems. It multiplies them.”
(Anna E Cook)
So how can we turn this around?
Shift left: how to incorporate Accessibility
Accessibility should be part of the digital product cycle for all disciplines. The earlier we incorporate it, the lower the costs, efforts, the smoother and faster usually the delivery. But what does that mean when it comes to AI?
Instruct your agents well
Your biggest lever is shaping the code as it is generated, rather than trying to catch problems after the fact. To do so, your coding agents need clear instructions. These can come in different formats.
Agent.md
The Agent.md (or claude.md) will be loaded into every session. Provide concise instructions here which are always applicable. In regards to accessibility, this could be something like “semantic HTML by default”, “WCAG 2.2 AA compliant”, “apply A11y skill for presentation layer files”.
Skills.md
Skills are loaded when the agent recognizes a task matches it. Skills can be particularly powerful in helping you improve accessibility patterns, as they can be quite specific.
When crafting an accessibility skill.md, here are a few things to look out for:
- Clearly define when the skill should be used, which files or areas of the product it should and shouldn’t be applied to and how it should be communicated that the skill is active.
- Use your own documentation or design system as the highest priority source of truth, or reference other resources you deem trustworthy
- Clear rules work very well: providing instructions, and even decision hierarchies explicitly can help reduce ambiguity: e.g. native HTML element → native HTML with attributes → ARIA only if nothing native covers it. This is the actual WAI-ARIA authoring rule, and spelling it out stops agents from reflexively sprinkling
role="button"on things that should just be<button>. - Besides positive examples, you can also document constraints and clear ‘don’ts’ (e.g. “do not use raw hex values when semantic tokens exist”)
- You could ask for a justification whenever ARIA is added outside a native element to surface any potential over-engineering
There are different approaches to using agent skills, depending on the size and complexity of your operation. There could be benefits in having different, very specific skills for different areas of accessibility. The idea being, that the more narrow a skill is, the more precise it can solve a problem.
However, if you are just starting from zero, don’t over complicate it. Start small and iterate.
Incorporate Accessibility in your prompts
Already include accessibility requirements in your prompts. Specifically ask to include accessibility consideration into the development of new features or refactoring of existing ones. Be specific and critical. How can accessibility be improved? Is there a more inclusive way to do this?
Digging deeper with socratic prompts, or asking the coding agent “What would you need to know in order to solve this problem effectively?”, can also help you uncover gaps and improve proposed solutions.
You can use this tactic at any stage of the product delivery cycle, of course - to challenge the product requirements or success criteria, specifications, expand the automated test coverage or uncover areas for manual testing.
AI is great - but not the answer to all (accessibility) questions
There are some benefits, sure.
But also, there are a lot of false promises and “solutions” that are simply too good to be true. If someone is claiming their tool will fix all your accessibility errors with a single prompt / click of a button, that’s a big red flag.
Be careful with “AI Audits”
Since automated tests can only ever detect a fraction of the existing accessibility issues, it’s also highly likely that using AI to automatically find, and then directly open PRs to fix issues will not be the silver bullet it sounds to be. It can however be one step in a layered process which also includes manual testing, fixing and reviewing.
Summary
Accessibility is a human concern, and humans are beautifully diverse and complex. And while some parts can be automated, some need human solutions, too.
Especially the nuances that go beyond automated accessibility testing are what’s very difficult to simulate with AI. There are a lot of different assistive technologies and ways to configure and use them. People get creative to find ways to make a broken, inaccessible web work for them.
Let’s be mindful in using the massive power of AI in our day to day endeavours to improve the state of the web accessibility, forge guardrails and hone our skills.
