Repository navigation
aria-keyshortcuts: define macOS mapping of Meta/Alt to Command/Option in AXKeyShortcutsValue #272
Description
The aria-keyshortcuts syntax uses platform-neutral modifier names (Meta, Alt). On macOS these correspond to the Command and Option keys, but the macOS mapping in Core-AAM (https://w3c.github.io/aria/core-aam/#ariaKeyshortcuts) does not say whether browsers should translate them for AXKeyShortcutsValue.
Result: VoiceOver announces "Meta Shift M" / "Alt Shift M" in Firefox and Chromium, while Apple keyboards are labelled Command and Option.
WebKit fixed this by translating exact tokens Meta -> Command and Alt -> Option, leaving other tokens unchanged and preserving malformed values: WebKit/WebKit@4588e2f
(WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=323089)
Related reports:
- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=2074048
- Chromium: https://issues.chromium.org/issues/556516042
Firefox maintainers noted the spec doesn't require translation, which is why implementations differ.
Proposal: in the macOS mapping, state that user agents should expose Meta as Command and Alt as Option in AXKeyShortcutsValue, leaving the DOM attribute unchanged.
Activity
css-meeting-bot commentedon Oct 15, 2026
The ARIA Working Group just discussed
aria-keyshortcuts: define macOS mapping of Meta/Alt to Command/Option in AXKeyShortcutsValue.The full IRC log of that discussion
<jugglinmike> subtopic: aria-keyshortcuts: define macOS mapping of Meta/Alt to Command/Option in AXKeyShortcutsValue<jugglinmike> github: https://github.com//issues/272
<jugglinmike> jamesn: This sounds like a simple proposal
<jugglinmike> jamesn: Can I ask a Mac person to take a look at this?
<jugglinmike> jcraig: I can take a look
<jugglinmike> jamesn: Please add the "agenda" label if you think that's appropriate
MReschenberg commentedon Oct 15, 2026
Hi folks, I've implemented this in gecko to match the webkit behaviour.
I'm wondering about localisation - is it the browser's responsibility to localise converted strings like "Command" and "Option"?
It would be helpful to have this information included in the specification.
Thank you!
cookiecrook commentedon Oct 15, 2026
I feel like an explicit:
Is duplicative/unnecessary. This probably already exists in the HTML or DOM specs somewhere. These are just implementation bugs.
@MReschenberg already has a Firefox patch in Gecko bug 2074048.
So I'm not sure there's anything left to do but evangelize the Chrome fix. @spectranaut may be interested in taking that one.
cookiecrook commentedon Oct 15, 2026
Gecko already localizes role and state values like "button" and "checked"... I don't think these are any different.
The author doesn't have the ability to translate this, so it's on the engine, right?[crossed two streams there, disregard the stricken text] There may be something in platform API you can reference to get the platform translation.cookiecrook commentedon Oct 15, 2026
I'm coming around to adding an AUTHOR Req:
and a UA Req:
cookiecrook commentedon Oct 15, 2026
In the ARIA call today, someone said "James, this seems like a simple one for you." I replied, "I've never thought 'aria-keyshortcuts' was particularly simple."
jcsteh commentedon Oct 16, 2026
Only where the platform doesn't provide some way to expose these in a locale-independent way; e.g. via role constants or predefined non-localised strings. For example, button is NSAccessibilityButtonRole on Mac. We avoid localising in the browser engine wherever possible, but sometimes, it can't be avoided if the API doesn't allow it. UIA and Android are regular culprits here.
The Gecko patch doesn't currently localise and nor does WebKit. The fact that WebKit doesn't localise is why we were unsure here. We initially thought that might have been deliberate; i.e. we wondered whether the accessibility client (e.g. VoiceOver) is expected to localise.