AI Screen Reader · Aigenie Enterprises · 2026
Production-ready · waiting on funding
A screen reader that understands, for 285M people who can’t easily see a screen.
An AI screen reader. Hold one key, say what you want, and it reads, sums up or takes you there.
- Replaced 100+ shortcuts
- 1 key
- The wait we designed to
- 2s
- Contrast, top WCAG level
- 7.1:1
How this was measured: Targets set from what users told us. Contrast checked against WCAG 2.2. Every screen here is a recreation: the product name and branding stay hidden until launch.
In short
Listening to people who never see the screen, cutting a hundred shortcuts to one, and designing in sound.
- Role
- UX designer (sole designer)
- Team
- 2 engineers, PM, CEO
- Timeline
- Aug 2025 - Jan 2026
- Platform
- Web app, with a mobile version
- Status
- Working build, waiting on funding
My role
Two engineers, a PM and the CEO. I was the only designer.
What I owned
- The research visits, and the calls that came out of them
- Every screen, on desktop and mobile
- What it says and when: setup, confirmations, errors, sounds
Screen readers read a page top to bottom: every ad, menu and footer link. A “Buy now” button sounds like a footer link, and getting around means over a hundred shortcuts. We wanted to move from reading aloud to understanding.
Who it’s for
Two visits, two kinds of blindness.
- First visit: everyone had lost their sight later in life, and still carried a picture of what a web page looks like.
- Second visit: people blind from birth. Braille isn’t a tool for them, it’s their language, and voice is how they use a computer.
Everyone read braille. No formal tests: we took a working build to the people it was for.
The finding
Silence sounds broken.
Most answers took 5 to 8 seconds, one took 20. People drifted off, and some asked whether the internet was down. A sighted person sees a spinner and knows the app is working. There is no spinner in audio.
Users said they could live with 2 to 5 seconds, so we set 2 seconds as the limit. We hit it often, but a slow network can’t be designed away. So: what do you hear when the wait is unavoidable?
Try it
The same 7.5-second wait, twice
A sighted person sees a spinner and knows the app is working. There is no spinner in audio, so what lands below is everything the user gets. The tones play; the spoken lines are written out.
What the user gets
Nothing yet. Pick a run above.
| Wait | What the user hears |
|---|---|
| Right away | “Got it,” and a chime |
| Up to 2s | A soft thinking tone, no words |
| 2 to 5s | “Reading the page” |
| 5 to 10s | “Still working, almost there.” |
| Past 10s | “Taking longer than usual. Keep waiting?” |
| If it fails | What happened, and one next step |
Hard call 2
A shortcut per job, or one key for all of them?
My early designs still had their own shortcuts, and since everyone read braille, I even mapped commands onto the braille cell. I’m glad I never built it.
If one key already lets you ask for anything, what are the other shortcuts for?
- What it cost
- Power users lose years of muscle memory, and a request costs a sentence, not a keystroke.
- Why it was worth it
- People blind from birth told us the heaviest part of a screen reader is the number of commands. Space is the biggest key, and anyone finds it by touch.
Walk through it
One key, then a check before anything happens
A step-by-step recreation of one exchange. Your microphone is never used, and the spoken lines are written out here rather than read aloud.
What the user said
—
What it says back
Listening…
Step 2 is the whole point: anything that goes somewhere new gets checked first. Answer no and it takes the blame rather than making you feel like the problem.
- Deleting always asks. Reading never does. When it mishears it takes the blame, so you never feel like the problem.
- Interrupting is safe. It picks up at the start of the sentence, not halfway through one.
- Hands-free came from my own hands. Holding the key got tiring, so you can ask it to just listen until you say stop.
Sound
No vibration, no spinner, just sound.
A phone confirms with a buzz in your hand. A laptop can’t, so sound carries content, confirmations and errors.
Try it
A tone for each state
A laptop can’t buzz in your hand, so on desktop sound carries the confirmations too. Press one to hear it: these are recreated in the browser for this page.
No tone carries meaning on its own. Every one of these arrives with words too, because a sound you miss once is a sound you can’t scroll back to.
It names what it can’t do, too: “this PDF is images, not text — I can read it with text recognition, or go page by page.” Never more than two choices at a time, because you can’t scan back through what you heard.
The screen
The screen is for everyone else.
The screen is for low-vision users and whoever helps them: plain, and read in the order it speaks. Our blue failed on contrast, so I darkened it to #0051C2 for 7.1:1, the top WCAG level.
The same thing, three ways
On a phone, in public, and hands-free
Rebuilt from my wireframes. The screen matters most to low-vision users and to whoever is helping them, so each of these reads top to bottom in the order it speaks.
Voice control
Tap to talkSilent assistant
Type instead of speaking; replies still come as audio
Hands-free
Listening…Page 1 of 24
Hands-free needed no new button: you ask for it by voice, so the home screen stayed at one.
The hardest part left was trust. You can’t check a document was read right, so the warning tone marks passages the text recognition doubts, and key values get read back twice: “four hundred twenty dollars: four, two, zero.”
Learned
Twice I reached for impressive.
First I showed every feature. Then I worried one button looked too simple. Both times the people I designed for asked for less, and both times they were right.
But the thing I learned didn’t come off a screen. It came from watching someone wait in silence and begin to think the machine had given up on them.
A much larger group tested the one-button version afterwards. The numbers belong to the client; the gist doesn’t. People said they wouldn’t need another device in the house.
In short: the outcome
- Instead of 100+ shortcuts
- 1 key
- Home screen buttons
- 4 → 1
- The response target
- 2s
Where it stands: a working build, waiting on funding.