Why menu bar apps ask for Accessibility permission

Updated 2026 · a 6-minute read

You install a small utility to tidy your menu bar and it immediately asks for Accessibility access — the same permission category used by screen readers and automation tools. macOS words the prompt in a way that makes you pause, and you should pause. It's a broad permission.

This article explains what Accessibility actually grants, the specific technical reason menu bar organizers ask for it, and how to tell the difference between an app that genuinely needs it and one that's overreaching.

What Accessibility access actually allows

Accessibility is macOS's automation permission. Granting it lets an app:

Read the interface of other applications — window titles, button labels, menu contents, the structure and text of what's on screen.
Act on that interface — click buttons, choose menu items, move windows.
Post synthetic input events, such as keystrokes and mouse events.

That is a lot of power, and it's right to be cautious. An app with Accessibility access can, in principle, read text in other apps' windows. This is why macOS makes you grant it manually in System Settings rather than letting an app request it with a single click.

What it does not grant is equally worth knowing. Accessibility is not Screen Recording — it can't capture the pixels of your screen. It doesn't give access to your files, camera, microphone, contacts, or network traffic. Those are separate permissions with separate prompts.

The specific reason menu bar organizers need it

Here's the part that isn't obvious, and it comes down to one surprising fact about how modern macOS draws the menu bar.

If you ask the system for a list of what's in the menu bar using the public window API (CGWindowListCopyWindowInfo), you get every status item back — position, size, layer, all of it. But every single one is reported as being owned by Control Center. Not Dropbox. Not Slack. Not the app that actually created it. Modern macOS renders status items out of the Control Center process, so at the window level there is no app attribution at all.

An organizer can see that there are nineteen icons and exactly where each one sits — but from that API alone it cannot tell you which one is which app.

That's fine for the basic job of hiding icons, which is really just a layout trick and needs no permission whatsoever. But it breaks anything that needs to know identity:

Showing you a readable list of your icons by app name.
Letting you group specific apps together under one button.
Opening a particular app's menu on your behalf when you pick it from a list.

The Accessibility API is the only public way to close that gap. Each running app exposes its menu bar extras through an accessibility attribute, which provides the owning app, a title, and the ability to activate the item exactly as a real click would. One API solves both naming and activation — and it requires the Accessibility grant.

The alternative would be worse

There's a second approach some organizers take: capture the screen, crop out each icon's pixels, and render them in the app's own panel. That's how the most sophisticated menu bar managers give you an independent, fully controllable icon bar.

It works well, but note the trade: it requires Screen Recording permission, which is strictly more invasive than Accessibility. An app with Screen Recording can see anything on your display, including windows you'd never want captured. If you're weighing two organizers, an app that needs only Accessibility is asking for less than one that needs Screen Recording.

How to judge whether an app should get it

Rather than a blanket yes or no, a few practical tests:

Does the app work at all without it?

A well-designed utility degrades gracefully. If hiding icons works with no permission and only the naming features are gated, that's a good sign — the developer scoped the permission to the feature that genuinely needs it. If a simple app demands Accessibility before it will do anything, ask why.

Is the reason explained in plain language?

Developers who understand the constraint can tell you exactly which feature needs it and why. Vagueness ("required for full functionality") is a small red flag.

Can you read the source?

Open-source apps let you — or someone you trust — verify the claim rather than take it on faith. For a permission this broad, that's meaningful.

Does it make network connections?

Accessibility access is only dangerous in combination with a way to send data somewhere. A utility that reads your menu bar and has no network code is a very different risk profile from one that phones home.

How to grant, check, and revoke it

All of it lives in one place: System Settings → Privacy & Security → Accessibility. You'll see a list of apps with toggles. Turning one off takes effect immediately — apps don't get a say in it.

Two things that trip people up:

Duplicate entries. If you see the same app listed twice, that usually means two copies exist on disk (say, one in Applications and one in Downloads). Permission is tied to the specific copy, so granting one leaves the other denied — and if you're running the other copy, the toggle looks enabled while the app still has no access. Delete the stray copy, then remove and re-add the entry.
It stopped working after an update. macOS ties the grant to the app's code signature. Some apps — particularly ones built locally or distributed outside the App Store — can change signature between builds, which quietly invalidates the grant. Re-granting fixes it.

The bottom line

Accessibility is a genuinely powerful permission and you should not grant it casually. But for menu bar organizers there's a real, specific, unavoidable technical reason: macOS deliberately doesn't tell apps which icon belongs to which app, and the Accessibility API is the only public way to find out.

The reasonable standard is: the app should work without the permission for anything that doesn't truly need it, explain clearly what the permission buys, and ideally let you verify the claim.

Barkeep is built to that standard. Hiding icons, the keyboard shortcut and the system monitor need no permissions at all. Accessibility is optional and used only for grouping — and the whole thing is open source, so you can check rather than trust.

Get Barkeep — free