PUNCHCARD Get Punchcard $9

Accessibility permission on a Mac: what it grants and why apps ask

· 6 min read

Accessibility permission lets an app read the interface of every other app on your Mac (window titles, text in fields, menu items, buttons) and send clicks and keystrokes as if you had made them. It was designed for screen readers and assistive tools, which is why it is so broad. Window managers, text expanders and automation apps legitimately need it; a large number of other apps ask for it simply because it is the easiest route to window titles. Here is what the switch does, how to tell need from want, and how to revoke it.

What the permission technically unlocks

macOS exposes an accessibility tree for every running app: a structured description of its windows, controls and text, maintained so that a screen reader can describe the interface aloud. The Accessibility permission (listed under System Settings, Privacy & Security, Accessibility) gives an app two abilities over that tree:

  1. Read it. The app can walk the windows of any other app and read titles, the text of fields and labels, the selected text, the URL bar of a browser, the subject line of a mail message, and so on. The content of a text field is part of the tree, which means passwords in fields that are not marked secure, drafts, and chat messages are readable.
  2. Act on it. The app can press buttons, choose menu items, move and resize windows, and post synthetic keystrokes and mouse clicks system-wide.

The official name in the prompt is “control your computer using accessibility features,” and for once the wording is accurate. An app with this permission can operate your Mac.

Two things it does not grant: it does not capture pixels (that is Screen Recording), and on current versions it does not let an app listen to raw keystrokes (that is Input Monitoring). But reading text fields and posting keystrokes gets an app much of the way to both.

Apps that genuinely need it

If the app’s purpose is to read or drive other apps’ interfaces, Accessibility is the correct permission and you should expect the request.

  • Window managers and tilers. Moving and resizing other apps’ windows is only possible through the accessibility tree.
  • Text expanders. They watch what you type in any app, delete the abbreviation and insert the expansion. Both halves require Accessibility.
  • Clipboard and snippet tools that paste into the frontmost app on a shortcut.
  • Automation and macro tools that click buttons and choose menus in other apps.
  • Assistive software, the original audience: screen readers, switch control, voice control alternatives.
  • Dictation and voice-typing apps that insert text where the cursor is.

For all of these, the permission is the feature. Denying it does not make the app more private; it makes it not work.

Apps that only want it

The second group asks for Accessibility because of one side effect: it is the quickest way to read the titles of other apps’ windows, which in turn reveals the document name, the browser tab, the email subject, the file path.

The usual examples are time trackers, focus and “distraction” tools, some note-taking apps that want to link to whatever you are looking at, and analytics-style dashboards of your day. Their pitch is that window titles make the record more detailed. That is true. It is also true that the permission they receive can read every text field on your Mac, not just the titles, and you have no way to verify from outside which of those it uses.

The question to ask is whether the extra detail is worth a permission that can read everything. For a time tracker, the honest answer is usually no: “Safari, 2 hours 10 minutes” is nearly as useful as a list of every tab title, and it costs nothing. Punchcard is built on that trade. It records app names only, which macOS provides to every app without a permission, and it never asks for Accessibility. The receipt it prints at closing time lists apps and minutes, never documents or URLs, because it never had them. If you want per-document detail, Punchcard is not the tool; if you want the day’s shape without handing over the keys, it is.

There is a longer comparison in time-trackers-that-ask-for-accessibility-permission-and-one-that-doesn-t.html.

How to see which apps have it

  1. Open System Settings.
  2. Choose Privacy & Security in the sidebar.
  3. Scroll to Accessibility and open it.
  4. The list shows every app that has ever asked. A switch on the right shows whether it is currently granted.

Go down the list and sort each app into the two groups above. Anything that does not drive or read other apps for a living should not be on the list with the switch on.

How to revoke it, and what happens

  1. In the same Accessibility list, turn the switch off next to the app.
  2. To remove the entry entirely, select the app and click the minus button below the list.
  3. If the app is running, quit and relaunch it. Some apps cache the permission state until restart.

Revoking does not uninstall or break the app. Features that need the permission stop working, and a well-built app will say so and point you back to the setting. A window manager stops moving windows. A text expander stops expanding. A time tracker that used Accessibility for titles usually falls back to app names or stops recording altogether, depending on how it was built.

If you want a full reset for one app, including every other permission it holds, open Terminal and run tccutil reset All com.example.bundleid, replacing the identifier with the app’s. You can find the identifier by selecting the app in Finder, choosing Get Info, or with osascript -e 'id of app "AppName"'.

A decision rule for the prompt

When the dialog appears, you have a few seconds to decide. A rule that holds up:

  • If the app’s main feature is operating other apps, grant it. It needs it.
  • If the app could plausibly do its job with less, deny it first and see what you lose. Most apps degrade gracefully. If the loss is window titles in a log, you have probably lost nothing you will miss.
  • If the app refuses to run at all without Accessibility and cannot say why, that is the answer.

One more consideration: the permission follows the app, not the session. An app that runs at login with Accessibility has the ability to read your screen’s text every day, including after you have forgotten it is there. Check Login Items & Extensions under General in System Settings alongside the Accessibility list, and treat the overlap as the set of apps that matter.

Questions

Is granting Accessibility the same as letting an app see my passwords?

It can be. Password fields marked as secure text are hidden from the accessibility tree, but anything typed into an ordinary field, pasted into a chat, or shown in a document is readable. Treat the permission as “can read what is on screen as text.”

Can an app get window titles without Accessibility?

Yes, through Screen Recording, which unlocks the names in the system window list as a side effect. So a tracker that avoids Accessibility but asks for Screen Recording has not reduced its reach. Only an app that asks for neither is limited to app names.

Why does macOS not offer a narrower “window titles only” permission?

There is no such permission today. The accessibility tree is all or nothing, which is exactly why apps should be judged on whether they ask for it at all, rather than on what they say they use it for.

If I deny it, will the app keep asking?

Some do, every launch. The entry stays in the Accessibility list with the switch off, and you can leave it that way. If the nagging is the only thing the app does without the permission, you have learned something about the app.