The Accessibility permission on macOS: what an app can actually see
macOS asks you to hand over one of its broadest permissions with a single checkbox and no detail. Here is what that checkbox really grants, why some apps genuinely need it, and what to ask before you tick it.
There is a checkbox in System Settings, under Privacy & Security › Accessibility, and next to it a line of text so short it manages to say nothing: allow the app below to control your computer.
It is one of the most consequential switches on a Mac, and it is presented with less explanation than a cookie banner. This piece is the explanation.
What the permission is for
The Accessibility API was built for assistive technology. A screen reader has to be able to read every label in every application and press every button in them, or it is not a screen reader. So the API is deliberately total: with it, a process can enumerate the interface of any running app, read the text in it, and synthesise input into it.
That design is correct for its purpose. It also means macOS has exactly one permission where a more careful system would have five.
What it actually grants
Once an app is ticked, it can:
- list every window of every running application, with titles, positions and sizes
- walk the accessibility tree inside those windows and read the text of controls
- observe notifications when windows move, resize, open or close
- press buttons, set values and move focus in other applications
- install an event tap and observe keyboard and mouse input
There is no way to grant a subset. The system asks one question and gets one answer, and the answer is all of it.
Why a window app needs it at all
Anything that has to know what is on your screen needs this permission, because there is no other route. Window managers need it to move windows. Text expanders need it to see where the cursor is. Automation tools need it to press things.
WindowNote needs it for the narrowest of those reasons: it has to know which windows exist, what they are called, and where they are — otherwise there is nothing to attach a note to.
That is a small fraction of what the checkbox hands over. Which raises the only question worth asking.
The question to ask is not "what can it do"
It is: what does this app choose to do, and how do I check?
The permission cannot answer that. It grants everything, always. So the useful signals are elsewhere:
- Does the app say where its line is, before you grant it? An app that explains what it will read — and what it will not — on the permission screen itself has at least committed to something in public.
- Does it phone home? Read the network activity. An app that reads your window titles and also opens connections to a server is asking you to trust two things instead of one.
- Is it sandboxed? It cannot be, if it does this — the App Sandbox forbids reading other applications' windows. So the absence of a sandbox is not a red flag here; it is a consequence. But it does mean the operating system is not holding the line for you.
- Who is behind it, and can you reach them? The most reliable constraint on a small app is that its author has a name.
What WindowNote reads, exactly
For the record, and because a page that discusses this should state its own answer:
| Read | Never read |
|---|---|
| The application's name and bundle identifier | The contents of your windows |
| The window title, as reported | Keystrokes, clipboard, passwords |
| Window position and size | The accessibility tree inside another app |
| The document path, where the app exposes it | Anything at all, off this machine |
The last row is the one that does the work. The notes live in a SQLite file in Application Support; there is no account, no sync and no telemetry, and the only network call the app ever makes is the licence check — which the free tier does not make.
None of that is enforced by macOS. It is enforced by the code being written that way, which is a weaker guarantee than a sandbox and a stronger one than a promise on a landing page — because the app also states it on the permission screen, before you decide.
The failure mode nobody warns you about
One practical note, because it wastes an hour the first time it happens.
The Accessibility entry is bound to the app's code signature, not to its path or its name. When an app updates and its signature changes, the old entry can survive in the list — ticked, apparently fine, and granting nothing at all. The app looks broken and the setting looks correct.
The fix is to select the entry, remove it with the minus button, and add the app again. Any app that does this well will detect the state and tell you, rather than silently doing nothing.
Grant it deliberately, or not at all
The honest summary is that macOS asks you to make a large decision with a small control, and cannot help you make it well. The permission is all-or-nothing, so the decision is about the app, not about the checkbox.
Which is a reason to install fewer things that ask for it — and to expect the ones you do install to tell you, in their own interface, where they have drawn the line.
- Can an app with Accessibility permission read what I type?
- Technically, yes — the same permission that allows an app to observe the interface also allows it to install an event tap and see keystrokes. macOS does not separate the two. That is why the question of what an app chooses to do with the permission matters more than the permission itself.
- Why does macOS not offer a narrower permission?
- The API was designed for assistive technology, where reading and driving the whole interface is the point. There is no scope in it for “titles and frames only”, so every app that needs a fraction of it has to ask for all of it.
- The app is listed under Accessibility but still does not work. Why?
- The entry is bound to the app's code signature. After an update that changed the signature, the old entry can stay in the list while granting nothing. Removing the entry with the minus button and adding the app again fixes it.