Voice is finally competitive with typing for a narrow class of web tasks: asking where something is on a page, dictating a short note, confirming a step in a workflow. The part that is still broken in 2026 is when the microphone listens. Most browser AI assistants either sit there quietly recording under a wake word, or toggle the mic on with a button and leave it on. Push-to-talk is the alternative — the mic is off unless the user is physically holding a key. This post explains why that matters, how Chrome actually lets you build it, and where the interaction model wins over everything else on offer.
What push-to-talk means on the web
Push-to-talk on the web is a voice interaction model in which the browser records audio only while the user is pressing and holding a designated key (or button), and stops the instant the key is released. The term is borrowed from radio and VoIP — gaming headsets and Discord made it a household default — but it has been slow to reach AI assistants because ambient-listening pitches better. It nonetheless has one property that every alternative lacks: there is no window of time, however small, in which the microphone is live without an explicit, physical act by the user.
The three common alternatives, and what they concede
- Wake-word / always-listening. The mic is active continuously, running local keyword spotting. The promise is hands-free convenience; the concession is that the device listens full-time, and the keyword detector misfires.
- Toggle-to-record. A button flips the mic on; it stays on until the user clicks again or a silence timer fires. The mic window is intentional but long, and every tab you switch to during that window is inside it.
- Full-session capture. Some AI browsers and meeting extensions capture audio for the duration of an entire browsing session or call. Useful for transcription; a blunt instrument for a “where is the export button” kind of question.
Why always-listening is a privacy problem
The issue with wake-word assistants is not that the vendors are lying about recording — it is that the detectors themselves are unreliable. A 2022 study by researchers at Northeastern University and Imperial College London exposed eleven smart speakers from eight manufacturers to 134 hours of television dialogue and measured unintended activations. The devices misfired on everyday phrases — “I care about,” “it feels like,” “unacceptable,” “election” — and CBS reported an average of 19 false activations per device per day in typical home environments. Ten percent of those misactivations captured more than ten seconds of audio — long enough to contain a complete private sentence.
Those are smart speakers in a living room. A browser-based voice assistant has the same keyword-spotting problem, without the mitigating distance from the user’s mouth. It sits in the same browser as a banking session, a corporate email, a doctor’s portal. The risk surface is not theoretical — it is a UX choice made by the vendor.
Push-to-talk collapses the risk surface to zero. The microphone is not armed, idle, or sleeping between commands; it is off. There is no detector to misfire, no toggle state to forget, no session that lingers.
The Chrome permission model for the microphone
The mechanics matter because a claim of “push-to-talk” is only as strong as the code path that enforces it. A Chrome extension built on Manifest V3 cannot use DOM APIs — including MediaRecorder and getUserMedia — from its background service worker. The service worker has no window, no document, no access to hardware capture. To record audio in MV3 you have two options:
- Launch a regular popup or tab and record from there (visible, disruptive).
- Create an offscreen document, a hidden page with DOM access that only exists while a recording reason is active.
Serious voice extensions in 2026 use the second. The extension listens for a keyboard event in the page, creates the offscreen document on key-down, starts MediaRecorder, streams the audio to the model, and tears the offscreen document down on key-up. The lifecycle of the microphone is bounded, by construction, to the duration of the keypress.
The narrow activeTab permission works in tandem: the extension only reads the current page when the user explicitly invokes it, never in the background. Mic and page are gated by the same rule — no gesture, no access.
The 2026 voice-assistant landscape
A short, honest survey. None of the big AI browser launches are push-to-talk by default.
- Perplexity Comet and ChatGPT Atlas. Full agentic browsers. Voice input is optional and typically toggle-based — click to start, click to stop. Full-browser commitment, persistent profiles, broad action rights.
- Microsoft Copilot in Edge. Copilot-style sidebar. Voice is one of several input modes; recording is typically button-triggered.
- Chat-sidebar Chrome extensions. A crowded category. Most focus on text input; voice, when present, is button-toggled. Broad-host permissions are common, which is a separate problem.
- Clicky. Push-to-talk by design. The microphone is physically off unless the Alt key is currently held. The offscreen document is created on key-down and destroyed on key-up. Everything else — answer, halo, voice reply — is a consequence of that single rule. See the live demo.
For a longer discussion of how these products divide up on the perceive / understand / act spectrum, see our guide to agentic browser assistants. The short version: full agents trade safety for autonomy; assistants like Clicky trade autonomy for a much narrower attack surface.
Clicky’s Alt-hold mechanic, in detail
Why Alt, and not a custom shortcut?
- One hand, zero rebinding. Alt is present and reachable on every common keyboard — Windows, macOS (Option), Linux, external keyboards, laptop keyboards. It never needs rebinding across sites, never collides with a site’s own shortcut in a way that matters for the hold pattern, and is reachable with the thumb of the hand still on the mouse.
- No modal state. Other extensions use a click-to-start, click-to-stop pattern — a modal state the user has to track. A hold pattern has no state: the mic is on precisely when Alt is down. No edge cases, no forgotten recordings.
- Keyboard-accessible by construction. Any user who can operate the keyboard can operate Clicky; no additional chord, no mouse gesture, no voice activation needed. This matters under WCAG 2.2 success criterion 2.1.3 (Keyboard, No Exception): all functionality of the content is operable through a keyboard interface.
The full key-down / key-up loop: the content script captures the Alt keydown event, sends a message to the service worker, which calls chrome.offscreen.createDocument() with reason USER_MEDIA. The offscreen page requests the microphone with getUserMedia, starts MediaRecorder in streaming mode, and forwards audio chunks to a transcription endpoint in near-real-time. Alt key-up triggers a tear-down — the recorder stops, the offscreen document is closed, the transcript is passed to the language model along with the page screenshot and DOM description. The voice answer comes back via ElevenLabs; the halo is rendered by the content script on a selector the model returned.
Three jobs push-to-talk does better than anything else
Finding a specific element on a complex page
Salesforce, SAP, Workday, Jira, Notion — the modern SaaS dashboard is a wall of controls, most of them hidden in menus. Typing “where is the export button” into a chat sidebar is slower than asking aloud, and reading the answer is slower than seeing a halo land on the actual button. Push-to-talk here is measurably faster than every alternative because the fastest input you have is the one already in your throat.
Interrupting yourself without interrupting your work
You are in the middle of a task, your cursor is somewhere load-bearing, you have a quick question. A chat sidebar asks you to move the cursor and click into an input. Push-to-talk asks you to hold a key with your off-hand. The difference is the cost of context switch — one of the two interrupts your flow and one does not.
Keeping voice input off when you are not using it
This is the job wake-word models cannot do. Even if a detector has a false-trigger rate of 1 in 1,000 — which is optimistic — the mic is live every second of every browsing session. Push-to-talk is the only pattern where the microphone is physically inert by default. For anyone working in a regulated industry, a shared workspace, or a home with other people in it, this is not a nice-to-have.
Accessibility implications
Keyboard-only access is a core WCAG requirement. An assistant that demands a mouse gesture, a wake word, or a specific pronunciation fails that requirement in practice. Alt-hold is the opposite: any input device that can hold a modifier key — external keyboards, switches mapped to Alt, voice-controlled keyboards like Talon — works without modification.
Push-to-talk is not universally better for accessibility. Users with motor impairments affecting sustained key holds may prefer a toggle pattern; users who cannot see the keyboard may need the modifier remapped to something more reachable. A strong voice assistant should expose the trigger as a setting, with push-to-talk as the default and toggle as an option. Clicky’s roadmap includes a configurable trigger with tap-to-lock and double-tap sticky modes for exactly this reason.
For the adjacent case — low-vision users who benefit from spoken answers plus a visual target — the push-to-talk + halo combination is a genuinely useful layer on top of a screen reader, not a replacement for it. We have a dedicated post on this coming up; the short version is that voice output and DOM-anchored pointing are complementary to NVDA, JAWS and VoiceOver rather than competitive with them.
Frequently asked questions
Why Alt and not a custom modifier? I want something more distinctive.
Alt is the default because it is universally present and requires no configuration. A user-defined modifier is a setting we plan to expose; we chose to ship the opinionated default first rather than a blank settings screen.
What happens if I hold Alt by accident while typing?
Clicky requires a brief hold threshold before arming — a quick Alt tap for a menu shortcut does not trigger recording. The recorder also does not transmit an empty audio stream; if you released too soon to capture a phoneme, nothing is sent to the model.
Can Clicky work without the microphone at all?
Not yet. Voice is the primary input and the product is designed around it. A text-only mode is on the roadmap for environments where microphone access is blocked by policy.
Does push-to-talk mean Clicky can’t stream answers back?
No — the input is gated, not the output. The voice answer plays back after you release Alt, and you can interrupt it by pressing Alt again to ask a follow-up. The model remembers the previous turn inside the current browser session only.
How much of this is enforced vs. policy?
The offscreen document lifecycle is enforced by Chrome itself: MV3’s service worker cannot access the microphone, and the offscreen document we create to do it is destroyed on Alt key-up. There is no persistent hidden tab, no cached stream, no policy layer. The enforcement is structural.
Next up in our 2026 series on browser AI privacy: Chrome extensions that don’t track you — how to audit the ones you already have installed.