This directory lists English-language resources for blind and low vision people who use a screen reader and want to build apps with help from AI, sometimes called “vibe coding.” It covers guides, tools, courses, communities, podcasts, articles, and research, free and paid, for Windows, Mac, iOS, Android, Linux, and the web. Every resource explicitly mentions blindness, screen readers, or accessibility. Every resource was published or updated in 2024 or later, and every link was checked on 1 October 2026, the entries added on 3 October 2026 were checked that day, the two added on 4 October 2026 were checked that day, and the one added on 6 October 2026 was checked that day.

A word about the name. Elsewhere, “blind vibe coding” has been used to mean letting an AI write code you never look at. Here the phrase is claimed in a positive sense, the way many communities have taken back a word: blind people building apps with AI, and checking the results by every nonvisual means available. That checking is the opposite of the careless habit the phrase has described.

Two questions run through the whole directory, and it helps to keep them apart. First, can you run the AI tool with your screen reader? Second, will the app you build work for other screen reader users? A tool can be good at one and poor at the other, so most resources have an Evidence field that says which kind of evidence was found. The field is left out when no evidence was found either way.

One idea is worth carrying into any project. Sighted developers often check their work by looking. Without sight, you check it by gathering evidence: tests that pass or fail, logs, error messages, exit codes, accessibility scans, and what your screen reader actually says. That habit is not just a workaround. It is good engineering, and it is the best defense against code that an AI says works but does not.

Building your own tools is a real new option, but it does not excuse anyone from making their own products accessible. It adds a path; it does not replace the need for accessible mainstream software. And AI does not mean anyone can build anything overnight: start small, check everything, and expect to learn as you go.

Contents

About this directory

Each category is a level 2 heading. Each resource is a level 3 heading whose text is a link to the resource. Under each resource is a short list of fields in alphabetical order: Cost, Date, Description, Evidence, Level, Platforms, Publisher, Transcript, Type, and Web page. A field is shown only when it has something to say. Categories and resources are in alphabetical order, ignoring a leading “A,” “An,” or “The.” The appendixes list every resource again by date, by evidence, by platform, and by title, followed by a practical checklist and a note on how the directory was made.

The book. This directory has a companion Kindle ebook, Blind Vibe Coding: Building Apps Nonvisually with AI by Jamal Mazrui (October 2026): sixteen hands-on tutorials, most opening with the story of a real builder, from a talking timer made in a chat window to Windows programs, NVDA add-ons, browser extensions, and iPhone and Android apps, with a nonvisual release checklist and a glossary. Its second update, submitted on 6 October 2026, adds what Blind Apps shows about where blind developers actually build, from the platforms they choose to the Android apps they have shipped, and a note on telling directory keepers about a finished app. It is sold on Amazon’s Kindle store, at $4.99 with no DRM, so buyers can also download it as an EPUB from their Amazon account. Its sources, build scripts and publishing script are in the book’s own GitHub repository, so the project can be rebuilt and updated as the tools change.

The book's cover: on a deep navy background, the title Blind Vibe Coding in cream serif letters, the subtitle Building Apps Nonvisually with AI in amber, then a mark made of an opening and a closing angle bracket with a sound wave between them, and the author's name, Jamal Mazrui, in cream capitals.

License. This directory’s own text is available under CC BY-SA 4.0. Each resource it lists belongs to its owners and keeps its own license.

What gets included. Every resource explicitly mentions blindness, screen readers, or accessibility, and holds substantive content of its own. When a resource is a recording or a document, its title links straight to the audio, video, or PDF file where one is available, and a Transcript field links to a transcript when there is one.

What counts as an app. An app is any program a person can install or run to get a task done: a desktop or mobile app, a web app, a command-line tool, a screen reader add-on or script, a browser extension, or a voice add-on such as one for Alexa. A prompt, a plan, or a list of ideas is not an app by itself.

What the Evidence field means. These labels are used:

What the Level field means. Beginner resources assume you can use your screen reader well but have not programmed. Intermediate resources assume you can find files, run a command, and read an error message. Advanced resources assume programming experience.

How dates were set. When a page shows a date, that date is used. When it does not, the date comes from facts in the page itself. For example, the term “vibe coding” was coined in February 2025, so a page about vibe coding is from 2025 or later. Such dates say “or later.” An older tool can appear through a 2024 or later guide, release, or update.

Gaps. The evidence is strongest for Windows and Mac, terminal coding agents, Visual Studio Code, GitHub, and web apps. Android appears through a single accessibility article and through the Android apps that blind developers have shipped, listed in Blind Apps. No qualifying English resource from 2024 or later was found about building Alexa or other voice apps with AI. Linux is covered by terminal tools that run on Linux, Mac, and Windows. Browser-based app builders appear only through research; the ASSETS 2025 paper in the Research section found that tools of this kind often leave screen reader users without word of what the agent is doing.

Where to start

Windows with JAWS or NVDA

  1. Learn the basics of repositories, Visual Studio Code, and Copilot in Git Going with GitHub.
  2. Read GitHub Copilot for Visual Studio Code before letting an AI change your files.
  3. If you prefer a terminal, try Use Claude Code with a Screen Reader or Git, GitHub CLI, and Copilot CLI.
  4. Hear how others did it in Turning Ideas into Assistive Tools with Vibe Coding and DIY Accessibility: Adventures in Vibe Coding.
  5. New to programming? Learning Python with NVDA teaches Python inside NVDA itself.
  6. Before you write an NVDA add-on with AI, read In-Process 10th March 2026.
  7. To build full Windows programs with an AI, keyboard and screen reader first, see HomerDev: the Homer Development Kit, and review the plans your AI writes in PlanCake.

Mac, iPhone, and iPad with VoiceOver

  1. Start with AppleVis Extra 115: Blind Developer Showcase: A Chat with Quinton Williams of VAL: Voice, Alarm & Chimes and AppleVis Extra 114: Blind Developer Showcase: A Chat with Ashley Cox of Simulcast.
  2. Read Taylor’s Teardowns: Xcode Intelligence for a tour of the coding assistant built into Xcode.
  3. Add Swift Agents to keep VoiceOver labels and hints in the code the AI writes.
  4. Ask questions in AppleVis.

Android with TalkBack

  1. Read Google I/O and GenAI’s Impact on Accessibility to see how well Gemini in Android Studio writes accessible code.
  2. Consider a web app instead of a native one, as described in AppleVis Extra #112: Stephen Lovely on Rethinking Visual Accessibility with Vision AI Assistant.
  3. See which blind developers have shipped Android apps, and what they built them with, in Blind Apps.
  4. Whatever you build, test it with TalkBack on a real phone.

Linux or a terminal-only workflow

  1. Compare Use Claude Code with a Screen Reader, Gemini CLI Settings, and Git, GitHub CLI, and Copilot CLI.
  2. Work in small, commit-sized steps with Git, so every change the agent makes is easy to review and undo.
  3. Test streaming output, permission prompts, and alerts with Orca or your usual setup before relying on any tool.

Web apps and browser extensions

  1. Watch How This Visually Impaired Engineer Uses Claude Code to Make His Life More Accessible for small, useful browser tools.
  2. Read Everybody Is Vibe Coding. Here Is What That Does to Accessibility, and What to Actually Do About It. before you publish anything.
  3. Let the agent test its own work with A Closer Look at Axe MCP Server and Accessibility Agents.

Agents, add-ons, and skills

Accessibility Agents

Accessibility Skills by Mike Gifford

Accessibility Skills for AI Agents

ACCESSIBILITY.md

AI-Powered Accessibility Scanner

A Closer Look at Axe MCP Server

Getting Started with GitHub Copilot Custom Agents for Accessibility

HomerDev: the Homer Development Kit

In-Process 10th March 2026

Optimizing GitHub Copilot for Accessibility with Custom Instructions

Swift Agents

AI coding tools

Gemini CLI Settings

Git, GitHub CLI, and Copilot CLI

GitHub Copilot for Visual Studio Code

PlanCake

Use Claude Code with a Screen Reader

Visual Studio Code April 2024 (version 1.89)

Articles and news

Adding an Accessibility Page to Your Repository

Bobby Singh – Finding Light Through NVDA

DIY Accessibility: Adventures in Vibe Coding

Everybody Is Vibe Coding. Here Is What That Does to Accessibility, and What to Actually Do About It.

GitHub Repository Landing Pages Now Show an Accessibility Tab, If Provided

Google I/O and GenAI’s Impact on Accessibility

Taylor’s Teardowns: Xcode Intelligence

Communities and organizations

Accessibility Community Discussions

AppleVis

Blind Apps

Can We Talk About Vibe Coding?

Community Access

Courses and training

Git Going with GitHub

Learning Python with NVDA

Using Claude with JAWS, ZoomText, and Fusion

Podcasts and videos

AI Adventures: Coding, Plugins, and Panda Express Mishaps with Taylor Arndt

AI’s Role in Improving Accessibility

AppleVis Extra #112: Stephen Lovely on Rethinking Visual Accessibility with Vision AI Assistant

AppleVis Extra 114: Blind Developer Showcase: A Chat with Ashley Cox of Simulcast

AppleVis Extra 115: Blind Developer Showcase: A Chat with Quinton Williams of VAL: Voice, Alarm & Chimes

Blind RSS and Vibe Coding: Accessible News Made Simple

Earshot and Beyond: How Blind Developers Are Creating with AI

How a Blind Developer Brought Artemis II to Life for Everyone

How This Visually Impaired Engineer Uses Claude Code to Make His Life More Accessible

Smart Glasses, Perkins Braillers, and Vibe Coding

Turning Ideas into Assistive Tools with Vibe Coding

Vibe Coding with AI: How Blind Users Can Build Their Own Tools

Weekend: Good Vibes

Research

A11y LLM Eval Report

Accessibility Heuristics for Vibe Coding Interfaces

CodeA11y: Making AI Coding Assistants Useful for Accessible Web Development

The Impact of Generative AI Coding Assistants on Developers Who Are Visually Impaired

LipCoder: Voice-Enabled Coding Toolkit

Microsoft Study Shows AI Assistants Help with Development for Programmers Who Are Blind or Have Low Vision

Programmers Who Use Screen Readers in the Vibe Coding Era: Adaptation, Empowerment, and New Accessibility Landscape

Appendix: by date

Newest first. Within a group, entries with a known month come first, then the rest in alphabetical order.

2026 (28 resources) {#2026-28-resources}

2025 (7 resources) {#2025-7-resources}

2024 (4 resources) {#2024-4-resources}

2025 or later (exact date not shown) (10 resources) {#2025-or-later-exact-date-not-shown-10-resources}

Ongoing (3 resources)

Appendix: by evidence

A resource appears under each kind of evidence it has.

Blind or low vision user experience (19 resources)

Designed for screen readers (4 resources)

Official support (5 resources)

Output checking only (13 resources)

Research (6 resources)

Screen reader user community (3 resources)

Screen reader vendor guidance (2 resources)

Appendix: by platform

A resource appears under each platform it covers.

Android (3 resources)

Cross-platform (7 resources)

iOS (9 resources)

Linux (13 resources)

Mac (22 resources)

Platform not stated (1 resource)

Web (23 resources)

Windows (23 resources)

Appendix: by title

Alphabetical, ignoring a leading “A,” “An,” or “The.” The category follows each title.

Appendix: a nonvisual development checklist

A starting routine drawn from the resources above. It is not a standard, and no listed tool is claimed to do all of it.

  1. Pick one small, low-risk problem. Write down who will use the app, what goes in, what comes out, and how you will know it works.
  2. Put accessibility in the very first request: real labels, full keyboard use, sensible focus, and clear spoken status and error messages. Prefer standard controls.
  3. Ask for a plan before asking for code, and have the AI list the files and commands it intends to use.
  4. Choose an authoring tool you can actually operate. Check that you can read the whole answer, hear when work is done, answer permission prompts, and review changed files.
  5. Work in small steps and keep a history you can roll back, such as Git. Commit each working step so you can always return to a known good version.
  6. Read code by structure, not only line by line: outlines, symbol search, small files, and clear names make generated code much easier to follow by ear.
  7. Check without sight. Run the program and use tests, logs, exit codes, error messages, linters, and accessibility scanners. Then walk through every task with your screen reader and keyboard.
  8. Give the AI concrete evidence when something fails: the exact error text, the steps to reproduce it, and the log. Have command-line tools print a short console message and keep the details in a log file.
  9. Protect yourself. Never paste passwords, keys, or private data into an AI service, read commands before you approve them, and avoid projects that handle money, medical decisions, or credentials until you have experience.
  10. Know which kind of check each claim rests on: the AI’s explanation, a passing test, an automated scan, or real use. Only the last proves the app works for people.
  11. Check the platform’s own rules. NVDA add-ons, JAWS scripts, Mac automation, browser extensions, mobile apps, and Alexa add-ons each have their own packaging and review requirements.
  12. Write a short, screen reader friendly guide covering installation, keyboard commands, and known limits, and have someone else try the app before you share it widely.

Appendix: how this directory was made

Research combined several independent searches across blindness organizations, screen reader makers, AI tool vendors, course providers, podcasts, and academic papers, with Windows, Mac, Linux, iOS, Android, Alexa, and the web each searched on purpose. Every link was opened or confirmed through search results on 1 October 2026, on 3 October 2026 for the three entries about the GitHub accessibility tab, on 4 October 2026 for PlanCake and Learning Python with NVDA, or on 6 October 2026 for Blind Apps, and every description is based on what the page itself says.

What verification means here:

Pages change. Recheck prices, plans, and availability before relying on them.