Accessibility prototype
Reading email by voice when the screen is the problem
A working prototype that lets somebody manage two email accounts entirely by speaking and listening: read me the unread ones, reply saying thanks, forward that to Lisa. It runs today against simulated mail. It is published here as a documented prototype, not as a finished product.
- Product
- Voice-controlled email portal
- Work
- Interaction design, speech interface, command parsing
- Stack
- Browser Web Speech API, Flask, Python
- Status
- Working prototype against simulated data
An AZWebCorp accessibility prototype
01 — The problem
Email assumes you are looking at it
Every mainstream mail client is a visual interface. Managing a inbox means scanning a list, recognising a sender, clicking a row. If reading a screen is difficult — because of eyesight, because of a hand injury, because you are driving, or simply because you are sixty-five and the type is small — the entire workflow becomes something you need help with.
Screen readers help with reading. They do not give you a way to say reply saying I'll be there at four and have it happen.
This prototype explores what the interaction looks like when speech is the primary channel rather than an accessibility bolt-on.
02 — What it does
Seven things you can say
The interface is a microphone button, a running transcript, and audio. There is no inbox list to scan and no menus to navigate — which is the point. Everything is reachable by saying it.
- "Read emails from Phil" — reads the matching messages aloud.
- "Show unread emails" — lists what is waiting, by voice.
- "Reply saying thanks" — composes and sends a spoken reply.
- "Forward to Lisa" — forwards the current message.
- "Mark as important" — flags the message being discussed.
- "Delete that" — moves it to trash.
- "Search for budget" — finds messages by content.
03 — How it works
Speech in, speech out, language in the middle
Speech recognition and speech synthesis both run in the browser through the Web Speech API, so no audio leaves the machine for transcription. The recognised text is parsed into an intent — read, reply, forward, flag, delete, search — and that intent is what the server acts on.
That separation matters. The backend exposes ordinary operations on mail; the voice layer is a front end over them. It means the same operations could be driven by a different interface later without rewriting the mail handling, and it means the command vocabulary can grow without the server changing.
A small Flask service serves the interface and the operations together, which keeps the prototype to one process and no infrastructure.
04 — What is and is not done
It works. It is not finished.
Two email accounts can be switched by voice and every command above functions — against simulated mail, not a live mailbox.
Connecting real accounts needs OAuth for each provider, and the answer to delete that has to be trustworthy before anyone points this at an inbox they care about. There is also a real question about how a spoken reply is confirmed: reading a draft aloud and asking for a yes is slower than typing it, and typing is the thing this exists to avoid.
None of that is solved. What exists is a working interaction model, which is the part that had to be proven before the plumbing was worth building.
No client is named on this page and none is implied. It is an internal prototype.
Technologies used
- Web Speech API
- JavaScript
- Flask
- Python
- Command parsing
Want results you can check?
Tell us what you are trying to fix and we will tell you honestly whether we can measure it.