Accessible Voice Navigation for Websites

A voice assistant that can only be started by clicking a small circle in the bottom-right corner is not an accessibility feature. It is a feature that happens to use speech.

The difference matters for the people most likely to benefit from voice in the first place.

The launcher problem

Consider who genuinely needs hands-free control: someone with limited fine motor control, someone using a screen reader, someone with low vision, someone whose hands are occupied. Now consider what a standard chat launcher asks of them — locate a small target by sight, and click it precisely.

For a portion of your users, the entry point is harder than the task.

A wake word removes the entry barrier

Set a phrase per project and visitors can start a conversation by speaking:

"Hey Acme, take me to my orders."

Detection runs on-device in the browser. No session opens, no audio is sent anywhere, and nothing is transcribed until the phrase is actually heard. It is a local pattern match, not an open line.

Two honest caveats: it needs microphone permission, which the visitor grants once with a real browser prompt; and it currently works in Chrome and Edge. It is a Pro-plan feature. Setup is covered in voice activation.

Navigation that lands on real pages

Spoken navigation is only useful if it works every time. The failure mode is the agent inventing a URL:

// Without your routes, "take me to the near-me page" can become /nearMe. ai.enableNavigation(router); // With them, the model is constrained to paths that exist. ai.enableNavigation(router, [ { path: "/orders", description: "The visitor's past orders" }, { path: "/near", description: "Shops near the visitor" }, { path: "/account", description: "Account and contact details" }, ]);

Given the list, an off-list path is refused rather than followed into a 404. For a sighted user a wrong turn is a mild annoyance; for someone relying on voice as their primary input, it is a dead end that costs real effort to recover from.

Use your genuine route descriptions here, in the words a visitor would use — "shops near the visitor" is better than "NearbyStoresView".

Voice complements the keyboard, it does not replace it

Some things to keep true regardless:

• Every capability reachable by voice should still be reachable by keyboard. Voice is an additional path, never the only one.
• Do not trap focus in the widget. A visitor must be able to tab past it.
• Keep the text tab. Not everyone can speak, and not everyone wants to speak in a shared space. The same agent should be usable typed.
• Announce outcomes. Return a result from every handler so the agent can confirm what happened out loud — silence after a command is indistinguishable from failure.

ai.register({ goToOrders: { description: "Open the visitor's order history.", handler: async () => { router.push("/orders"); return { status: "opened", page: "orders" }; }, }, });

What about the transcript?

Anyone using voice is speaking aloud, often in a shared space, often personal details. Emails, phone numbers, card numbers and national IDs are stripped from transcripts automatically before storage. Names and street addresses cannot be reliably pattern-matched, which is what sensitive: true is for:

params: { name: { type: "string", sensitive: true }, street:{ type: "string", sensitive: true }, }

Your handler receives the real value; the stored transcript gets [redacted]. Redaction happens before the write, so the data is not visible in your dashboard, not visible to us, and not present in a backup. See privacy and redaction.

Worth stating plainly

Voice is not a substitute for the accessibility basics. Semantic HTML, proper labels, visible focus states, sufficient contrast and full keyboard operability all still matter, and no assistant compensates for their absence. Voice is a strong additional path for people who find pointing and typing difficult — which is exactly the population most poorly served by a click-only launcher.