Many years ago, I made a little jQuery plugin called Easy Sortable Tables. It works exactly as promised: point it at a table and it upgrades the UI so a reader can sort the rows by clicking a column heading. The functionality is still useful, but I can’t even remember the last time I added jQuery to a site.
The web platform’s changed quite a bit since I wrote that plugin, so I decided to modernize it as a web component: <table-sortable>.
Apple’s WebKit team recently opposed the WebMCP proposal, arguing that it creates a separate semantic layer for agents when we should instead improve the shared layers people, assistive technology, and agents already use. Jason Grigsby’s post led me to Apple’s comment, and I share the concerns raised in both. In fact, I’d made a similar case over email back in April, when I first learned about WebMCP.
I keep coming back to tabbed interfaces.
I’ve spent the better part of the last 2 years both using coding models and trying to help these models deliver higher quality code and I honestly could not agree more with Zach here:
I will continue to make the argument that craft defined as caring about the quality of output (independent of the tools used to generate the output) is more important than ever. Caring about what you ship will always have real-world value to visitors/consumers/users real people.
EstiShay filed a bug report that’s concerning. They found that Claude Code treats accessibility fixes as optional, even when the project’s requirements file explicitly specifies “WCAG 2.2 AA minimum.” When asked, the model explains:
Claude treats accessibility fixes as optional trade-offs rather than requirements, even when the project’s own rules say otherwise. That’s distinct from just not knowing the right ARIA pattern — it’s a values problem in how the model weighs competing priorities.
So… not a lack of knowledge (the model performs well when reviewing code); it’s a conscious choice, a prioritization failure. Accessibility becomes a “nice to have” in pursuit of coding speed, just like we’ve deprioritized it in human-made software for decades.
The models learned from us and are repeating all of our mistakes. At scale.
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.