What does Accessibility permission actually do on a Mac?

Accessibility access on a Mac lets an app simulate mouse clicks and keystrokes and read the contents of other apps' windows, system-wide — not sandboxed to its own window. Camera and microphone use light up a colored dot in the menu bar the instant either turns on; Accessibility and its narrower sibling, Input Monitoring, do neither. There is no indicator, no log, and no way to see in real time whether an app holding either permission is using it right now. This guide is about the one decision that actually matters: an app just asked for Accessibility — should you allow it, what do you lose by saying no, and how do you check what already has it.

What Accessibility control actually covers

Accessibility is the permission behind macOS's assistive-technology framework: Apple's own APIs for moving the cursor, clicking on an app's behalf, typing on an app's behalf, and reading the text and labels inside another app's window, regardless of which app is in front. Our guide to seeing every permission on your Mac covers the base mechanics — how Accessibility differs from the narrower Input Monitoring permission, and the well-known categories of tool (window managers, automation apps, real assistive technology) that legitimately request it. What that page doesn't cover, and what nothing else ranking for this question covers either, is the part below: the gap in what macOS actually tells you once you've said yes.

Why there's no indicator for Accessibility, and why that's the real risk

Apple documents the exact colors for its live-use indicators: a green dot next to Control Center means the camera is on right now, orange means the microphone is, purple means something is recording system audio. Screen recording gets a second layer on top — macOS has re-confirmed that access on a recurring, roughly monthly basis since Sequoia, a behavior carried into Tahoe, specifically because Apple decided the permission was sensitive enough to make apps re-justify it.

Accessibility and Input Monitoring got no equivalent treatment. As of macOS Tahoe 26, the only signal either one gives you is a static row in System Settings that says Allowed or not — set once, at grant time, and never updated to reflect whether the app has actually used the capability since. It doesn't change if the app uses it constantly. It doesn't change if the app hasn't touched it in a year. An app holding Accessibility could be reading the contents of your banking app's window or simulating a keystroke into your password manager at this exact moment, and macOS will not tell you — not with a dot, not with a log, not with anything short of you noticing the effect yourself: your cursor moving without your hand near the trackpad, or a window coming to the front that you didn't click.

This app just asked for Accessibility — here's how to decide

Start by naming the exact feature the app needs it for. A window manager needs it to move and resize other apps' windows when you press its shortcut. A text expander needs it to detect what you're typing system-wide and insert the expanded text in place. Remote-support software needs it to give a technician's mouse and keyboard literal control of your screen. If you can point at one specific, real feature that requires system-wide control, that's a legitimate reason. If the app can't explain one, or the explanation is vague ("for full functionality"), that's the strongest single signal to decline.

Next, check whether a narrower permission would actually cover the job. A global hotkey that doesn't need to move your cursor or read a window only needs Input Monitoring, not Accessibility. An app that just needs to tell a different app to run a command — not click or type on your behalf — needs Automation (the Apple Events permission), not Accessibility either. If the feature you actually want only needs one of those, and the app is asking for the broader grant anyway, that's worth a question to the developer before you click Allow, not an automatic yes.

Then weigh what you lose by saying no. Most apps that request Accessibility degrade a feature rather than fail outright: a window manager without it simply does nothing when you press its shortcut; a text expander without it can usually still show you the expansion to copy by hand. Denying the request first and seeing exactly what stops working is a reasonable, low-risk way to find out whether you actually need to grant it — you can always add the app back from Settings later.

Finally, match the request to the developer, not just the feature. Accessibility for a documented feature from an app you can put a real name to — an active GitHub repo, a real support page, a developer you'd recognize — is a routine grant. The same request from something bundled inside a "free PDF converter" you don't remember installing is the case worth declining and investigating instead of allowing on reflex.

Which kinds of apps legitimately hold this permission, and why

Naming a category isn't the same as knowing what a specific tool actually does with the grant. A few real, checkable examples:

Notice what's absent from that list: nothing here needs Accessibility to see your camera, your microphone, your screen, or your files — those are separate permissions macOS tracks and asks for on their own. Accessibility is narrower and, at the same time, more powerful than it sounds: it's entirely about input and on-screen UI content, and it grants nothing outside that.

When it re-prompts, or looks different after an update

An app that already had Accessibility can end up asking again after an update — not because macOS reset anything on its own, but because the app's code-signing identity changed, or the new version added a feature the old one never requested. Our guide to why Mac app permissions change after an update covers exactly why, and how to tell a legitimate re-ask from something worth a second look. Accessibility isn't a special case there — the same rules govern it as every other permission tracked by tccd, the system daemon behind every permission prompt on a Mac.

Auditing what already has it, and revoking it

The path is System Settings → Privacy & Security → Accessibility, and a second, separate list at Privacy & Security → Input Monitoring — they're tracked independently, so an app can hold one without the other. Flip an app's toggle off, or select it and click the − button, to revoke either one. If the toggle doesn't seem to change anything right away, quit and reopen the app: macOS checks this particular permission once, when a process starts, not continuously, so an app that was already running can keep behaving as if it's still allowed for a little while after you've revoked it.

Deleting an app doesn't clear its row in either list — the grant is keyed to a bundle identifier, not to whether the app still exists on disk. Our guide to auditing every app permission on your Mac covers exactly how to spot and clear those leftover entries, plus the command-line reset tool that does the same job without opening Settings at all.

What SwoopByte Permissions can and cannot tell you about Accessibility

Everything above is the real, correct manual path, and none of it requires installing anything. SwoopByte Permissions, the app we're building, reads the same Accessibility and Input Monitoring rows into one screen alongside every other permission, organized by app instead of by pane, so you're not opening two separate System Settings lists to answer one question about one app. It's an auditor, never a blocker: it can't grant, deny, or intercept an Accessibility prompt on your behalf, because that consumer API doesn't exist for any third-party app, ours included. The audit is free and stays free; a one-time $19.99 Pro license adds change history and ongoing monitoring for anyone who wants more than a point-in-time read. It's still in development — join the waitlist to get it first.

FAQ

Is it safe to give an app Accessibility access on Mac?

It's safe when you can name the specific feature the app needs it for and you recognize the developer. It's worth declining, at least at first, when the app can't explain why it needs system-wide control or you don't know who made it — you can always grant it later if a feature turns out to need it.

Can an app read my keystrokes on Mac?

Yes — Input Monitoring gives an app exactly the capability a keylogger needs, and Accessibility can simulate and observe input too. That's genuinely true, and it's also true of the same capability a legitimate global-hotkey launcher or remote-support tool uses. The permission itself doesn't distinguish intent; you do, by checking who's asking and why before you allow it.

What's the difference between Accessibility and Input Monitoring on a Mac?

Accessibility lets an app simulate clicks and keystrokes and read the on-screen content of other apps' windows. Input Monitoring is narrower: it only lets an app read raw keyboard, mouse, or trackpad events, even while a different app is focused. Some tools need one, some need both, depending on whether they also have to act on the screen or just listen for a hotkey.

Why is there no menu-bar indicator for Accessibility like there is for the camera?

Apple built live indicators for camera, microphone, and screen recording specifically, and has never extended the same treatment to Accessibility or Input Monitoring. As of macOS Tahoe 26, both remain visible only as a static Allowed row in System Settings, with no signal for whether the grant is actually being used at any given moment.

Do I need to give an app both Accessibility and Input Monitoring?

Only if it genuinely needs both — reading or acting on-screen content, and capturing raw input events regardless of focus. A tool that only listens for a global hotkey needs Input Monitoring alone; one that also moves windows or reads window text needs Accessibility too. Two separate requests from the same app for two different jobs isn't automatically suspicious, but it's still worth being able to name what each one is for.

How do I know if an app is using Accessibility right now?

You mostly can't, from the system itself. There's no live indicator or usage log for this permission, so the only practical signals are indirect: your cursor or a window doing something you didn't initiate, or a change you'd only catch by comparing the allowed-apps list to what you remember granting.

Related guides