Voice Transcription Shortcut Misassigned
Summary:
The default shortcut for voice transcription (“Fn” key) does not function as expected on a 2025 MacBook Air. Instead of triggering voice transcription, the Fn key opens the emoji panel. Voice transcription only works when using the right Option key, which is inconsistent with the documented default behavior.
Steps to Reproduce:
Attempt to activate voice transcription using the default shortcut (Fn key).
Observe that instead of voice transcription, the emoji picker opens.
Use the right Option key instead.
Voice transcription activates successfully.
Expected Behavior:
Pressing the Fn key should start voice transcription by default.
Actual Behavior:
Fn key opens emoji picker instead of triggering voice transcription.
Voice transcription only works via right Option key.
Environment:
Device: MacBook Air (2025 model)
macOS version: 26.4.1
Input method: Default system keyboard shortcuts
Impact:
Default shortcut behavior is misleading or incorrect.
Interferes with existing user workflows relying on Fn key or Option key.
Reduces usability of voice transcription feature.
Additional Notes / Suggestion:
Allow full customization of keyboard shortcuts for voice transcription.
Current behavior appears to be either a configuration bug or incorrect shortcut mapping.
The Fn key behavior conflicts with expected system defaults and should be corrected or made configurable.
Log in to comment and vote
Comments6
Ramzi
May 10
Unfortunately we can't disable the emoji shortcut. It's a system shortcut that cannot be swallowed.
If you want another experience you're gonna have to pick between control, right option and right command. The three of them work
Sven S.
May 10
The voice transcription shortcut is documented as Fn, but this is incorrect on my MacBook Air (2025). Fn does not trigger transcription; instead it opens the emoji panel due to macOS behavior.
In practice, transcription only works using the right Option key, which is not mentioned in the app at all. This is already a mismatch between documentation and actual behavior.
In addition, I use the right Option key for other purposes, so this default is not suitable for my setup. The main issue is therefore twofold: the documented shortcut is wrong, and the functional alternative is not user-configurable.
The correct solution would be to update the documentation away from Fn (since it does not work) and ideally allow users to freely assign their own shortcut for voice transcription instead of relying on a fixed system-dependent binding.
Ramzi
May 10
I have just tested and Fn does work for voice transcription on my MacBook M4Pro.
However, it is true that the emoji pop-up appears right after. Can you reopen a feature request on being able to customize the activation key for voice on another ticket, and if there's a few upvotes I'll work on it.
Sven S.
May 10
I don’t really want to open a separate feature request just for this. The current discussion already shows there is an issue with the current implementation.
Even if Fn technically works on your device, that behavior is clearly not consistent across different Mac models and configurations. On my MacBook Air (2025), pressing Fn does not behave as expected for voice transcription, and in addition it conflicts with the macOS emoji popup.
So even in the “working” case, the current default shortcut still collides with a system function, which makes it a poor default choice. The core issue is that the activation key is fixed and cannot be customized by the user.
Sven S.
May 10
I did some more testing and found additional behavior that may help explain the issue.
Initially, Fn did not work correctly for voice transcription on my MacBook Air (2025), while the right Option key did. After switching the activation key to another supported key and then back to Fn, Fn started working correctly as well.
However, to avoid the macOS emoji popup, I now have to use the “hold key” behavior instead of a simple key press. In this configuration, the right Option key no longer triggers voice transcription.
So there still seems to have been some kind of incorrect internal state or configuration issue initially, even though the settings did not appear wrong from the UI side. I unfortunately can no longer reliably reproduce the original behavior after toggling the shortcut settings.
That said, I still think customizable activation keys would be the better long-term solution, since Fn conflicts with system behavior on macOS and different users may already rely on modifier keys for other workflows.
Ramzi
May 10
Thank you, Sven. I'll reopen your request in this case and if there is any other user upvoting the feature I'll take it into consideration.