What macOS Accessibility permission actually allows

Accessibility is the permission that lets an app control your Mac the way you do: read the buttons, fields and windows of other apps, and send clicks and keystrokes as though you had made them. It is one of the broadest grants macOS offers, which is why the dialog is worded so seriously. It is also the only way several ordinary features can work, so the useful question is not whether to ever grant it, but which app gets it and for what.

What the grant covers

macOS exposes an accessibility layer that describes the interface of every running app in a structured way: this is a button, this is a text field, its value is such and such, this window is at these coordinates. It exists so that assistive technology can describe and operate apps it did not write. Anything granted Accessibility can use that same layer.

In practice, an app with the permission can do four things.

It can read the structure of other apps’ windows: the labels, the values in fields, which element has focus. It can send synthetic input: clicks at a point, a keystroke, a paste. It can move, resize and rearrange windows belonging to other apps. And it can observe that you switched apps or opened a window, as an event rather than as a picture.

That is enough to do useful work and enough to do harm, which is why the grant is per app and revocable in one place.

What it does not cover

Three separate permissions are often confused with this one, and knowing the boundaries tells you when a request is out of proportion to the feature.

Input Monitoring is the permission to read keyboard and other input events globally, including in apps that are not the one reading them. Accessibility can send input; Input Monitoring can watch it. An app that needs to notice a key combination while another app is in front asks for this one, and there is more on it in what macOS Input Monitoring permission is for.

Screen Recording is the permission to capture what is on screen as pixels, including window titles of other apps. Accessibility gives structure, not pixels. An app that wants a picture of your screen needs this instead.

Full Disk Access is unrelated to input entirely. It lets an app read protected locations such as Mail storage, Messages and other apps’ containers. Nothing about controlling the interface requires it.

An app that asks for all four at first launch is asking for the whole Mac. Each request should map to a feature you can name.

How to see and change what is granted

Open System Settings, go to Privacy and Security, then Accessibility. The list shows every app that has asked, with a switch for each. The switch being on means the app has the grant right now.

Three things are worth doing in that list, ideally today rather than after something goes wrong.

1. Read the whole list. Apps you uninstalled may still be listed, and apps you granted years ago for a feature you no longer use are still holding it.
2. Turn off anything you cannot explain. If you cannot name the feature the permission enables, switch it off. The app will ask again if it genuinely needs it, and you will find out what for.
3. Remove stale entries. Select an entry and use the minus button to take it off the list entirely.

Changing the switch usually takes effect immediately, though some apps need to be quit and reopened before they notice. macOS will not let an app grant itself the permission or flip the switch on your behalf; the toggle requires your password or Touch ID.

When a request is reasonable

Some features genuinely cannot work without it, and refusing simply means the feature does not run.

Window management is the clearest case. Moving and resizing another app’s windows is exactly what the accessibility layer is for, and there is no alternative route.

Anything that types for you is the second case. Text expansion, dictation that lands words at the cursor, and pasting into a field in an app that is not the one you are using all require sending synthetic input into another app.

Automation tools are the third. Anything that clicks a button in another app on your behalf is using this permission by definition.

The reassuring pattern is a request made when the feature is first used, with an explanation of what it enables, rather than a dialog at launch before you have done anything.

A worked example of the boundary

It helps to see where the line falls in an app that sits close to it. Ledge is a shelf at the top of the screen: drag a file up to the notch, or the top center on a Mac without a notch, and it stays there until you take it somewhere.

Its global shortcut, Option-Space by default, needs no permission at all. It is registered as a system hotkey rather than by watching your keyboard, so the app is told only that the combination was pressed. Nothing else about your typing reaches it. That difference is the subject of how to add a global shortcut without extra permissions.

One feature does use Accessibility: auto-pasting a file path into a terminal window, which means sending a paste into an app that is not Ledge. That is a real use of the permission and there is no way around it. So it is asked for the first time you use that specific feature, not at launch, and everything else keeps working if you decline.

That is the shape to look for in any app. A named feature, a request at the moment of use, and the rest of the app functioning if you say no. The wider checklist is in what permissions a file shelf app should never ask for.

If an app stops working after an update

Accessibility grants are tied to the app’s code signature. When an app updates, macOS checks that the signature still matches; if the app has been re-signed by a different developer or tampered with, the grant is dropped and the feature stops.

The usual symptom is a feature that worked yesterday silently doing nothing today, with no error. Check the Accessibility list first. If the switch is off, turn it back on. If the app is missing from the list, launch it and trigger the feature so it asks again.

This is a security feature rather than a bug. Tying the grant to the signature means permission follows a verified build and does not transfer to a replacement you did not approve.

Questions

Can an app with Accessibility read my passwords?

It can read the structure of interfaces, and a password field’s contents are protected from that layer. It can, however, send keystrokes and observe focus, so the grant is still one to give deliberately and to a developer you are willing to trust.

Is Accessibility the same as letting an app record my screen?

No. Screen Recording captures pixels and is a separate switch in Privacy and Security. Accessibility describes elements and sends input. An app can have one without the other.

Will turning the permission off break the app?

It breaks the specific features that need it. A well-built app keeps the rest running and asks again the next time you use a feature that requires the grant, rather than refusing to launch.