Building Accessible Tools for a Nonverbal Brother with AI: One Non-Programmer's Open Source Journey

A developer with no programming background whatsoever used AI tools to build a complete suite of switch-accessible interactive tools and games for his brother, who lost the ability to speak nearly a decade ago. This story not only demonstrates the real-world power of AI-assisted programming — it shines a light on a corner of the tech industry that is too often overlooked: the people who genuinely need technology but are deemed "economically unviable."

A Decade Trapped in a Communication Dead End

The person at the center of this story is Ben, who has an extremely rare condition called TUBB4A-related leukodystrophy. He could walk and talk as a child, but the disease gradually took everything away. Today he can neither speak nor move his limbs. For years, his only way of communicating has been tilting his head left or right to indicate "yes" or "no."

The author posed a pointed question in the original post: "Do you know how many yes/no questions you have to ask someone every day to give them as much autonomy as possible? Hundreds." What Ben needed wasn't more yes/no choices — he needed real access: the ability to make his own decisions and express his own needs.

Due to the complexity of his condition, eye-tracking and head-tracking technologies don't work for him, and traditional AAC phrase boards can't genuinely engage him either. What Ben wanted was simple: to play games again and to choose what he watches on TV.

AAC (Augmentative and Alternative Communication) is a broad field encompassing tools and strategies designed to help people who cannot speak normally. Common forms include Picture Exchange Communication Systems (PECS), Speech Generating Devices (SGDs), and eye-tracking keyboards. However, most AAC solutions assume the user retains some precise form of muscle control — such as eye movement or finger tapping. For patients like Ben with severely limited motor control, the vast majority of mainstream AAC options present physical barriers. Switch access is the lowest-barrier interaction method in this space, requiring only that a user can trigger one or two switch signals (such as a head switch or sip-and-puff switch). Through a "scan and select" mechanism, users browse through options one at a time and confirm their choice. While slow, this method is often the only means of active interaction available to those with severe motor disabilities.

AI Lets Someone With No Coding Background Write Code

The turning point came when the author learned that AI could help write code — "even someone like me with no programming background" could start building better tools for Ben. When Ben used his switch device to select his favorite movie, Spider-Man 1, for the first time, that moment ignited the author's drive to keep building.

The author initially used a competitor to Claude, then switched after learning about Claude's improved capabilities — Claude is now one of his primary tools. Notably, AI plays more than just the role of "code generator" here. The author also uses it as a creative thinking partner for game design, writing Game Design Documents (GDDs) and spec sheets, and even helping run the nonprofit they founded, the NARBE Foundation.

This case is a prime real-world example of "vibe coding" in action: the developer describes what they need in natural language, and AI handles implementation, debugging, and iteration. Lowering the technical barrier means that people with needs but no technical skills can now solve their own problems.

Vibe coding is a concept popularized in early 2025 by researcher Andrej Karpathy, describing a style of programming that relies entirely on AI to generate code — where the developer barely reads or understands the underlying code. The developer expresses their intent in natural language; the AI generates, modifies, and debugs the code; and the human focuses on verifying whether the result matches expectations. This approach breaks the traditional premise that "you must know how to code to build software," though it has sparked debate around code quality, security, and maintainability. In high-stakes contexts like accessibility tools — where correctness is critical — the effectiveness of vibe coding depends heavily on the precision of the requirements and whether a real user (like Ben himself) is continuously involved in feedback and iteration.

A Reusable Engineering Approach to Accessibility

From an engineering perspective, the way this system was built offers valuable lessons. The author's development environment is VS Code with the Claude Code extension, and his workflow is worth examining:

Describing Requirements in Plain Language

The author describes in everyday language what Ben needs, and Claude Code handles building, debugging, and iterating based on Ben's real-world feedback. The entire process is driven by the user's actual experience.

Codifying Accessibility Standards in Markdown Files

This is the most reusable design in the entire approach. The team maintains files like ACCESSIBILITY.md in their code repository as "build rules." Claude Code references these files every time it generates a new game, ensuring all products adhere to a consistent accessibility standard. More importantly, anyone can use these same files to build their own tools — effectively turning "accessibility specifications" into engineering assets that AI can read and act on.

Storing accessibility standards as Markdown files in a code repository is fundamentally a "rules as code" approach. Traditional accessibility compliance typically relies on developers manually consulting external documents like WCAG (Web Content Accessibility Guidelines), which is easy to overlook during collaborative or fast-paced development. When these rules are written as context files that AI can read directly, every time a new feature is generated, the AI automatically applies them as constraints — effectively embedding the compliance review step into the development workflow itself. This is especially valuable for small teams or individual developers who don't have a dedicated accessibility engineer, yet still need to maintain consistent standards across every iteration. For other developers looking to build similar tools, these Markdown files are a ready-to-use engineering starting point.

Embedding AI Directly into the Product

AI isn't just used during development — it runs inside the product itself. Their real-time conversation tool uses Claude Haiku to generate suggested responses that Ben can select with his switch, allowing him to join real conversations rather than passively answering yes/no questions.

All games and tools run on a shared "scan and select" system controlled by the spacebar or Enter key, meaning any switch device capable of sending either of those two keystrokes can be used.

Completely Free and Open Source

The entire project is free and open source (MIT license), runs directly in the browser, and requires no registration or installation (streaming functionality is handled through a free browser extension). Resources include:

• Games platform: switchedgames.org
• Benny's Hub tool center: bennyshub.com
• Code and rules files: the narbehouse repository on GitHub

The author acknowledges that these tools are "economically unviable" — the population using switch devices is too niche and too varied. But he argues that's exactly why they need to be built. Today, Ben has a keyboard, a phrase board, and text messaging (the first time in his life he can send a text). He can search the web, browse any streaming platform to pick what he wants to watch, and play dozens of games that were co-developed with him.

What This Means for the AI Industry

This story goes beyond a heartwarming personal project. It raises a question worth the entire AI industry considering: when the technical barrier drops dramatically, needs that were once ignored as "too niche a market" finally have a chance to be met.

Commercial logic will never prioritize extremely niche, highly specific groups — but when individuals can use AI to build solutions themselves, "economic viability" is no longer the only measure that matters. As the author wrote in closing: "If even one person sees this and is inspired to build a tool or game for someone like Ben, it was worth it."

From the perspective of technological equity, the most profound impact of AI-assisted programming may not be making professional developers more efficient — it may be enabling caregivers, family members, and ordinary people who have never written a line of code to become problem-solvers themselves.