A Microphone-Denied Route for a Voice Enquiry Form
A voice enquiry form asks a visitor to speak. Some will refuse microphone access. Some have no microphone. Some will be somewhere quiet places are not possible. If refusal dead ends the form, you lose the enquiry. This article proposes a route that treats denial as a normal path, not an error. It is a design suggestion, and all examples are hypothetical.
Principle
Voice should be an option, never the only way in. The typed route should be reachable before any permission prompt and after any denial, with the same fields and the same outcome.
Permission-denied journey
Consider these states and what the visitor sees in each:
- Before asking: the form shows both choices side by side, record a message or type it. The microphone is not requested until the visitor chooses to record.
- Prompt pending: a short line explains why access is being requested, and that typing is available instead.
- Denied: the message says recording is not available and the typed box is open and focused. Wording should be neutral, not blaming.
- Previously denied in the browser settings: the prompt may not appear at all. The form should detect the failure to start recording and move to the same typed state, optionally mentioning that access can be changed in the browser settings if the visitor wants to.
- No microphone found: same typed state, with a message that no microphone was found.
- Recording started and then failed: keep anything already entered, offer to retry or type.
In every state, nothing the visitor has already entered should be lost.
Typed alternative acceptance card
Check each item as pass or fail:
| Check | Pass means |
|---|---|
| Visible before prompt | Typed option is on screen before any permission is requested |
| Denial handled | Refusing leaves the form usable without reloading |
| Focus | After denial, keyboard focus lands on the typed field |
| Same fields | Typed route asks for the same contact details and topic |
| Same destination | Typed enquiry reaches the same place as a recorded one |
| Message text | Neutral, says what happened and what to do next |
| Assistive technology | The status change is announced to a screen reader |
| Switch back | A visitor who denied can still choose recording later |
| Data kept | Previously entered fields survive the change |
Branching choices
If you transcribe recordings, consider showing the visitor the transcript so they can correct it, and treat the transcript as secondary to what they confirm. If you do not transcribe, say how the recording will be read, since visitors may wonder. If an enquiry needs a recording to be understood, for instance a spoken product noise, offer the typed route with a prompt for the same details, such as when the noise occurs.
Hypothetical worked example
Imagine a visitor opens the form on a shared device and presses Record. The browser asks for the microphone and they decline. The form replaces the recording area with a line saying recording is not available, and the typed box appears with the cursor in it. They type the same enquiry, add their contact details, and submit. The team receives it in the same queue as recorded enquiries, labelled only by how it was entered.
Stop conditions
Hold the release if denial reloads the page, empties fields, hides the typed box, requires a second click to find it, or puts typed enquiries in a different place from voice ones.
Acceptance checks
- Test denial, a previously blocked state, and a device without a microphone.
- Run the card with keyboard only and with a screen reader.
- Ask someone unfamiliar to refuse access and complete the form unaided.
- Record failures as gaps in the route, not as visitor mistakes.