What macOS Accessibility permission actually allows

If you install a window management tool on macOS, at some point a dialog asks you to grant it Accessibility permission, and the wording is not reassuring. It is worth understanding what that permission actually is, because the honest answer is more interesting than either "it's fine, everyone needs it" or "never grant this to anything".

What the permission is for

macOS exposes an accessibility API so that assistive technology — screen readers, switch controls, voice control — can inspect and operate the interface of other applications. That is its purpose. An app with this permission can read the accessibility tree of other applications and act on the elements it finds: press a button, focus a field, move a window.

Apple documents the surface as the Accessibility API, and gates it behind explicit user consent in System Settings under Privacy & Security. It is not something an application can grant itself, and it survives no sleight of hand: the user turns it on, deliberately, per app.

Window management uses it because there is no narrower door. macOS does not offer a "move other applications' windows" permission that stops there. If you want to reposition a window that belongs to another process, this is the interface, and it comes with the rest of the surface attached.

That is the honest shape of it. A window manager asks for a capability broader than the job it does, because the platform does not offer one sized to the job.

What it does and does not include

Worth separating clearly, because these get conflated:

It does allow enumerating windows and their positions, moving and resizing them, minimising and restoring them, raising and focusing them, and reading accessibility attributes of interface elements — which includes window titles, and can include the text content of accessible controls.

It does not include screen recording. That is a separate permission with a separate prompt. An app with Accessibility permission cannot capture your screen on the strength of it.

It does not include file access. Full Disk Access is separate again. Accessibility permission grants nothing on the filesystem.

It does not include input monitoring in the keylogging sense. Observing keystrokes globally is its own permission.

So the accurate statement is narrower than the fear and broader than the marketing. Accessibility permission is powerful specifically because it can read interface content and drive other applications — not because it is a skeleton key to the machine.

Why window titles are the sensitive part

The capability that deserves the most care is not moving windows. It is reading them.

A window title is often a filename, a client name, a ticket number, a document name, a URL. A list of open window titles across a working day is a reasonably detailed description of what you do and who you do it for. That is true whether or not any tool intends it: the information is right there in the API.

This is why the interesting question to ask a window manager is not "do you need Accessibility permission" — it will, they all do — but "what do you do with what you can read?"

Orvial's answer is that content-sensitive metadata is treated as sensitive by design: window titles, URLs, file paths, document names and Scene names are the kind of thing that should stay on your machine and stay out of default telemetry. The privacy principles set that out in full, and permissions covers which permissions Orvial expects to need and which it deliberately does not.

The second question worth asking is what happens when you take the permission away. A tool that silently stops working, or worse, keeps reporting success while doing nothing, has told you something about how it was built. Losing the permission should be detected and explained, not absorbed.

The verification problem this creates

There is a subtler consequence, and it is the one that shapes the engineering.

Asking the accessibility API to move a window is a request, not a guarantee. The call can return successfully while the window ends up somewhere else, or nowhere: the application may constrain its own geometry, refuse the size, be mid-launch, be in native fullscreen, or simply be slow to respond. A tool that treats a successful API call as a successful outcome will confidently report a workspace it did not achieve.

This is why Orvial is designed to re-read the workspace after acting rather than trusting the call. An outcome that was confirmed and an outcome that was merely attempted are different results and are reported differently — including the case where the evidence is genuinely insufficient to say. What verified workspace restoration actually means goes into how that is modelled.

It also means some things are honestly out of reach. A window in native fullscreen is not a window you can politely move, and the right response is to say so rather than to try something approximate and call it done.

What this means when you grant it

A reasonable position, for any tool asking for this permission:

Grant it when you understand what the tool does with the read side, not just the write side. Expect the tool to explain why it needs the permission before requesting it, rather than prompting on first launch and hoping you click through. Expect it to work locally by default, since nothing about moving your windows requires a server. And expect it to behave sensibly when you revoke it.

Orvial is in development and has not been released, so everything here is the standard it is being built to rather than a claim about shipped behaviour. The permission list itself will be confirmed against the signed, notarised build before launch — a page describing permissions for software nobody can run yet is a design commitment, and it is labelled as one.

What is not in doubt is the shape of the trade. macOS asks you to grant a broad capability to get a specific job done, and the only sensible response from a tool on the receiving end is to be precise about what it does with the rest.