Stop Vibecoding Screen Readers — fireborn

fireborn

Stop Vibecoding Screen Readers

Published on June 8, 2026

There's a trend on Android right now that is going to get someone hurt. Hurt in the sense of a blind person picking up their phone in the worst possible moment and finding out the thing they depend on to interact with the world has decided to just not work.

TalkBack forks are everywhere. New projects every few weeks, each one full of promises. More like VoiceOver. Faster gestures. Better verbosity. Less latency. Some of them even deliver on one or two of those things. But every single one ships with bugs so obvious, so embarrassing, so easily caught by a developer who knew what they were doing, that there is only one explanation for how they got out the door.

The developer had no idea what they were building.

The Symptoms Are Obvious

Focus lands in the wrong place after a list scroll. Custom actions fire out of order. The reading cursor jumps on edit fields. Braille output drops characters under load. Explore by touch stops registering on the first pass after the screen turns back on. These are the first five things you do when you pick up your phone. A developer who knows the accessibility stack catches these before they ship. Explore by touch has timing quirks that are completely predictable once you know they exist. Screen buffer refresh rates interact with gesture dispatch in ways that are documented, known, and entirely manageable if you have spent any real time in the framework. Anyone who had would have them on their mental checklist.

These developers are prompting for code they do not understand, feeding it into Android Studio, patching compilation errors, and shipping. The AccessibilityNodeInfo tree, gesture dispatcher conflicts, threading models — they have not thought about any of it, because the LLM handled it, and the LLM does not know what it does not know. Neither do they. So the bugs ship.

Having the LLM write the tests fixes nothing. The LLM writes tests for the behaviour it thought it was implementing. It misses the same things it missed the first time. Tests written by the same system that wrote the code confirm the code does what the LLM thought you wanted. That is the least useful information available.

Trust Is a Technical Requirement

You need to be able to trust a screen reader the way you trust your eyes.

Your eyes are not a tool you evaluate before trusting. You do not glance at a doorframe and wonder whether your visual cortex got it right. You just know. A screen reader has to earn that same automatic trust, or it is not doing its job.

A screen reader that might mis-focus means manually verifying after every interaction. One that drops content means never being sure whether that notification actually didn't come. One that behaves inconsistently means second-guessing your own device constantly. It is exhausting. It is demoralizing. And it is the direct result of someone shipping software they did not understand into a context where people have no fallback.

Either the screen reader reports the state of the interface accurately and reliably, or it is not a screen reader. It is a screen reader shaped object that fails at the one job it exists to do.

Be Honest About What You Built

The readmes say "improved TalkBack experience" and "designed with accessibility in mind" and "feedback welcome." Feedback welcome. As if the people filing issues about broken focus management are doing the developer a favour, rather than the developer having failed them before the first install.

If you would not be comfortable saying "an LLM wrote this" in the readme, you should not be releasing it. That discomfort is your own judgment telling you something is wrong.

Blind users are installing these things in good faith, hitting these bugs in real life, and finding out the hard way. Every single one of those people trusted the developer not to waste their time and compromise their access. That trust was not earned and it was spent anyway.

I Understand the Appeal

If you have spent years watching TalkBack stagnate, watching Google treat accessibility as a checkbox, watching features break between releases and stay broken for months while the bug tracker collects dust — the idea that you could sit down with an LLM and have something that seems to work in under an hour feels like a revelation. You do not have to wait for Google. You do not have to file another bug that goes nowhere. You can just build the thing.

The LLM cannot build this thing. It has read the documentation. It can generate code that compiles and runs and appears to work in a demo. It cannot feel that the focus behaviour is wrong. It cannot notice that something is slightly off about the way the reading cursor moves through a conversation list — the kind of thing that is hard to articulate but immediately obvious to anyone who has navigated conversation lists with a screen reader for years. It produces code evaluated...