Dispatches From The Internets

Prompt and Circumstance

Back at Ability Summit, I moderated a conversation about shifting accessibility left in the age of AI. During that discussion, Yumeng Ma described a problem she’d encountered in her research: there wasn’t a magical prompt that made generated code accessible. The component mattered. The model mattered. And what we chose to measure mattered too.

That research is the subject of a paper I co-authored with Yumeng Ma, Jacob O. Wobbrock, Joe Devon, Michael Fairchild, Jennifer Mankoff, and Venkatesh Potluri: “Prompt and Circumstance: Evaluating Accessibility in LLM-Generated HTML Form Components”, for ASSETS ’26, the ACM SIGACCESS Conference on Computers and Accessibility.

Accessibility Assistant for Figma v53: From Design Decisions to Handoff

The Accessibility Assistant for Figma icon

In an internal analysis of accessibility bugs, a colleague found that roughly half could be traced back to design decisions. These were issues we should have caught earlier, before those decisions became codified in code and long before anyone encountered them in a shipped product.

That’s one of the reasons I started working on Accessibility Assistant for Figma. I wanted to help designers catch issues while they worked and help them build their accessibility knowledge along the way. Version 53 brings more of that work together, organizing annotations, assessments, issues, and handoff around projects.

Sortable Tables with Progressive Enhancement


(updated )

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>.

WebMCP Should Prioritize People over Agents

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.

“AI, make the website good”—zachleat.com

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.

LLM biased against accessible code (Claude Code issue #56079)

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.

Can Your AI Pass the Accessibility Test?

Title slide for Can Your AI Pass the Accessibility Test? with Carie Fisher, Aaron Gustafson, and Jessie Lorenz.

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.

Fixing Accessibility After the Fact Is Too Late

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.