EDIT: I suppose what I'm saying is that "The paid products Adam mentions are the pre-made components and templates, right? It seems like the bigger issue isn't reduced traffic but just that AI largely eliminates the need for such thing." is wrong. My hunch is that AI has the appearance of eliminating the need for such things.
They almost completely just give money back if it fails/sucks, and they are still coming out ahead.
Regarding the point about accessibility, there are a ton of little details that must be explicitly written into the HTML that aren't necessarily the default behavior. Some common features of CSS and JS can break accessibility too.
None of this code would obvious to an LLM, or even human devs, but it's still what's expected. Without precisely written and effectively read-only boilerplate your webpage is gonna be trash and the specifics are a moving target and hotly debated. This back and forth is a human problem, not a code problem. That's why it's "hard".
I would 100% of the time prefer to encounter the median website written by Opus 4.5 than the median website written by a human developer in terms of accessibility!
It's just… a lot of people don't see this on their bottom line. Or any line. My awareness of accessibility issues is the Web Accessibility Initiative and the Apple Developer talks and docs, but I don't think I've ever once been asked to focus on them. If anything, I've had ideas shot down.
What AI does do is make it cheap to fill in gaps. 1500 junior developers for the price of one, if you know how to manage them. But still, even there, they'd only be filling in gaps as well as the nature of those gaps have been documented in text, not the lived experience of people with e.g. limited vision, or limited joint mobility whose fingers won't perform all the usual gestures.
Even without that issue, I'd expect any person with a disability to describe an AI-developed accessibility solution as "slop": because I've had to fix up a real codebase where nobody before me had noticed the FAQ was entirely Bob Ross quotes (the app wasn't about painting, or indeed in English), I absolutely anticipate that a vibe-coded accessibility solution will do something equally weird, perhaps having some equivalent to "As a large language model…" or to hard-code some example data that has nothing to do with the current real value of a widget.
Internal tools and prototypes, both things that quality components can accelerate, have been strong use-cases for these component libraries, just as much as polished commercial customer-facing products.
And I bet volume-wise there's way more of the former than the latter.
So while I think most people who care about quality know you can't (yet) blindly use LLM output in your final product, it's completely ok for internal tools and prototyping.
I think people vastly underestimate just how much work goes into determining the correct set of primitives create a design system like Tailwind, let alone a full blown component library like TailwindUI.
This is probably a good thing. The web would be much better off with fewer design systems.
