One keypress to a voice conversation

Where this could work for other businesses

The obvious fit: any school, college, or employer with a genuine duty to make software accessible to a blind or low-vision user — worth saying once, then moving past it, because the real pattern here is broader than blindness.

IT helpdesks generally have a version of this problem: some piece of software is badly designed for a specific person’s needs, the vendor isn’t going to fix it, and the fix has to live around the software rather than inside it. Wrapping a clunky multi-step tool in a single launcher applies just as well to a colleague with limited dexterity who struggles with a mouse, or someone with a cognitive load issue who just needs fewer decisions between “I want this” and “this is open.”

Aged-care and assisted-living settings are a strong, less obvious fit — an elderly resident who can operate a single button but not a modern browser’s menu structure has exactly the same shape of problem this solved: too many small, unfamiliar steps standing between someone and something they actually know how to use once it’s in front of them.

Strip the accessibility framing away entirely and the mechanism is: wrap a piece of software you don’t control in a single trigger that performs the multi-step dance on the user’s behalf, with more than one way of finding the thing it needs to click so a vendor’s next redesign doesn’t break it outright. Any business supporting non-technical users through poorly-designed third-party software — a client portal, a benefits system, a hospital patient app — has a use for that same wrapper-and-fallback approach.

The problem

A blind student needed to talk to ChatGPT by voice, which sounds like it should be one tap away. It isn’t. Getting there meant opening a browser, finding the right page, and locating a small voice-mode button somewhere in a menu — three separate visual-navigation steps for someone who can’t see any of them. A sighted person does this without thinking. For someone using a screen reader, every one of those steps is a search.

It got worse because the target kept moving. ChatGPT’s own interface changes its button positions and labels periodically, which means a workaround built around “the voice button is the fourth thing you Tab to” quietly stops working the next time OpenAI ships an update — and the person who’d notice it broke is the person least equipped to troubleshoot it visually.

The goal

Get a blind student from “nothing open” to “talking to ChatGPT by voice” in one action, with no visual navigation anywhere in the sequence, and build it so it survives the app changing under it at least some of the time.

What it does

A single Desktop shortcut — or a keyboard combination she can press from anywhere on the laptop — opens ChatGPT fullscreen with voice mode already running. There’s no address bar, no tabs, no visual clutter for a screen reader to wade through, and spoken confirmations announce what’s happening at each step, so she gets the same “yep, it worked” feedback a sighted person gets just by glancing at the screen.

Getting the voice button pressed automatically turned out to be the interesting part, and there are two competing approaches sitting side by side in the project on purpose. The first simulates a fixed number of Tab key presses to reach the button — simple, but it only works if the button is still in the same position in the page’s navigation order. The second runs a small browser script that looks for the actual voice button by its on-page identity, with several fallback ways of recognising it, so a modest layout change doesn’t take the whole thing down. The second approach is the one actually relied on day to day; the first is kept as a fallback for when the browser extension itself isn’t available.

There’s also a maintenance guide written for whoever ends up supporting the laptop next — not the person who built this, someone else entirely — because an accessibility tool that only the original builder can fix has failed at its own job.

The build

This wasn’t built with an AI coding agent doing the heavy lifting — it’s simple enough that the real engineering was in the iteration, not the code. The build went through a real design pivot: the first instinct was to make the browser as stripped-down as possible (a minimal, tab-and-menu-free window) on the theory that less clutter is always better for accessibility. That instinct turned out to be wrong in one specific way — the more capable auto-detection approach behaves less reliably in that stripped-down mode than in an ordinary browser window kept fullscreen instead. The declutter goal was still worth keeping; it just needed a different way of achieving it than initially assumed.

The bigger lesson was about brittleness generally. Anything that depends on a fixed position — a tab count, a click coordinate — will eventually be wrong, because the thing it’s counting through is out of your control and changes on its own schedule. The fix wasn’t cleverer counting, it was giving up on counting altogether in favour of asking “is this the voice button” directly, with more than one way of answering that question so a single UI tweak doesn’t break everything at once.

Problems & solutions

Symptom: the keystroke-counting launcher stopped reaching the voice button after ChatGPT’s interface changed. Diagnosis: anything built around a fixed position in someone else’s UI is only ever one update away from breaking. Fix: switch the primary approach to recognising the button by its own on-page identity, with several fallback ways of identifying it, so a layout tweak degrades gracefully instead of failing outright.

Symptom: the more reliable auto-detection approach worked less consistently inside the stripped-down “app mode” browser window than expected. Diagnosis: the simplified browser mode chosen for its clean look wasn’t actually compatible with how the detection script needed to run. Fix: launch in an ordinary browser window, kept fullscreen instead of minimal, which preserved the clutter-free goal through a different mechanism.

Symptom: there was no way to tell whether a launch attempt had actually succeeded. Diagnosis: a sighted user gets that confirmation for free just by looking; a blind user gets nothing unless it’s said out loud. Fix: add a spoken confirmation at each meaningful step, so success — or failure — is something she’s told, not something she’s expected to notice visually.

Symptom: whoever eventually has to fix this when it breaks won’t be the person who built it. Diagnosis: a tool that only works if you already understand its internals isn’t actually accessible tooling — it’s just moved the accessibility problem onto whoever supports the laptop. Fix: write a separate, plain-language maintenance guide aimed at a non-technical helper, covering exactly what to check and in what order, distinct from the build notes meant for the original author.

The stack

Component	Why
PowerShell	Text-to-speech confirmations and the one-time desktop shortcut setup — both built on things already on every Windows machine, nothing extra to install
AutoHotkey	The fallback launcher, simulating the keystroke path to voice mode when the browser-script approach isn’t available
Tampermonkey	Runs the primary, more resilient approach — finding the voice button by what it is, not where it happens to sit that week

Results

The whole multi-step, visually-dependent path to a voice conversation collapsed into one action she can trigger from anywhere on the laptop, without needing anyone else in the room. The maintenance guide has already done its job once — being able to hand a non-technical helper a clear troubleshooting sequence instead of “call the person who built it” is the actual measure of whether accessibility tooling works, not whether it works on day one.

What’s next

Worth checking whether ChatGPT exposes any direct way to land straight in voice mode without needing a button at all, which would remove the fragile part of this entirely. A voice-activated launch — saying a phrase to open ChatGPT rather than needing even one keypress — is the natural next step if the underlying voice-command tooling is reliable enough to trust for something used daily.