DIY Accessibility: Adventures in Vibe Coding

When I attended the recent American Council of the Blind (ACB) Convention, one of my favorite sessions discussed vibe coding and its applications for accessibility. One of the ideas that particularly interested me was fairly simple: if something isn't accessible, you can potentially fix it yourself or build your own accessible version. For this piece, I wanted to discuss my personal experiences with vibe coding for accessibility as someone with essentially no coding knowledge, as well as what I think it might mean for accessibility more broadly.

If you're not familiar with the term vibe coding, it generally refers to using a large language model to write code on your behalf. This has expanded significantly with the introduction of AI coding agents. Instead of simply asking an AI to produce a block of code that you then have to figure out what to do with, coding agents can examine existing files, make changes, run commands, test their work, and attempt to correct problems themselves. In some cases, you can describe the program you want and have the AI build much of it for you.

From an accessibility standpoint, I think this is potentially very valuable. It allows a significantly larger number of people to attempt to create accessible software or correct accessibility problems without the advanced coding knowledge that would traditionally be required.

In my experience, the models I see people who are blind or have low vision using most often for coding are Anthropic's Claude and OpenAI's Codex. There are plenty of other options, including Google's Gemini, xAI's Grok, Moonshot's Kimi, DeepSeek, Qwen, and others. GitHub Copilot also provides an environment for AI-assisted coding and can work with models from several different developers.

I personally have essentially no coding experience. Before AI coding became practical, any ideas I had in the arena of software or game development generally stayed just that: ideas. I might know what I wanted a program to do or how I thought something should work from an accessibility perspective, but I didn't have the programming knowledge to turn that into working software.

I first started seriously testing the waters in February 2026. One problem I had encountered was accessing subtitles while watching online video. Traditionally, the solutions I was familiar with generally required having the actual video file and playing it in a compatible media player that could send subtitles to my screen reader. That's not always particularly helpful in the age of streaming.

My original idea was considerably more ambitious. I tried using AI to create a Firefox extension that could detect video playback and automatically synchronize subtitles with it. That didn't work reliably, so I eventually simplified the idea. Instead, I wanted a small program that could load a plain-text subtitle file and let me use a global keystroke to start subtitle playback alongside whatever video I was watching. Additional keystrokes could adjust the timing if the subtitles became misaligned.

I first worked with ChatGPT to create a software design document describing what I wanted, then gave that document to Gemini through Google AI Studio. Gemini developed a working Python program for me. Its interface wasn't accessible, but the keyboard commands worked and the program accomplished what I wanted. I could report bugs, ask for changes, and receive updated versions. The resulting code may not have been particularly elegant, but I suddenly had a program that solved a very specific accessibility problem for me despite having no idea how to write it myself.

A few months later, I gave that original Python script to ChatGPT and asked it to replace the inaccessible interface with one using traditional accessible Windows controls. It did so essentially in one attempt. What had originally taken extensive discussion and testing, and still resulted in an inaccessible interface, had now become a fairly trivial request.

I saw the same progression when I wanted a bespoke add-on for NVDA, my screen reader, that could perform calculations and convert values I copied to the clipboard. I described what I wanted in a couple of sentences. ChatGPT created a properly packaged NVDA add-on, including documentation and attribution. It required a few iterations, but most of the problems came from things I hadn't thought to specify in my original request.

These were useful projects, but they were also fairly small. Naturally, I wanted to see what would happen if I tried something considerably more complicated.

Over the past year or so, I've been playing a game using a combination of AI-generated visual descriptions and automatic optical character recognition (OCR). The game seemed like a particularly good candidate for an accessibility mod. There wasn't free character movement or another mechanic that would require me to design an elaborate accessibility soundscape. Most of what I needed was already available as text somewhere in the game. I simply needed that information to be presented properly to a screen reader user.

For this project, I decided to use Codex through the ChatGPT desktop app. Rather than asking it to immediately start changing things, I first described what I wanted from an accessibility and design perspective. I then asked Codex to examine the game files, determine how the game worked, and propose a technical approach for making it accessible.

This is where using an AI coding agent began to feel very different from my earlier experiments. Codex could explore the codebase itself rather than relying on me to supply individual files. It examined the game, identified how relevant parts of the interface worked, and proposed an accessibility framework. I could then tell it to implement that framework directly in a test copy of the game.

I kept the first request intentionally simple. I wanted focused items to be announced by the screen reader along with tooltips that consistently appeared with them. Codex created the accessibility patch and implemented those features successfully. With that first version, I was probably 70 or 80 percent of the way toward being able to play the game accessibly.

That result still amazes me somewhat. This was no longer a small Python utility built from a detailed description. The AI had examined an unfamiliar game codebase, figured out how the interface operated, understood the behavior I wanted from an accessibility perspective, proposed a way to implement it, and then made the necessary changes.

Since then, most of my work on the project has involved testing.

I play through the game, take notes on accessibility problems or features that still need to be added, and construct a detailed bug and feature request report. I often use ChatGPT to help organize the report so that the requested behavior and reproduction steps are as clear as possible. I then give it to Codex and have it update both my working copy and the accessibility patch.

I've now gone through that process more than 10 times. So far, Codex has generally been able to identify the problems I've reported and make the requested changes. In one recent example, a feature I requested introduced significant lag into the game. I described when and where I encountered the slowdown. Codex investigated, identified the underlying problem, and corrected it without simply removing the accessibility feature that had caused the problem in the first place.

That experience also taught me something important about vibe coding: not knowing how to program doesn't necessarily mean you bring nothing to the process.

Through my work at AFB, I've gathered a significant amount of accessibility QA and design experience, and I've found both extremely useful when working with coding agents. The AI may know how to implement something technically, but that doesn't mean it automatically knows what the best accessible experience should be.

I've found that the more precisely I can describe that experience, the better the results are.

For example, saying, "Make this game accessible," leaves an enormous number of decisions to the AI. Even saying, "When an enemy appears, read its name and description, then read each menu option as I focus it," still requires the AI to determine where all of that information exists in the game and how to identify it.

Instead, I asked Codex to include a debugging tool that lets me examine the text and interface elements available on a given screen. That means I can give it instructions more like this: when an enemy appears, read fields B, C, and D once. Do not read fields A, E, or F. Afterward, whenever the player changes focus, read fields G and H.

I don't need to understand the programming behind those fields. I simply need to understand what information they contain and how I want that information presented to the player.

This has probably been one of the most useful lessons I've learned from the entire process. I try to minimize the number of assumptions the AI has to make. I implement a few features at a time, thoroughly test them, and provide as much concrete information as I can when something isn't working. More complicated problems get their own focused requests instead of being buried among 20 unrelated changes.

I've also been pleasantly surprised by the accessibility of the vibe coding process itself. Both Gemini and ChatGPT have worked well for me with a screen reader, and I've found the ChatGPT desktop app and Codex quite accessible. The desktop app operates similarly to the website, and, as far as I've encountered, its controls are labeled and usable.

The primary accessibility annoyance I've encountered is in very long conversations, where my screen reader focus will sometimes end up on an earlier message. I then have to navigate by heading through my exchanges with the AI until I reach the current response. It's inconvenient, but fairly minor compared with the access barriers I encounter in plenty of other software.

There are, of course, limitations to all of this.

Cost is one. Advanced AI models require a significant amount of computing power, and heavy use can become expensive. I'm currently doing my work with a ChatGPT Plus subscription, which costs around $20 per month, and most of the updates I've requested for my game project have taken Codex somewhere between a few minutes and around 15 minutes to complete. More complicated software projects can require substantially more processing, and users doing heavy AI development may need considerably more expensive plans.

There is also the much more important question of what happens when someone who doesn't understand programming asks an AI to create software.

I can't independently look at the code Codex produces and tell you whether every decision is optimal. There could be a cleaner way to accomplish something. Poorly designed AI-generated code could also introduce security, privacy, performance, or maintainability problems that a nonprogrammer might not recognize.

The importance of those risks depends somewhat on what you're building. There is a substantial difference between creating a small utility for your own computer and deploying software that will handle sensitive information for thousands of people. Vibe coding doesn't eliminate the need for experienced software developers, particularly when creating production software.

Likewise, I don't think vibe coding is a fix for accessibility more broadly.

Developers should still consider accessibility from the beginning and test their software and services with people who use assistive technology. Asking users with disabilities to repair inaccessible products themselves is obviously not an acceptable accessibility strategy.

But as a supplement or a stopgap, I think vibe coding offers something genuinely new.

If there is a niche piece of software that few people who are blind or have low vision use, it may now be possible for one of those users to create an accessibility patch that would never have been commercially viable. If you have a highly specific need that no existing application meets, you may be able to build something for yourself. Someone with deep knowledge of an accessibility problem but no programming background can potentially bring that expertise directly to the development process.

That's the part I find most exciting.

I've only recently started truly exploring what vibe coding can offer, and I've already gone from having software ideas that stayed ideas to creating utilities, an NVDA add-on, and an accessibility patch for a game. I certainly wouldn't claim that this makes me a programmer. What it has done is dramatically lower the technical barrier between identifying a problem and being able to experiment with a solution.

For people interested in trying it, particularly those who already subscribe to one of the major AI services, the barrier to entry may be lower than it has ever been.

This is, of course, my personal perspective coming from a very specific place. I'd love to hear about your experiences with vibe coding. Have you found it useful? If you have programming experience yourself, does that change how you approach working with coding agents? If you'd like to share your experiences, leave us a comment on our socials.