The macOS Accessibility API is a framework that allows one application to send keyboard input and read the contents of other applications. For dictation, it means the transcription engine can take the text it produced and type it directly into whatever you were working on — without passing through your clipboard or a synthetic keystroke.
How dictation apps use it
When you hold the push-to-talk key and speak, the dictation app goes through three steps:
- Transcribe the audio into text.
- Decide where the text lands. This decision is made the moment the key goes down, not when you release it — because the app needs to know which window to type into before it has any words.
- Insert the text using the Accessibility API if the target app supports it, or fall back to synthesised paste if it does not.
The Accessibility API is the direct route — it tells macOS "put these words into the text field that currently has focus". It is not a real keystroke (it does not travel through your keyboard settings or trigger keyboard shortcuts), and it is not a clipboard operation (it leaves your clipboard untouched and puts the original content back if it had to paste). This is why dictation into any app works the same way across your Mac.
When it falls back to paste
Some applications do not support the Accessibility API. This includes:
- Password fields in most apps, which block paste for security reasons.
- Very old or unsigned apps, which may not expose a text input interface to the system.
- Some terminal emulators and Unix tools, which expect real keystrokes rather than high-level text insertion.
- Sandboxed apps that have permission restrictions around input.
When an app does not support Accessibility API text insertion, the dictation app falls back: it copies the text onto the clipboard, sends a simulated ⌘V (paste), and then puts back whatever was on the clipboard before. This works in almost every app, but it is slower, and it means anything you had copied already is gone and has to be restored afterward.
The permission
To use the Accessibility API, an app must ask the system for permission. macOS enforces this at the kernel level — a process cannot use the API unless the user has explicitly granted it. The permission appears in System Settings under Privacy & Security. You can revoke it at any time, and revoking it breaks the app completely; it will have no way to type into other apps.
This is the same permission a screen reader uses, and the same one Sticky Keys and Voice Control rely on. It is not unique to dictation apps. When an application requests Accessibility access, macOS shows you which app is asking and what it can do — you make the choice, and you can always change it later. This is one reason why apps need your trust before they can become part of your workflow.
Special cases: passwords and restricted fields
One common limitation is that password fields block access to the Accessibility API even when the app has permission. This is macOS itself enforcing security — a password field is designed so that nothing can see or type into it, not even the system's own accessibility tools. This is correct behaviour; it means a malicious app cannot steal passwords by monitoring what the Accessibility API receives. The trade-off is that dictation does not work in password fields, and no amount of permissions can change that. When you need to type a password, you type it yourself or use a password manager.
Why this matters
Dictation tools are built on top of this system boundary. The speed, reliability and behaviour of any dictation app depends on what this API offers and what each operating system's version of it enforces. This is why a dictation tool can only promise exactly what the Accessibility framework allows — and why features that need real access to your actual keyboard or a hidden background listener are off limits. Understanding the Accessibility API's limits is understanding how to get the most from a dictation app.