Unless you’ve been living under a rock, you’ve heard the term vibe coding.

It doesn’t just allow you to ship code faster.

It can also ship inaccessible code, faster, and at scale.

Vibe coding is an AI-first, prompt-driven way of building software. Gone is manually writing and debugging your code, instead you guide an AI tool to generate code, revise, fix errors and repeat.

The idea is you prototype faster. and ship minimum viable products faster, generating UI components and glueing it all together.

The term "vibe coding" comes from Andrej Karpathy. His idea is you give the AI a lot of freedom and your oversight gets lighter.

His description is unusual … "it’s not really coding in the traditional sense. It’s more like I see stuff, I say stuff, I run stuff, I copy-paste stuff, and it mostly works".

"Mostly it works" ……. This sounds like the worst idea for developing software, the "she’ll be right" attitude of not putting much thought into what you’re doing.

But putting cynicism to one side and thinking optimistically can this really be the accessibility nirvana we’ve been hoping for? Will AI handle all the hard parts of accessibility?

Of course not.

Web accessibility’s been around for over 20 years. It’s a core part of web development that needs rigour and technical understanding to get the best out of websites and assistive technology tools and make them work effectively. Most of the world has laws requiring digital platforms to be accessible. And yet, accessibility still hasn’t become a default part of delivering quality software.

The gap between digital systems and disabled people’s difficultly using them remains. The gap isn’t narrowing its remaining.

And one of the clearest signs of this continuing gap comes from WebAIM and their annual reports. The 2025 report scanning the top one million homepages identified, close to 95% of homepages had detectable WCAG failures. Things like low colour contrast, missing alt text, missing form labels, empty links, empty buttons, and missing document language.

And this is pretty basic stuff. If the web is full of these inaccessible patterns, what happens when we build systems which remix from these patterns at scale?

AI trained on huge amounts of web content reflects the world as it is, and the world is messy.

If most real-world websites contain common accessibility failures, then AI-generated code isn’t magically immune to those failures. AI will produce generic solutions with all kinds of accessibility defects, unless you tell it otherwise.

It’ll miss labels and skip keyboard behaviour. It’ll sprinkle ARIA because it looks right. And it’ll create something that seems fine visually but collapses under screen reader and keyboard testing.

At the same time, the pressure to move ever faster is real. Y Combinator has publicly claimed that in their 2025 winter cohort, 25% of founders had codebases where about 95% of the lines were AI-generated.

And this is concerning. Y Combinator is the global startup accelerator. We’re talking about the future tech leaders of Silicon Valley and the creators of tomorrow’s digital systems possibly contributing to hastily built digital products which increase the digital inclusion gap.

But whether you love it or hate it, AI-generated code is here, and it’s not going away.

Instead of actively pushing against it, the question should be how do we use AI generated code and vibe coding without ending up with vibe quality?

Quality design doesn’t happen by accident.

Even Microsoft’s guidance on reviewing AI-generated code leans on a familiar theme. AI often defaults to generic patterns unless you enforce standards, review deliberately, and iterate with intention.

So, the guidance is don’t let AI ship code unsupervised.

If you’re going to use vibe coding responsibly for accessibility, you need incredibly robust guardrails.

You need to set boundaries. Define your component patterns, semantic HTML expectations and the shortcuts you refuse to allow. Make accessibility requirements explicit in all of your prompts.

Require keyboard behaviour, focus management, labels, and error handling, language attributes, and contrast.

And crucially add the required accessibility expert review before anything lands. And test the output with keyboard testing, screen reader smoke tests, and automated checks as a baseline.

Because if most of the web is still getting the accessibility basics wrong, "trained on the web" doesn’t mean "accessible by default".

It means you must actively steer, cajole and shape it to make it build not just quicker, but better and correctly.