Why a keyboard overlay needs Accessibility permission on a Mac
A keyboard overlay needs Accessibility permission because macOS keeps the keys you press in one app away from every other app until you say otherwise, and Accessibility is one of the permissions that lets you say so. Typebar asks for Accessibility and nothing else. It uses it for three things: to see which keys you press, to read app menus so it can name your shortcuts, and to type for you when you use Click to Type.
You turn it on, or off, in System Settings > Privacy & Security > Accessibility. The rest of this post explains what you are agreeing to, why an overlay cannot work without it, and how to fix the switch when it does not seem to take.
What the Accessibility permission allows
Accessibility is the permission macOS gives to apps that work with other apps on your behalf. In System Settings, the Accessibility list sits under the line “Allow the applications below to control your computer”, and that is a fair summary. An app on that list can:
- Read other apps’ interfaces: menus, buttons, windows and the text in them.
- See input: the keys you press, wherever you press them.
- Act for you: press keys and click, as if you had done it yourself.
The name comes from where these abilities started. Tools for people who cannot use a keyboard or mouse in the usual way need to read the screen’s controls and operate them, and the same system serves window managers, launchers, text expanders and automation apps today.
Because it is broad, macOS never lets an app grant it to itself. An app can only ask, and you decide in System Settings.
Why a keyboard overlay needs it
Each of Typebar’s three uses maps to one of those abilities.
Seeing your keys. This is the whole point of an overlay, and the part macOS guards. Without a permission, an app only sees keys typed into its own windows. An overlay has to see the keys you press in Final Cut Pro, Terminal or a browser, while it sits in the corner doing nothing but drawing a keyboard.
Naming your shortcuts. When you press Shift-Command-4 (⇧⌘4), the pill shows “⇧⌘4 Screenshot Selection”, and in an app where Command-K inserts a link it shows “⌘K Insert Link”. App shortcut names like that are read from the menus of the app in front, so they match what your viewers will find when they look. The same reading powers the cheatsheets: hold a modifier such as Command and the keys relabel with what they do in that app. Reading another app’s menus is exactly what Accessibility allows. See every keyboard shortcut for the app you are using shows the cheatsheets at work.
Typing for you. With Click to Type on, clicking a key on the board types it into the app in front. That is an app pressing keys on your behalf, which is the “control your computer” part. Presenting with only a mouse covers when that is useful.
Why not Input Monitoring or Screen Recording
macOS has other permissions that sound related, and it helps to know why an overlay does not need them.
| Permission | What it lets an app do | Does Typebar use it? |
|---|---|---|
| Accessibility | Control your computer, including seeing keys | Yes: keys, menus and Click to Type |
| Input Monitoring | Monitor input from your keyboard, even while you use other apps | No |
| Screen Recording | Record the contents of your screen | No |
Input Monitoring lets an app watch the keyboard, and some key displays use it. On its own it would cover only one of Typebar’s three jobs: it does not let an app read menus or type for you. Since Accessibility is needed for those anyway, and covers seeing keys too, Typebar asks for one permission rather than two.
Screen Recording lets an app capture what is on your screen. An overlay draws its own keyboard; it does not need to see anyone else’s windows to do that. Typebar does not ask for it. Its board and pill still appear in your recordings, because your recording app captures them like any other window on screen. (In macOS 15 and later this list is called Screen & System Audio Recording.)
Fewer permissions is better for you. Every permission is something an app could misuse, so an app that asks for exactly what its features need is easier to trust. Is a keystroke display safe? goes into what Typebar keeps and how to check any app’s claims.
Turn it on
When an app asks for Accessibility, macOS shows a prompt with a button that opens System Settings. You can also go there directly:
- Open System Settings and choose Privacy & Security in the sidebar.
- Click Accessibility.
- Find the app in the list and turn on its switch. macOS may ask for your login password or Touch ID to confirm.
- If the app is not in the list, click the add button (+) below it, choose the app in your Applications folder, and turn on its switch.
That is the only permission Typebar asks for, so its switch is the only one you need to turn on.
Turn it off, or fix a switch that will not stick
To take the permission away, go back to System Settings > Privacy & Security > Accessibility and turn off the app’s switch. For Typebar, that takes away what it uses the permission for: seeing your keys, reading menus and typing for you in Click to Type.
To remove an app from the list entirely, select it and click the remove button (−) below the list. It is worth doing for apps you have deleted or stopped using, since an old entry is permission nobody is using.
Sometimes an app’s switch is on and the app still says it lacks access. This can happen after an app is replaced by a new copy. The usual fix:
- Quit the app.
- In Privacy & Security > Accessibility, select it and click the remove button (−).
- Open the app again and allow it when macOS asks, or add it back with the add button (+).
If that does not work, Terminal can clear macOS’s stored decision for one app with tccutil reset Accessibility followed by the app’s bundle identifier, which you can find with mdls -name kMDItemCFBundleIdentifier /Applications/Typebar.app. For Typebar the command is tccutil reset Accessibility com.everydaymactools.typebar. The app then asks again the next time it needs the permission.
What the permission does not change
A few things stay the same however an overlay is set up, and they are worth knowing:
- Secure input still wins. When you type into a password field that macOS marks as secure, macOS keeps the keys away from every other app, Accessibility or not. Typebar shows nothing typed there, and the pill says “Typing hidden in a password field”. Secure input on a Mac explains why.
- Automation does not type. Typebar’s links, command-line tool and Shortcuts actions can change what the board shows. They never type or press keys for you. Click to Type types only when you click a key on the board.
- Nothing you type is kept. Typebar uses the permission to light keys and name shortcuts, and nothing you type is saved or sent anywhere.
Questions
Is it safe to give a keyboard overlay Accessibility?
It is a broad permission, so give it only to apps you trust, from a developer you can identify. Check that the app is signed and notarized, and that it asks for nothing it does not need.
Does Typebar need Input Monitoring as well?
No. Accessibility is its only permission. It does not ask for Input Monitoring or Screen Recording.
What happens if I never turn it on?
An overlay without the permission cannot see the keys you press in other apps, so there is nothing to show. Typebar needs it for the board to light up.
Typebar is $9 once, for up to 5 Macs, with a 24-hour free trial and everything on.