Format a hotkey for aria-keyshortcuts

[sss-Mihail-sss]

The problem

A control that has a shortcut should announce it to screen readers with aria-keyshortcuts. Today the hotkey is written once for useHotkey and a second time by hand for the attribute:

useHotkey(appHotkeys['search.open'], open) // 'Mod+K'

<button aria-label="Search" aria-keyshortcuts="Control+K Meta+K" onClick={open}>
  Search <kbd>{formatForDisplay(appHotkeys['search.open'].hotkey)}</kbd>
</button>

The two drift apart when the default changes, and the attribute never follows a user's custom hotkey (useCustomHotkeys). formatForDisplay doesn't fit: it gives symbols for people (⌘K), and ARIA wants the spec's modifier names and KeyboardEvent.key values (Meta+K).

Proposal

A formatter next to formatForDisplay:

formatForAria(hotkey: Hotkey | ReadonlyArray<Hotkey>, options?: { platform?: Platform }): string | undefined

• Mod becomes Meta on macOS and Control elsewhere. Without a platform (on a server, or in a static shell that doesn't know the user's OS) it gives both alternatives, Control+K Meta+K, so the attribute is correct for everyone and hydrates the same.
• Modifiers as ARIA names them: Control, Alt, Shift, Meta; keys as KeyboardEvent.key values (/, Escape, ArrowUp), with Space for the space bar.
• Several hotkeys become space-separated alternatives: formatForAria(['Mod+K', '/']) → Control+K Meta+K /.
• A sequence (['G', 'H']) has no ARIA form; it is left out, and undefined when nothing is left, so the attribute isn't rendered.

And in the React adapter, for app hotkeys, a hook that follows custom hotkeys:

const aria = useAriaKeyShortcuts(appHotkeys['search.open'], appHotkeys['search.slash'])

<button aria-keyshortcuts={aria} …>

It would read the effective hotkey (the user's custom one or the default) and the provider's platform, like useFormatForDisplay.

What we do now

A small helper in the app that replaces Mod+ with both Control+ and Meta+ and drops sequences. It works for our three shortcuts, but it doesn't know custom hotkeys or key-name details, which the library already parses.

Happy to send a PR if the shape looks right.