macOS | Windows
demo.webm
Video description
Two open apps placed side-by-side on macOS: TextEdit and What Can't I Press? TextEdit is open to a blank document. What Can't I Press? shows a search input, an expand/collapse all toggle button, a list of 4 disclosures in a collapsed state, a notification message, a shortcut filter input, a download icon, and two buttons labeled "Scan all open apps" and "Scan last focused app". The disclosures are labeled, "JAWS", "Narrator", "NVDA", and "VoiceOver" and each has a badge tallying how many shortcuts are present.
The notification message reads, "What Can't I Press cannot detect all possible keyboard shortcuts. Be sure to also check manually."
The mouse cursor clicks the "Scan last focused app" button and a brief scan happens. The list of disclosures updates to show global keyboard shortcuts and shortcuts for TextEdit. All disclosures are set to an expanded state, and links to jump to the next section are also revealed.
The mouse cursor then clicks on the search input, where the word "save" is entered. It then briefly scrolls through the list to show what apps have functionality related to saving.
The search input is cleared by clicking a clear button, then focus is placed on the filter input, where Commandkbd> + s is entered. The list of keyboard shortcuts filters to show all shortcuts that incorporate these keystrokes.
The cursor then clicks on the Command + S save row button, and places focus on the TextEdit document. The content "⌘S" is inserted into the document via pasting.
Helps to show what keyboard shortcuts are already claimed by different screen readers and apps. This helps to prevent collisions when creating new keybindings.
For example, h is often used to toggle open help dialogs. h is also the most popular navigation technique used by the two most popular screen readers on the planet.
Note
This app cannot not detect all keyboard shortcuts. This is because some keyboard shortcuts can be implemented in a way that scanning cannot detect. Treat the app as a starting point.
What Can’t I Press? lives in your macOS menu bar or Windows system tray. Click its icon to open the app. It also displays itself automatically the first time you launch it.
- Detect shortcuts in the app you had open prior to opening What Can’t I Press?, or
- Scan all currently open apps. The full "scan all apps" sweep briefly brings each running app to the foreground to read its menus, then restores focus to where it started.
- Search by intent. Search for keyboard shortcuts or commands to filter the list.
- Search by keypress. Enter keyboard shortcuts to also filter.
- Click a keyboard shortcut row to copy it to your clipboard.
- Hold Control while clicking to copy it as HTML with each key wrapped in a
<kbd>element, using the spelled-out key names. - Hold Shift while clicking to copy the same
<kbd>HTML using the displayed symbols.
JSON can be generated for what keyboard shortcuts are currently displayed.
Download the latest installer from the Releases page.
Warning
The app is currently not registered with Apple or Microsoft, meaning you'll need to bypass operating system protections to install and run the app. All code used to build this app is open and reviewable. Also reference SECURITY.md.
The app uses the Accessibility API to scan, which requires explicit permission. It will guide you to enabling this the first time a scan is run.
You may need to manually re-add app permissions in certain circumstances.
UI Automation needs no up-front permission for ordinary apps. Reading menu accelerators from an app running as administrator requires this app to run elevated as well. These apps are silently skipped otherwise.
All work executed on the app is performed on-device. Nothing about what you scan ever leaves your computer.
The keyboard shortcuts the app reads are analyzed locally and shown only to you. No data is collected, stored off-device, or sent anywhere.
There is no telemetry or analytics for the app. Its only network activity is checking GitHub for new releases and opening links, such as the project page, and that is only triggered by manual activation.
The companion website uses Plausible Analytics, a privacy-focused lightweight analytics service.
Manually discovering conflicts is a chore, yet is important work to do to ensure you don't unintentionally override something important. This app helps to lower the effort for the act of discovery.
For more background on this, read How an accessibility designer adds keyboard shortcuts to a web app.
As much as possible we should not put the burden on the person using assistive technology to use workarounds.
File an Issue that describes this feature. Be sure to also reference the project roadmap before doing so.
File an Issue that describes the bug.
File an Issue that describes the keyboard shortcut that didn't work as expected.
File an Issue that describes the access barrier.
Electron allows me to more easily distribute the app across different operating systems. It is also more mature of a framework compared to its peers in the space.
There is no central registry or technique used for declaring keyboard shortcuts. Because of this, some keyboard shortcuts cannot be detected by scanning. This is due to how the keyboard shortcuts have been written in the application's code.
Why isn't the app detecting keyboard shortcuts on macOS, even after I gave it accessibility permissions?
This can happen with ad-hoc-signed builds, which is what this app uses until I get it signed. To fix it:
- Go to System Settings → Privacy & Security → Accessibility
- Remove "What Can't I Press" with "–"
- Re-add the app to the list of apps, and then and enable it.
The Windows version of the app scans using Microsoft UI Automation (UIA), the accessibility framework built into Windows. It finds the app's menu bar and reads each menu item's AcceleratorKeyProperty.
Unfortunately, UIA does not expose a background app's accelerators the way macOS does. "Classic" Windows 32-era menus are not present in the UIA tree until a user actually opens them. Additionally, modern apps such as Notepad, Office, and Edge don't utilize "classic" menu architecture.
To accomodate this, the app runs a best-effort live pass that tries to expand top-level menus through UIA's ExpandCollapsePattern and read whatever it can reach.
The two most popular desktop/laptop screen readers run on Windows. If you are mad about Microsoft's regression in discoverability for this kind of thing, consider yelling at them on issue trackers.
- Lists the running app through a small bundled Swift helper.
- For each app, reads its menu bar with macOS Accessibility services and pulls the shortcut shown next to every menu command.
- Layers on any custom shortcuts set in System Settings → Keyboard → Keyboard Shortcuts → App Shortcuts — for both the specific app and "All Applications" — which override the app's defaults.
- Reads the built-in macOS system shortcuts from the symbolic-hotkeys preferences file and decodes each into a key, modifiers, and a plain-English label.
- Flags apps that register hidden global hotkeys at runtime. Their binary imports
RegisterEventHotKeyas a coverage gap, since those can't be enumerated.
- Lists the running apps by finding processes that have a visible main window, using the window title as the name.
- For each app, uses Windows UI Automation to walk its menu bars and read the accelerator key listed on each menu item.
- Falls back to scanning the whole window when no menu bar is found.
- Uses a built-in, hand-maintained list of Windows system shortcuts (Win + E, Ctrl + Shift + Esc, Alt + Tab, etc.), because Windows exposes no store to read these from.