What it is
The macOS Accessibility API is a system framework that lets one app read from and write to the user interface of another app. It was built for assistive technologies — screen readers, voice control, switch control — and is the mechanism by which a dictation tool types into a field that another app owns.
When Voiacast finishes transcribing a sentence, the text needs to land in the field your cursor was already in. There are two plausible paths on a Mac:
- Write to the clipboard, then issue a paste keystroke.
- Use the Accessibility API to insert the text directly into the focused text field.
Both work. The second is what makes the experience feel native.
Why the Accessibility-API path is the right one
The clipboard path is invasive. Every transcription overwrites whatever the user copied last — a URL, a code snippet, a multi-line block of prose — and the user has to be careful not to dictate into a window where they were about to paste something else. It also produces a visible flash if the focused app pastes in a way that triggers a UI update.
The Accessibility-API path is invisible. The text appears in the field as if you had typed it. The clipboard stays untouched. The undo stack shows one insertion, not “paste from outside”. The flow is exactly the flow a person typing the same text would have.
The trade-off is the permission prompt. Apple gates the Accessibility API behind an explicit, per-app user grant in System Settings → Privacy & Security → Accessibility. The first time a dictation tool tries to type into another app, macOS prompts the user to grant the permission and opens the right pane in Settings.
What the permission allows
The permission grants the granted app the ability to read the accessibility hierarchy of other apps and to insert text and post synthetic events into them. It does not grant arbitrary system access, network access, or file-system access. It is the narrowest privilege that allows “type into the focused field”.
A user who is uncomfortable granting it has two fallbacks: don’t dictate (the Free tier still ships the transcription pipeline) or use a clipboard-paste fallback the tool provides. Voiacast prefers the Accessibility path and falls back to synthetic key events when it has to — those are a coarser path but do not require the same level of permission.
When the API path does not work
A handful of apps deliberately opt out of accepting Accessibility-API text insertion. Most modern editors, terminals, and browser inputs accept it; a few legacy native apps and a handful of sandboxed applications reject it.
The fallback path uses synthetic key events — the dictation tool fakes the keystrokes one by one, as if you were typing fast. This is more fragile than the API path (it depends on the input system honouring the keystroke order, which a few apps do not), but works in most of the edge cases the API path misses.
What this means in practice
The first time you dictate after installing, macOS will ask for Accessibility. Click “Open System Settings”, flip the toggle, and you are done forever. The same prompt is the price of every Mac tool that types for you — Magnet, BetterTouchTool, Rectangle, Keyboard Maestro, TextExpander all live behind the same permission.
If a dictation tool you are evaluating does not ask for Accessibility, it is almost certainly using the clipboard. That is a clue about the quality of the typing-into-focused-field experience you should expect.
See also
- Push-to-talk hotkey — the input side of the same flow.
- On-device dictation — the transcription side.
- Voiacast vs Wispr Flow — a comparison with a tool whose typing path is the same shape.
Last reviewed .