What Accessibility permission actually gives an app on Mac
It is the most powerful switch in that pane, and macOS gives you no way to grant only part of it.
An app has asked for Accessibility access, the dialog looked serious, and you would like to know what you are agreeing to before you agree to it.
That is the right instinct. This is the most powerful permission in the Privacy & Security pane, and it is worth understanding once rather than approving by reflex every time.
What it grants
Accessibility access lets an app act as though it were you. Specifically, it can:
- Send keystrokes and clicks to any other app, as if typed or clicked.
- Read the interface of other apps — window titles, button labels, the text of fields, the structure of what is on screen.
- Move, resize and close other apps' windows.
The name comes from what the API was built for: screen readers and switch controls, software that has to operate the whole machine on someone's behalf. Everything else that needs to drive the interface uses the same door, because macOS provides no other.
What it does not grant
Worth being clear, because the dialog's wording frightens people into assuming more than is true:
- It is not file access. Reading your documents is Files & Folders or Full Disk Access, which are separate switches.
- It is not the camera, the microphone or the screen. Screen recording in particular is its own permission.
- It is not network access, and it does not let an app send anything anywhere it could not already.
Why ordinary apps need it
Most of the software asking for this is entirely legitimate, because macOS offers no narrower way to do ordinary things:
- Window managers — Rectangle, Magnet, Moom. Moving a window requires it.
- Text expanders and clipboard managers — typing into the app you are in.
- Launchers and automation — Keyboard Maestro, Hazel, BetterTouchTool.
- Screenshot and annotation tools that need to know what window you are on.
- Remote support software, which needs it for the obvious reason.
- Anything that has to drive System Settings, because parts of System Settings cannot be reached any other way.
How to decide
The question is not "is this permission dangerous" — it is, inherently. The question is whether this app has a reason for it. Four checks:
- Does its core function require driving the interface? A window manager plainly does. A weather widget plainly does not. If you cannot construct the reason yourself, that is the answer.
- Does the app say why, in its own words, before asking? Software that explains the request up front has usually thought about it. Software that throws the system dialog at you on first launch with no context has usually not.
- Is it signed and notarised, by a developer you can name? Right-click the app, Get Info, and look at where it came from — or in the Terminal,
codesign -dv --verbose=2 /Applications/TheApp.appnames the signer. - Is the permission narrow in practice? Some apps need it for one feature and work without it otherwise. That is a good sign, and it is worth checking whether you can simply not use that feature.
Granting and revoking it
System Settings → Privacy & Security → Accessibility. Or straight there:
open "x-apple.systempreferences:com.apple.settings.PrivacySecurity.extension?Privacy_Accessibility"
Switch the app on. Unlike some of the other lists in that pane, this one has a + button, so an app that has not asked yet can be added by hand.
Then quit the app and open it again. Some apps pick the permission up live; many do not, and the ones that do not usually give no sign of it.
Revoking is the same switch, the other way. Nothing is lost — the app simply stops being able to do the thing.
Audit the list occasionally
This is the one worth doing, and almost nobody does. Open that list and read it.
You are looking for two things: apps you no longer use, and apps you do not recognise. Software you deleted months ago can still be sitting there with the switch on, and a name you cannot place is worth looking up before you leave it enabled. Removing an entry costs nothing; you will be asked again if you were wrong.
The part that is genuinely unsatisfying
macOS cannot scope this permission. There is no way to grant an app the ability to scroll one window, or to control one other app, or to read window titles without also being able to type. It is one switch, and it is all of it.
That is a real limitation and it is worth knowing, because it means the trust you extend is not to a feature but to a whole application, and to every update that application ever ships. It is the strongest argument for granting it sparingly, to software you can name the author of, and for reading the list occasionally rather than never.
I write a small menu bar app called JumpDock, and it asks for this — for exactly one of its shortcuts, the one that has to scroll the Privacy & Security pane to reach a setting macOS gives no link to. Every other shortcut in it is a plain link and asks for nothing, so switching that one off leaves the app needing no permissions at all. That is the shape I would want from anything asking you for this.
