How-to
How to enable Accessibility permissions on macOS (Tahoe + Sequoia)
Enable Accessibility for an app in macOS Tahoe 26 and Sequoia 15. What it actually grants, why apps need it, and how it differs from Screen Recording.
If you’ve installed an app that automates anything on your Mac — a text expander, a clipboard manager, an app launcher with global hotkeys, or any AI tool that can move your cursor — you’ve hit Accessibility permission. This is the up-to-date guide for granting it on Tahoe 26 and Sequoia 15.
Verified 2026-04-27 against Apple’s Allow accessibility apps to access your Mac. Procedure has been stable since Ventura 13 — only the panel location moved slightly.
What macOS version are you on?
Check Apple menu → About This Mac. The procedure is the same across recent versions, only the path differs slightly:
| Version | Path |
|---|---|
| macOS Tahoe 26 (2026) | System Settings → Privacy & Security → Accessibility |
| macOS Sequoia 15 (2024-2025) | Same path as Tahoe |
| macOS Sonoma 14 | Same path |
| macOS Ventura 13 | System Settings → Privacy & Security → Accessibility |
| macOS Monterey 12 and earlier | System Preferences → Security & Privacy → Privacy tab → Accessibility |
The 5-step procedure
- Apple menu → System Settings (or System Preferences on Monterey or older)
- Click “Privacy & Security” in the sidebar — scroll if you don’t see it
- Click “Accessibility” within Privacy & Security (usually below App Management, Automation, and Files & Folders)
- Find your app and flip the switch on. macOS asks for password or Touch ID
- Quit and restart the app —
Cmd+Q, not just closing the window. Accessibility only activates on next launch.
What Accessibility actually grants
This is the permission that gives an app real power over your Mac. Specifically:
- Read the AX tree — a structured representation of every window, button, text field, and label currently visible. Apps use this to know “the user is in the Bevel modifier panel” without literally looking at pixels.
- Send keystrokes — type characters, simulate keyboard shortcuts, trigger system actions
- Send mouse events — click at coordinates, drag, scroll
- Observe focus changes — know which window or text field the user just clicked on
- Inspect UI elements — get labels, roles, and values of buttons and fields
Apps that legitimately need it: text expanders (TextExpander, Espanso), clipboard managers (Paste, Maccy), launcher apps (Raycast, Alfred), window managers (Rectangle, Magnet), accessibility tools for users with disabilities (the original use case), and screen-aware AI tools that can also control the cursor (Skilly).
Apps that should never ask for it: most screenshot tools, most chat apps, most browsers, most media players. If a single-purpose app asks for Accessibility without an obvious automation feature, that’s a flag.
Accessibility vs Screen Recording — the difference matters
These are often confused. They’re separate for a reason:
| Screen Recording | Accessibility | |
|---|---|---|
| Lets app SEE pixels | ✅ | ❌ |
| Lets app READ window contents (AX tree) | ❌ | ✅ |
| Lets app SEND keystrokes | ❌ | ✅ |
| Lets app SEND mouse clicks | ❌ | ✅ |
| Weekly re-prompt | ✅ (Sequoia 15+) | ❌ |
| Required by Skilly | ✅ for screen capture | ✅ for cursor pointing |
Some apps need both, some need only one. Apple separated them so you can make informed grants — a screenshot tool gets Screen Recording but not Accessibility; a keyboard expander gets Accessibility but not Screen Recording.
When the app isn’t in the list
Apps only appear in the Accessibility list after they’ve requested the permission at least once. Two fixes:
Option 1 (preferred): Launch the app and trigger the feature that needs Accessibility. macOS shows a permission dialog. Click “Open System Settings” — the app gets auto-added to the list. Toggle on, restart the app.
Option 2 (if you dismissed the prompt): In the Accessibility panel, click the + button below the app list. Navigate to /Applications/, pick the .app bundle, click Open. macOS adds it to the list with the toggle off; flip it on.
”I enabled it but it’s still denied”
Three causes, in order of frequency:
1. You didn’t fully quit the app. This is by far the #1 cause. Closing the window keeps the process running, and Accessibility is checked at process launch only. Cmd+Q while the app is in focus, wait two seconds, relaunch.
2. The app’s bundle identifier changed (e.g., upgraded from a beta to a release build, or replaced one app with a fork). macOS keeps the old entry separate. Click the - (minus) button to remove the stale entry, then let the new app prompt fresh.
3. The app needs more than just Accessibility. Some apps need Accessibility AND Input Monitoring AND Screen Recording. If only Accessibility is granted, parts of the app still won’t work. Check the app’s troubleshooting docs or its onboarding flow — most well-built apps walk you through every required permission.
Privacy posture: what Skilly needs and why
Skilly requires both Screen Recording (to see what app you’re using) and Accessibility (to move the cursor to the right button while answering your question). The Accessibility permission is what lets Skilly’s blue cursor land on the actual Bevel slider in Blender, not just a generic “look here” arrow.
What Skilly does NOT do with Accessibility:
- Never types for you (we don’t simulate keystrokes)
- Never clicks for you (cursor points; you click)
- Never reads other apps’ windows in the background (capture is push-to-talk only)
The Accessibility grant is required by Apple’s API model, but Skilly uses only the read+point subset, never the type-or-click-for-you subset. The full source is on GitHub if you want to verify.
Try Skilly
Skilly is the AI tutor that watches your Mac screen and points at exactly what to click while answering you out loud. 15 minutes free, no card.
FAQ