Everybody Is Vibe Coding. Here Is What That Does to Accessibility, and What to Actually Do About It.
Everybody Is Vibe Coding. Here Is What That Does to Accessibility, and What to Actually Do About It.
Okay, so I want to talk about something that has been on my mind constantly, and I want to do it the way I would if you and I were just sitting down and talking it through. No lecture, no scolding, no 200-page report. Just the truth about where we are, from someone who lives in this every single day.
I am a blind developer. I have been doing accessibility for eight years, since 2017. In that time I have tested products, trained teams, consulted, and built the tools, and I have done this work inside some of the biggest names in the field as well as at the small studio I run accessibility for now. I also build apps for Apple platforms for a living, accessible from the first line, so I am not just talking about this from the sidelines. I ship it. And I use a screen reader all day, every day, still in the weeds doing screen reader testing every single week. So when I tell you the ground is shifting under all of this, that is not a hot take. It is what I am watching happen in real time, from the inside.
I am also going to be on Main Menu, ACB Media’s technology show, talking about vibe coding with some friends. So I figured it was time to write the whole thing down in one place. What vibe coding even is, what it is doing to accessibility, everything I have built to deal with it, and most importantly, what you can actually do about it. Because that last part is the whole point. I do not want you walking away from this just feeling bad. I want you walking away knowing what to do.
First, what even is vibe coding
Let me back up, because not everybody knows the term, and that is fine.
Vibe coding is a name Andrej Karpathy coined in early 2025. It means building software by describing what you want in plain language and letting the AI write the code for you. You guide it by prompting and testing instead of reading every line yourself. In the fuller version of it, people do not read the code at all. If there is an error, they paste it back into the AI and it fixes it. They go off the vibes.
And honestly, I think it is amazing. I really do. People who could never ship software before are shipping real things now. A few years ago, making an app meant getting out Xcode and writing every line by hand, and it took forever. Now somebody can put an app together in an afternoon. That is a genuinely good thing, and I am not here to dunk on it or gatekeep it.
I will say clearly, I am not a vibe coder myself. I use AI to write my code, and then I actually review it, because I know what good looks like and I know what breaks. But that is me. The wave of new builders coming in does not work that way, and we have to deal with the world as it actually is.
Here is the problem nobody wants to say out loud
Accessibility is not a strength of AI. At all.
This is the part I really need you to hear, because a lot of people are quietly acting like accessibility matters less now, when the truth is the exact opposite. It matters more than it ever has.
The research on this is blunt. Large language models produce inaccessible code by default, and the newer, fancier models did not fix it. Study after study in 2025 found the same pattern: the interfaces these models generate ship with multiple WCAG violations right out of the box, the kind that stop a screen reader cold. AI is decent at a couple of things, like color contrast and basic semantic HTML. But it misuses ARIA, it misses anything dynamic, and it has no idea what it is actually like to use the thing with a screen reader. AI is not your accessibility expert. It was never trained to be.
So put the two pieces together. We have more people shipping more software faster than ever before, using a tool that does not prioritize accessibility in what it produces. Which means, day by day, the apps and sites we all rely on are getting less accessible, not more, even as there are more of them. And this is not just websites. It is mobile apps, it is all the AI experiences everyone is bolting on right now, all of it. If a real person uses it, it counts, and most of it was never checked by anyone who navigates the world the way I do.
What actually breaks, in plain terms
Let me make this real, because “inaccessible” is a vague word until you have lived it. Here is what I hit over and over in vibe-coded apps.
Buttons with no name. The AI throws an icon on something clickable and never labels it. A sighted person sees a little trash can. My screen reader just says “button,” and I have no idea what it does.
Everything is a generic box. Instead of a real button or a real heading, the whole interface gets built out of plain containers styled to look right. On screen it looks fine. To my screen reader there is no structure at all, no headings to jump between, nothing that announces what it is.
Focus that goes nowhere. You tap something and a dialog opens. Obvious if you can see it. But focus never moves there, so as far as my screen reader knows, nothing happened. Sometimes focus gets trapped and I cannot get back out.
Color as the only signal. The form field turns red to show an error, with no text and no announcement. So I submit the same broken form three times, because nothing ever told me what was wrong.
Custom controls that reinvent the wheel. The AI builds its own dropdown or slider from scratch instead of using the one the platform already gives you for free, and the homemade one has none of the keyboard and screen reader behavior the real one would have had.
None of this is exotic. This is the sign up, the login, the main thing the app is for. And none of it is hard to get right if somebody who knows what they are doing is in the loop. That is the whole catch. Somebody has to be in the loop.
The other half of the problem: the industry priced out the people who need it most
Here is the part that really bothers me, and it was a problem long before AI showed up.
Accessibility, as an industry, was never built for everybody. It was built for big companies with budgets. A full audit usually runs a few thousand dollars, commonly between 2,500 and 10,000. The services that put a real disabled person in front of your product run well into the thousands and are aimed at enterprises. If you are a solo developer or a small business, that is just out of reach. So you do nothing. Not because you do not care, but because the front door costs more than you have.
And doing nothing is getting more dangerous, not less. In just the first half of 2025, website accessibility lawsuits jumped about 37 percent over the same stretch the year before, with more than 2,000 filed, and most of them hit small businesses and e-commerce. There is no small business exemption. The demand letters alone ask for five to twenty-five thousand dollars to settle. So the people who cannot afford a 5,000 dollar audit are the exact same people getting hit with a 15,000 dollar demand letter. That is backwards, and it is cruel.
Now add the vibe coding wave to that. A whole new group of builders, most of whom have never used a screen reader and have no idea what one even is, shipping fast with a tool that does not do accessibility for them. They are not bad people. Nobody ever taught them. So if we hand them a 200-page WCAG document and a five-figure invoice, of course they are going to skip it. We have to meet them where they are.
What I built about it, because I got tired of waiting
So I stopped waiting for the industry to fix this and started building. I built it in two halves on purpose, because you genuinely need both.
The AI side: a team of accessibility agents
Since AI will not prioritize accessibility on its own, a group of us decided to make it. Together with Jeff Bishop and the Community Access folks, I helped build a team of accessibility agents that plug right into the AI coding tools people already use, Claude Code, GitHub Copilot, Codex, and Claude Desktop. They review the interface as it is being written.
The idea is that the accessibility work happens while you build, by agents that actually know what good looks like, instead of being something you bolt on at the end or after you get sued. Accessibility is not one thing, so it is not one agent. There is a lead that looks at your task and pulls in the right specialists, somebody for ARIA, somebody for keyboard behavior, somebody for contrast, for forms, for modals, for headings and structure, and more. The lead coordinates them, sorts out the findings, and gives you a real review right there in your workflow.
And here is the part I care about most: they are open source. Gatekeeping the fix would defeat the entire point. You can grab them and read exactly how they work at the accessibility agents on GitHub.
I will be honest with you about what this is and is not, because I always try to be. The agents are fantastic at catching the mechanical stuff while you build, the missing labels, the bad ARIA, the structure problems. That is real, and it is the part AI tools skip. But an automated check, even a smart one, still catches only a slice of what actually matters. It can tell you a button has no label. It cannot tell you that your whole checkout flow is impossible to finish with a keyboard, because finishing a flow is a human thing. A scanner does not get frustrated and close the tab. A real person does. Which brings me to the other half.
The human side: teardowns
The second half is the one I am most excited about, and it is the human part.
Years ago I really sat with something I had known for a long time from doing this work. Accessibility had become long, expensive, arduous, and intimidating, and that is exactly why people avoided it. It had quietly turned into a thing you only do when a lawyer makes you. That is not how it should feel.
I think accessibility should be personal, it should be effective, and it should be easy enough for somebody who genuinely wants to do right by their users but has no clue where to start. So that is what a teardown is. I take your product and I use it the way a blind customer actually would, with a screen reader, signing up, logging in, doing the main thing it is for. Then I tell you in plain terms where it works and where it falls apart, and the specific things to fix first. Not a scan a tool spits out. A real blind developer, using your product, showing you what happens.
It does not have to be a website either. I can tear down web apps, iOS apps, even AI chatbots and AI experiences. If you have an iOS app, you send me a public TestFlight link or the App Store link and I test it on a real device. If real people use it, I can use it the way they would.
And here is the part that should make this an easy yes. You do not have to take my word for what you are getting, because I publish teardowns in the open. You can read exactly what one looks like before you spend a dollar. Go see my teardown of ActiveCampaign, my teardown of Codex, or my teardown of Xcode Intelligence. That is the exact kind of clear, specific, prioritized read you get for your own product, except yours is private by default. If you want yours public to show your customers you actually care about access, that is your call, and we can talk about it up front.
Now let me be straight about what a teardown does and does not cover, because honesty is the entire point of this. A teardown is the screen reader and keyboard experience. It is me, a blind person, actually trying to use your product, so I catch the things that wreck that experience, the unlabeled buttons, the focus that goes nowhere, the flow you cannot finish without a mouse. What it does not cover is the purely visual stuff. Color contrast is the obvious example. I am blind, so I am not the right person to tell you whether your gray text on a white background is readable for someone with low vision. That is a real accessibility issue, it matters, and it is exactly the kind of thing a tool can measure precisely and a full audit will check. The accessibility agents I mentioned catch contrast while you build, automated checkers catch it, and an audit covers it formally. A teardown is the human layer on top of all that, the part the tools cannot feel. The trick is knowing what each one is for, and I will always tell you straight which one you actually need.
So here is what to actually do
Alright, this is the part that matters most. If you build things, here is the honest playbook, from the cheapest thing to the most formal.
Start by caring on purpose. The single biggest predictor of whether something is accessible is whether anybody decided it mattered before they shipped. The best accessible software I have ever worked on was built accessible from the first line, by people who chose to. That is always easier and cheaper than fixing it later.
Put accessibility into the way you already build. If you are coding with AI, get the accessibility agents into your workflow so the review happens as the code gets written. They are free and open source. There is no reason not to.
Use the automated tools, but know their ceiling. Run a scanner. Just understand it catches maybe a third of what matters, and the third it catches is the easy third. Do not let a green checkmark convince you a blind person can actually use your product.
Get a real human to use it. This is the step almost everybody skips, and it is the one that actually tells you the truth. That is what a teardown is for. It is the fast, affordable way to find out where real users are struggling, without a five-figure invoice.
Know when you genuinely need an audit. If you want full legal compliance, this is the one. An ADA concern, a compliance requirement, a contract where you have to prove conformance, all of that means you need a full audit, the formal report, every screen, every checkpoint, including the visual things a teardown does not cover. I will tell you that straight, and I will point you to it rather than sell you the wrong thing. A teardown is the smart, affordable first look. An audit is the legal-grade document. They are not the same, and most teams should start with the teardown and let it show them where the real pain is before they spend audit money.
If you want a teardown
Let me put the money in perspective, because this is where people freeze up. A full audit runs a few thousand dollars. A demand letter, the kind small businesses are getting hit with right now, asks for five to twenty-five thousand to settle. Against either of those numbers, a teardown is almost nothing.
Right now it is half off as a launch, no code to enter. A written teardown is 75 dollars instead of 149, and you get the findings on your key flows and the specific things to fix, in priority order. A teardown with a recorded screen reader walkthrough, me narrating your own product getting stuck, is 175 instead of 349, and that recording is the thing you hand your team, because hearing your product get stuck is a lot more convincing than reading about it. The launch price is only for the first 20 teardowns, and only a few of those spots are left, so if you have been meaning to do this, now is the moment.
So here is the one thing I would ask. Stop treating accessibility as the thing you will get to someday, because the someday version is the lawsuit version, and it is the most expensive and least kind version there is. You do not have to become an expert, and you do not have to do it alone. You just have to start small. When you are ready, you can book a teardown right here on Gumroad. And if you want the full picture of where this whole industry stands in 2026, I wrote that up in the state of accessibility and AI.
One last thing
I am not trying to corner a market here. I am trying to open one up. In an AI economy where anybody can build anything, I want everybody to succeed, the builders and the disabled people who deserve to use what they build. Those are not competing goals. They are the same goal.
The industry priced accessibility like a luxury. I have spent eight years proving it is a basic, and I am building it that way. If that is the kind of accessibility you believe in, come build it with me. And if you are not sure where you stand, just ask me. Tell me what you are building, and I will give you the truth about where it stands, no pressure either way.


I think that Brian Hartgen's article is completely accurate, but so is the article here.
What he describes is not, repeat not, what "vibecoding" is generally like, and pretending that a prompt such as he suggests is at all characteristic of what gets used by the uninitiated is to ignore "the work product" accurately characterized as AI slop that I keep encountering.
Taylor Arndt gives a clear definition of what he (or she) means by Vibecoding: "It means building software by describing what you want in plain language and letting the AI write the code for you. You guide it by prompting and testing instead of reading every line yourself. In the fuller version of it, people do not read the code at all. If there is an error, they paste it back into the AI and it fixes it. They go off the vibes." That does not describe, at all, the process that Brian Hartgen is talking about nor is it what's being decried.
Most of us who are developers seen AI aided code generation as a small miracle of sorts, but we also do as Arndt states and, "I use AI to write my code, and then I actually review it, because I know what good looks like and I know what breaks." That is the critical piece that is missing, entirely, from vibecoding as clearly defined for the purposes of this article.
The uninitiated doing what is described by the vibecoding definition laid out above leads to slop far more often than not. AI assisted code generation with the result being reviewed by those who are in a position to refine and correct is is not vibecoding.
I know nothing about this topic, so I am excited to learn, from you & others, that is why I am sending this.
https://leaseysocial.com/@brian/116811322825683619