ShrtcutMac apps ask for Accessibility permission because macOS blocks any app from controlling other apps without your explicit consent. It grants the ability to read window information, move and raise windows, and post keystrokes and clicks — the capabilities that window managers, text expanders and automation tools are built on.
The prompt itself is unhelpfully vague. “Control this computer using accessibility features” sounds either trivial or alarming depending on your mood, and it gives you nothing to judge the request with.
This is a genuinely broad permission and worth understanding properly — both so you stop worrying about legitimate apps, and so you take the decision seriously for ones you are unsure about.
What the permission actually grants
Accessibility permission unlocks the macOS Accessibility API, originally built for assistive technology such as screen readers. Because assistive software has to be able to describe and operate any app on your behalf, the API is powerful by design. An app holding it can:
- Read the titles, positions and sizes of other apps’ windows
- Move, resize, raise and close those windows
- Post synthetic keystrokes and mouse clicks to other apps
- Read the contents of text fields and interface elements
- Observe global keyboard input, including while another app is focused
That last two are the ones that deserve your attention. An app with Accessibility permission is technically capable of observing what you type. This is why macOS gates it behind a manual toggle in System Settings rather than a simple in-app prompt, and why it has been progressively tightened since OS X 10.9 Mavericks.
Why so many ordinary apps need it
| App type | Why it needs Accessibility |
|---|---|
| Window managers | Cannot move or resize another app’s window without it |
| App and window switchers | Listing and raising other apps’ windows is gated |
| Text expanders | Typing the expanded text means posting keystrokes |
| Clipboard managers | Pasting on your behalf posts a synthetic ⌘V |
| Menu bar utilities | Rearranging menu bar items manipulates another process’s UI |
| Automation tools | Driving other apps is the entire product |
None of these can fall back to a lesser permission. macOS offers no narrower “just let me list windows” scope — it is the full Accessibility API or nothing. That bluntness is why the prompt feels disproportionate for an app that only wants to raise a window.
How to judge whether an app deserves it
The permission is all-or-nothing, so the decision has to be about the app, not the scope. Reasonable questions:
- Does the core feature actually require it? A window switcher does. A note-taking app almost certainly does not. If the reason is not obvious, that is a signal.
- Is the developer identifiable? A real company or named developer, a working support address, a privacy policy that says something specific.
- Is it signed and notarised? Notarised apps have been scanned by Apple for known malware and are tied to a Developer ID that can be revoked. Gatekeeper warnings are worth heeding.
- Does it need the network? An app that reads your keystrokes and talks to a server deserves far more scrutiny than one that does neither.
- Does the privacy policy address this permission directly? Vagueness about the most invasive thing an app does is telling.
Granting, checking and revoking
Everything lives in System Settings › Privacy & Security › Accessibility. The list shows every app that has asked, with a toggle each. Turn one off and the app loses the capability immediately — typically it keeps running with its main feature disabled. Use the − button to remove an entry entirely.
Reviewing that list occasionally is a good habit. Apps you uninstalled can linger, and it is the clearest single view of which software can drive your Mac.
When permission is granted but nothing works
A common failure: the app is ticked in the list but still behaves as though it has no permission. macOS ties the grant to a specific copy of the app binary, so moving it between folders, replacing it, or updating it outside its own updater can leave a stale entry pointing at the old copy.
The fix is to select the app in that list, remove it with −, then add it again with + — or relaunch and re-grant when prompted.
Why App Store apps rarely ask
Apps distributed through the Mac App Store must run in Apple’s App Sandbox, and sandboxed apps cannot use the Accessibility API to control other applications. There is no entitlement that unlocks it.
This is why so many window managers, switchers and automation tools are sold directly by their developers rather than on the App Store. It is not a shortcut around review — the capability those apps depend on is simply unavailable under sandbox rules. It also means the App Store is not a useful filter for this category, so judging the developer matters more.
Frequently asked questions
Is it safe to give an app Accessibility permission?
It depends entirely on the app. The permission itself is a normal part of macOS, but it is broad — it allows observing keystrokes and controlling other apps. Grant it to software from identifiable developers whose core feature genuinely requires it.
Can an app with Accessibility permission read my passwords?
It is technically capable of observing typed input, which is why the permission is gated behind a manual toggle. Whether an app does so comes down to trusting the developer — prefer apps that are notarised, and treat network access plus this permission as a combination worth scrutinising.
How do I remove Accessibility permission from an app?
Open System Settings › Privacy & Security › Accessibility, switch the app off, or select it and use the − button to remove it. The capability is withdrawn immediately.
Why does my app still not work after I granted permission?
macOS ties the grant to a specific copy of the app, so moving or replacing it can leave a stale entry. Remove the app from the Accessibility list with −, then add it back with +.
Why do Mac App Store apps never ask for this?
App Store apps must run in the App Sandbox, which blocks the Accessibility API for controlling other apps. Tools that need it are distributed directly instead.
The short version
Accessibility permission is macOS’s single switch for “this app may control my computer.” It is coarse, it cannot be narrowed, and plenty of ordinary utilities genuinely need it. Judge the developer rather than the prompt, prefer notarised apps, be extra careful with anything that combines this permission with network access, and audit the list now and then.