The Best Of The Internets

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.

Accessibility in the End of Deterministic Design (Again)

The framing Anna Cook uses for her talk is an important one: accessibility isn’t something generative interfaces will magically solve; it’s the groundwork we need in order to make those systems trustworthy at all.

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.

Making keyboard navigation effortless

I’m very excited by focusgroup: a declarative way to handle a bunch of keyboard-navigation patterns that currently require a lot of brittle JavaScript.

This is exactly the sort of thing I want to see the platform absorb. We’ve spent years rebuilding common interaction patterns with roving tabindex, focus management, and piles of event handling code. If the browser can take more of that on, we get lighter pages, more consistent experiences, and fewer opportunities for developers to get keyboard support wrong.

The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages

The latest WebAIM Million is a sobering reminder that, at scale, the web is getting more complex faster than it is getting more accessible.

There are a lot of grim numbers in here, but the one that really sticks with me is how many of the same, eminently-fixable issues continue to dominate year after year. We’re still talking about contrast, missing labels, empty buttons, and missing alt text. In other words, this is not a story about edge cases. It’s a story about fundamentals.

Under the hood of MDN’s new frontend

This is a fascinating look at how MDN rebuilt its frontend around server-rendered HTML, web components, and a clear understanding of where interactivity actually belongs (and how to deliver it).

I particularly appreciated how plainly this post describes a mismatch a lot of teams create for themselves: wrapping largely-static content in an app shell, then shipping a pile of JavaScript just to re-assert what the server already knew. MDN’s new approach feels refreshing, despite being grounded in age-old best practices: Keep the content first-class, treat interactivity as optional (and isolated), and only ship what the page actually needs.

There’s a lot to like here, but more than anything I love seeing MDN embrace an architecture that’s truly aligned with the platform it documents.