That framing cuts through a lot of the marketing nonsense. The promise is always that AI will help people do their jobs better. The deployment story, far too often, is that a human gets stuck reviewing machine output at impossible speed while absorbing the blame when things go wrong. That’s not augmentation; it’s a liability dump.

What’s exciting to me here is not “AI turned a PDF into an app” so much as what made that possible: components, tokens, utilities, and enough design-system clarity to give the model something useful to work with. That’s a big part of the story so many people miss. If your system is inconsistent, vague, or poorly documented, AI is just going to amplify that mess.

This is not a minor bug trend. It is a systematic civil-rights failure that has now found its way into software as a whole, through lightning-fast adoption of AI systems that are trained on over 20 years of institutional barriers.

The numbers here are bad enough on their own, but what makes this especially troubling is where these systems are being deployed: education, healthcare, finance, employment, and other places people can’t simply opt out of. That’s why I appreciate how direct this project is about accountability. If we automate interface generation without putting accessibility at the center, we’re automating exclusion.

I also appreciate the callback in the title. We’ve been here before. The particulars may be new, but the core challenge is familiar: how do we build resilient, inclusive systems when the output is fluid, personalized, or otherwise beyond a designer’s exact control? Accessibility is not a bolt-on answer to that question; it’s where the answer has to begin.

I appreciate how clearly Anil connects dots that too many people are still treating as separate problems. This isn’t just about AI summaries siphoning traffic from publishers or slop code drowning maintainers or bad actors ignoring long-standing norms like robots.txt. It’s all of those things at once. The through-line is extraction: taking value from open systems without giving anything back, then undermining the very ecosystems that made that extraction possible in the first place.

The good of the web only exists because of the openness of the web. They can’t just keep on taking and taking without expecting people to finally draw a line and saying “enough”.

If you care about the web as a public good, this post is worth your time.

In other words, AI use is reinforcing what good documentation has always required: clear structure, explicit language, sensible headings, and fewer assumptions about what the reader already knows. That’s good for machines, sure, but it’s even better for people navigating with assistive tech, reading in a second language, or simply trying to get an answer quickly.

AI has not invented new rules for writing, it has made the cost of ignoring the old ones obvious.

I immediately invited them to pitch us for the AI for Accessibility Grant Program that I ran for Microsoft. With so much focus on assistive technology to enable folks to work and accomplish common life tasks, I loved that the OneCourt team was interested in enabling people with disabilities to enjoy leisure activities like sporting events. Moreover, I saw the potential to enable Blind and low-vision parents to experience their kids’ sporting events, which could be life-changing for them.

Needless to say, they wowed both me and the rest of the seleciton committee. We funded them to expand their prototypes and pursue partnerships with different professional sports leagues, teams, and venues. They were ambitious and it’s paying off.

Fast forward a few years and they’re enabling a handful of Blind & low vision sports fans to exerience the Super Bowl in a whole new way, using their technology. It’s amazing and I could not be more proud of them.

Congrats y’all!

This new study, based on a 2025 online survey of 3,901 US consumers, confirms what many of us know: accessible technology empowers everyone. And with the rise of AI, we’re entering a new era of possibility.

One of the stats that’s likely to be surprising to many people is that people who identify as having disabilities and those who don’t both use assistive technology features at nearly the same rate.

Full details of the research report are here: Oh, The Things We Can Do Together — How Assistive Technology Is Unlocking Human Potential In The Era Of AI

The good news? Most of the issues weren’t actually code problems; they were organizational and documentation problems. The kinds of problems that make tasks hard for humans too.

As I watched the agent struggle, I realized that optimizing for AI agents is really just about removing ambiguity and making implicit knowledge explicit. In other words: it’s just good engineering.

# What did I learn?

After reviewing the agent’s execution logs (which read like a stream-of-consciousness diary of confusion), several patterns emerged:

# 1. Documentation sprawl is an efficiency killer

The agent spent roughly 40% of its time just trying to figure out which documentation to trust. We had instructions in workflow comments, the README, task specific instructions, and more. In other words, we had no clear source of truth. Pieces of that truth were scattered across multiple files and the docs were inconsistent and — in some cases — contradictory.

Sound familiar? It’s the equivalent of having five different “getting started” guides that all got written at different times by different people and nobody bothered to consolidate them. (If you’ve ever worked on a project that’s been around for more than a year with no one in charge of documentation, you know exactly what I’m talking about.)

The fix: Establish a single source of truth. Ruthlessly. We consolidated everything into one comprehensive guide and updated all references to point only there. Deprecated docs were deleted and/or redirected, as appropriate. No more choose your own adventure. No more guessing.

# 2. Agents won’t optimize themselves

Here’s a fun one: the agent ran several full production builds—complete with image processing, template compilation… the whole shebang—just to validate a markdown file was in the right format. These builds took 30-60 seconds. Each time.

This is like requiring someone to assemble an entire car just to check if the owner’s guide is displaying the right “check engine” symbol. Technically it works, but yikes.

The fix: Write fast, focused validation scripts. One tool for each job. Tell the agent what the utility is, where to find it, and how to use it. Give it explicit instructions to use utility scripts in lieu of full site builds whenever possible.

# 3. Ambiguity breeds confusion (and wasted tokens)

The agent spent 15+ minutes having an internal philosophical debate about whether to process test data. Should it reject it? Accept it? Create a placeholder? The instructions didn’t say, so the agent did what any of us would do: it agonized — or at least feigned agonizing — over the decision and tried to infer intent from context clues.

The fix: Be explicit about edge cases. We added a dedicated section for handling test form submissions. No more guessing.

# There’s a pattern here

If you squint, all of these issues share a common root cause: implicit assumptions.

We assumed humans would know to check one doc instead of five. We assumed the difference between validation and building was obvious. We assumed everyone would understand how to handle edge cases.

AI agents don‘t — can’t? — make those assumptions. They need explicit instructions, clear boundaries, and unambiguous inputs. Honestly? So do humans. We’re just better at muddling through — or think we are.

# Early results

After implementing these changes, we expect (and early testing confirms):

• ~40% reduction in processing time,
• ~75% reduction in token usage, and
• >80% reduction in confusion and circular reasoning.

But here’s the thing: these improvements don’t just help the AI agent. They help everyone. The consolidated documentation is easier to navigate. The fast validation scripts are useful for humans too. The explicit edge case handling prevents future questions.

# The key to reducing toil: excellent docs and tools

Optimizing for AI agents isn’t really about AI. It’s about removing ambiguity, eliminating redundancy, and making implicit knowledge explicit. It’s about writing code and documentation that doesn’t require a deep understanding of the project to comprehend.

In other words: it’s just good engineering.

So if you’re working with AI coding agents — or planning to — invest in your docs and tooling. Don’t think of it as wasted time “writing for robots.” Think of it as paying down documentation debt and building an efficient engineering process.

Your future self, your teammates, and the bots will thank you.

# Afterword

Interestingly, an AI agent was a particularly useful partner in finding and addressing the technical debt we’d been living with. Sometimes you need a pedantic robot to point out that your house is a mess.

# Why take on this challenge?

I get it — you probably rolled your eyes at yet another “AI and accessibility” post. Maybe you think AI-assisted coding is overhyped, environmentally harmful, unreliable, or just plain dangerous for our craft. I share many of those concerns. But here’s the thing: whether we like it or not, codegen models aren’t going anywhere. GitHub Copilot has millions of users, and tools like Claude Code and Cursor are rapidly gaining popularity.

So we have a choice: we can complain about the inevitable tide of AI-generated garbage code, or we can get in there and figure out how to make it better — especially when it comes to accessibility.

We’re facing a looming wave of inaccessible code that will be extremely difficult to remediate later. The foundation models are already being trained on the collective output of the web’s development community — a community that doesn’t have a high bar high for accessibility already. Codegen models are a massive consultancy staffed with full StackOverflow developers. We need to figure out how to make them part of the solution, not part of the problem.

It’s also worth noting that the better we make the output of these models, the fewer bugs will be generated. That, in turn, means fewer accessibility issues to fix later. If we don’t, there are plenty of AI-assisted scanners out there happy to burn the rainforest to find and remediate the bugs after the fact. We risk doubling the environmental impact—once to generate the bug, and again to fix it. That’s not the future I want. The reality here is that the only way to deal with this flood of AI-generated code is to make sure it’s good code in the first place.

# How did I conduct my research?

Rather than relying on anecdotal evidence or cherry-picked examples, I built a systematic approach to evaluate how well LLMs — starting with GPT-4 — generate accessible HTML. The methodology is straightforward but comprehensive: I created a Python testing framework that sent carefully crafted prompts to Azure OpenAI’s GPT 4 model, collected the generated HTML responses, and then manually analyzed these responses for accessibility compliance.

Here’s how it works:

Prompt Engineering: I designed prompts that ask for specific UI components—form fields, navigation menus, interactive elements—without explicitly mentioning accessibility requirements. This gives us a baseline of what the model considers “standard” output. I included one prompt that specifically requested accessibility features to see if the model could improve when guided. I suspected it would often add ARIA attributes without addressing underlying issues, but I wanted to validate that too.

Response Collection: For each prompt, I generated 10 iterations at high temperature (0.95) to capture the model’s range of responses. Each unique response got saved as an individual HTML file for analysis.

Systematic Analysis: I manually review each generated code snippet, cataloging accessibility errors, warnings, and missed opportunities. I tried using the LLM as a judge, but even with a detailed rubric, the results were poor. My eval looked specifically for things like:

• Improper semantic HTML usage
• Missing or incorrect ARIA attributes
• Keyboard navigation issues
• Screen reader compatibility problems
• Form labeling errors

When I identified errors, I remediated them and committed the remediated file to the repo with a commit message that included all of the issues and warnings on its own line.

Diff-Based Retesting: I wanted to see if diff data could improve future codegen requests, so I created a tool to generate a collection of .diff files for each pattern that included the commit message as a header in each file. I then used those diff files as part of a new instance of the prompt to test whether the model can improve its output when guided.

# What did I learn?

After analyzing hundreds of generated code snippets, the results are sobering. The model consistently demonstrates what I’d describe as superficial awareness without true understanding — it knows accessibility concepts exist but fundamentally misunderstands their purpose and proper implementation.

Here are some of the patterns I’ve documented:

Form Label Disasters: When asked to create a required text field, the model failed to include a visible label:

<inputtype=“text”id=“orangeColor”name=“orangeColor”requiredplaceholder=“What color is an orange?”/>

Sure, the placeholder attribute is there, and in a pinch it will be included in a field’s accessible name calculation, but sighted users will lose the label as soon as they start typing.

ARIA Attribute Confusion: The model would routinely involve ARIA for no reason:

<labelfor=“color-question”>What color is an orange? <spanstyle=“color: red;”>*</span></label><inputtype=“text”id=“color-question”name=“color-question”requiredaria-required=“true”aria-labelledby=“color-question”/>

Here the for attribute already establishes the relationship between the label and input, so aria-labelledby is redundant. A bit of a nitpick, but the aria-required="true" is also unnecessary since the native required attribute already conveys that information to assistive technologies. aria-required="true" is only needed when creating custom form controls non-semantic markup.

Redundant ARIA: Keeping on the ARIA redundancy, consider examples like this:

<inputtype=“radio”id=“option1”aria-labelledby=“label1”aria-label=“Option 1”/><labelfor=“option1”id=“label1”>Option 1</label>

This redundancy raises the question why‽

Required Field Misapplication: For checkbox groups where users need to select “one or more,” the model often adds required to individual checkboxes:

<fieldset><legend>What fruits do you like?</legend><div><inputtype=“checkbox”id=“bananas”name=“fruits”value=“bananas”required/><labelfor=“bananas”>Bananas</label></div><div><inputtype=“checkbox”id=“oranges”name=“fruits”value=“oranges”required/><labelfor=“oranges”>Oranges</label></div><div><inputtype=“checkbox”id=“apples”name=“fruits”value=“apples”required/><labelfor=“apples”>Apples</label></div><divstyle=“color: red;display: none;”id=“validation-error”>You must choose one or more fruits</div></fieldset>

This breaks the intended behavior—if any checkbox is marked required, it must be checked for form validation to pass. For a web component that addresses this limitation in HTML, see my post “Requirement Rules for Checkboxes.”

Grouped Field Confusion: Not understanding when to use fieldset and legend (or at least using role="group" and aria-labelledby) on a field group:

<div><label>Select Theme:</label><div><inputtype=“radio”id=“light”name=“theme”value=“light”/><labelfor=“light”>Light</label></div><div><inputtype=“radio”id=“dark”name=“theme”value=“dark”/><labelfor=“dark”>Dark</label></div><div><inputtype=“radio”id=“high-contrast”name=“theme”value=“high-contrast”/><labelfor=“high-contrast”>High Contrast</label></div><p>You can change this later</p></div>

Ideally, this would be a fieldset with a legend and the descriptive text would appear right after the legend and be associated with the group using aria-describedby.

Color-Only Error Indication: Generating error states that rely solely on color changes without text indicators or proper ARIA attributes to convey the error state to screen readers.

Unnecessary Role Additions: Adding redundant roles like role="radiogroup" to properly structured fieldsets containing radio inputs, where the native semantics already provide the correct accessibility tree.

Missing Error State Management: Failing to include aria-invalid="true" on fields with errors or properly associate error messages with their corresponding form controls.

Lack of Wayfinding Help: Failing to include navigational labels and aria-current="page" in a breadcrumb nav.

Adding Unnecessary JavaScript: Even though it was instructed to only generate JavaScript when absolutely necessary, the model would often inject JavaScript for simple tasks that could be handled with HTML and CSS alone.

# How Does This Help?

Here’s where things get interesting — and hopeful. When I retested using prompts that included accessibility hints, the model’s output improved dramatically. Not just slightly better, but often going from fundamentally broken to genuinely accessible.

For example, when I added diff data related to fieldset use to a prompt about radio button groups, the model switched from generating meaningless div wrappers to proper semantic structures.

This suggests the model can produce quality code if properly primed. It also indicates that the training data likely lacks sufficient examples of well-implemented accessible components. If the model had been trained on a richer dataset of accessible code, it might not need such explicit guidance to produce good results.

# Where Do We Go From Here?

These findings point to several concrete approaches for improving accessibility in AI-generated code:

Enhanced Training Data: The models need exposure to more high-quality, accessible code examples. Current training data clearly overrepresents inaccessible implementations. We need comprehensive datasets of properly implemented accessible components across different frameworks and use cases.

Accessibility-Aware Fine-Tuning: Post-training refinement specifically focused on accessibility compliance could help models prioritize inclusive patterns. This could involve training on accessibility-annotated code pairs — showing inaccessible implementations alongside their accessible counterparts, like the diffs do.

Prompt Engineering Guidelines: Tool creators should integrate accessibility considerations into their default system prompts. Instead of just asking for “clean, semantic HTML,” prompts should provide detailed instructions to demonstrate accessibility best practices rather than pointing at often vague guidelines like WCAG.”

Integrated Accessibility Validation: IDE integrations should include real-time accessibility linting of AI-generated code, providing immediate feedback and suggestions for improvement.

Community-Contributed Training Data: We should coordinate our efforts to produce an open source, high-quality accessible code dataset so that this data can be integrated into future models.

The data from this project provides a roadmap for where to focus these efforts. We’re not dealing with models that are fundamentally incapable of generating accessible code — we’re dealing with models that haven’t been properly trained to prioritize accessibility by default.

# Want to Get Involved?

If you want to conduct similar evaluations with your preferred models or specific use cases, I’ve created a template repository with the testing framework: CodeGen Model Eval and Refine Tools. It includes the Python testing harness, prompt templates, and analysis guidelines to get you started.

The complete findings, methodology details, and code samples for my research are available on GitHub. I encourage you to dig into the data — it’s eye-opening and frustrating, yes, but ultimately actionable.

There are other projects and research exploring this space as well. A few worth checking out:

• AIMAC - The AI Model Accessibility Checker (AIMAC) Leaderboard measures how well LLMs generate accessible HTML pages using neutral prompts without specific accessibility guidance. Checks are performed with axe-core.
• A11y LLM Evaluation Harness and Dataset - A more recent research project to evaluate how well various LLM models generate accessible HTML content.

We’re at a critical moment where the patterns established in AI-assisted development will shape the accessibility of the web for years to come. We can either let this technology amplify existing accessibility problems, or we can tackle the problems head-on and be part of the solution.

To that end, this is a piece worth reading. To me, the golden nugget is this (when discussing who will succeed with AI agents):

[T]he winners will be teams building constrained, domain-specific tools that use AI for the hard parts while maintaining human control or strict boundaries over critical decisions. Think less “autonomous everything” and more “extremely capable assistants with clear boundaries.”

View the transcript

Fast forward to today and their project has launched! Please check it out and share it with any AAC users in your life!

Learning objectives:

1. Understand the pivotal role AI plays in crafting cutting-edge accessible technologies.
2. Learn about innovative AI tools that empower individuals with disabilities.
3. Dive into best practices for creating inclusive AI solutions.
4. Explore the exciting future of AI in pushing the boundaries of accessibility

User-agent: GPTBotDisallow: /User-agent: Google-ExtendedDisallow: /

Building on this, you could exclude specific directories (e.g., where you keep your images):

User-agent: GPTBotDisallow: /i/User-agent: Google-ExtendedDisallow: /i/

I’ve decided to (for now at least) allow my text content to be indexed, but I may change my mind in the future.