Last week at Microsoft Build, Jessie Lorenz, Carie Fisher, and I gave a short talk on a question every AI-enabled product team should be asking: can your AI pass the accessibility test?
The core point was straightforward: AI does not fix a broken process; it accelerates whatever process you already have. If accessibility is already in the workflow, AI can help scale inclusion. If it’s not, AI will scale the same barriers teams are already shipping.
At Ability Summit 2026, I moderated a panel on a question that feels more urgent by the day: how do we prevent accessibility defects before they get baked into AI-assisted workflows and shipped at scale?
As AI accelerates how software and content are created, accessibility risks emerge earlier and propagate faster than traditional testing and remediation can handle. This panel explores what “shifting left” means in the age of AI, from evaluating foundation models and code generation for accessibility, to embedding inclusive intent directly into design and development workflows. Panelists discuss how AI-assisted design tooling, automated scanning, and remediation in engineering pipelines can work together to prevent defects before they ship. Drawing on internal and external perspectives, the session presents a closed-loop view of accessibility that spans creation, evaluation, and remediation at AI speed.
Sometimes the simplest form pattern is the one you repeat ad infinitum: “Type it once, then type it again.” We do it for password confirmations, email verification, and any flow where a typo creates expensive follow-up work. I released a small web component to handle that pattern cleanly: form-matching-fields.
This is a pointed reminder that AI trained on an inaccessible web will reproduce that inaccessibility at scale — unless we intervene thoughtfully and intentionally.
That’s the part too many people seem eager to hand-wave away. These systems are not arriving with some magically enlightened understanding of disability, inclusion, or accessible implementation. They’re being trained on the web as it is, which means they are taking all of its worst practices as truth.
If we want AI-assisted coding to improve outcomes rather than exponentially accelerate harm, accessibility must be foundational.
This post is a detailed and useful look at GitHub’s accessibility agent experiment.
It dovetails nicely with my post on identifying accessibility data gaps in codegen models and my follow-up on optimizing codebases for AI coding agents. The former argued that these systems are already biased toward reproducing the web’s accessibility failures; the latter argued that if we want agents to be useful, we need to give them clearer structure, better documentation, and better examples.
What I especially appreciate here is how grounded the whole effort seems to be. One takeaway is that you can’t just wave your hands and tell an LLM to “do accessibility”; you need concrete guidance, clear expectations, and solid examples. Another is that accessibility work is too contextual to treat as a simple linting problem. And, perhaps most importantly, this is a good reminder that if we want AI systems to help improve accessibility, we have to be intentional about the data, patterns, and codebases we are feeding them. Otherwise they’ll just automate the same mistakes faster.
Cory Doctorow offers a characteristically sharp critique of the AI bubble, but what I found most useful here is his framing of how these systems are actually meant to be deployed: not to empower workers, but to turn them into “reverse centaurs.”
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.
Eric Bailey walks through a clever pattern for getting the feel of nested interactive controls without sacrifice the platform’s semantics to get there.
In this piece, Eric digs into accessible name length, accidental activation, stacking context weirdness, and progressive enhancement too. That kind of thoroughness matters because patterns like this can go sideways in a hurry when folks cargo-cult only the CSS and skip the reasoning.
This is a compelling illustration of what becomes possible when a design system is structured well enough to be usable by both people and machines.
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.
Adobe has produced a tremendously useful resource for anyone working with Shadow DOM and trying to understand where modern CSS features actually stand in practice, not just in theory.
What I especially like here is the framing: not simply “supported” or “unsupported,” but whether a feature is actually advisable in Shadow DOM, how it crosses boundaries, and where browsers still disagree. That’s the kind of nuance you need when you’re building real components instead of admiring specs from afar.
An important and sharply argued framing of AI-generated accessibility failures as a civil-rights problem, not just a quality-control issue.
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.