Dispatches From The Internets

Fixing Accessibility After the Fact Is Too Late

At Ability Summit 2026, I had the pleasure of moderating a panel on a topic that feels more urgent by the day: how we prevent accessibility defects before they are 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.

Easy Data-entry Verification with a Web Component

Sometimes the simplest form pattern ends up being 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 can create expensive follow-up work. This week I released a small web component to handle that pattern cleanly: form-matching-fields.

Artificial Intelligence Has One Chance To Get Accessibility Right

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.

Building a general-purpose accessibility agent—and what we learned in the process

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.

AI companies will fail. We can salvage something from the wreckage

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.

Accessible faux-nested interactive controls

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.

AI-assisted coding transforms PDF to web app using NYS Design System

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.

Modern CSS Feature Support For Shadow DOM

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.

AI is locking people out. At Scale.

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.

The Incredible Overcomplexity of the Shadcn Radio Button

It’s just a radio button.

Paul’s teardown is a good illustration of how far modern front-end practice can drift from the simple, robust platform primitives we already have.

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Reading this reminded me of a pair of pieces I’ve linked to before: Making radio buttons and checkboxes easier to use and There can be only one: Options for building “choose one” fields.

We have spent an astonishing amount of time and energy overcomplicating a control HTML already gives us, often in the name of developer experience or styleability. More often than not, all we’re really doing is trading resilience for ceremony.