Skip to content

Format keyboard shortcuts according to OS conventions #258

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Nov 3, 2021

Conversation

jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Nov 2, 2021

Fixes #151
Fixes #255
Closes #256

This formats keyboard shortcuts to OS conventions on Windows and macOS. It reverts #252 and supersedes #256.

I checked with VoiceOver, and it appears that these glyphs are recognized correctly on Catalina when speaking shortcuts on menu items, etc. (i.e., the curvy arrow is correctly pronounced "return" when reading the keyboard shortcut). I pulled the Windows formatting conventions by looking at how custom keyboard shortcuts are formatted in Microsoft Word (IIRC), but it would be good to double-check those.

This reverts commit 57a6ee7.

It was not clear in issue jupyterlab#151 calling for a change in formatting of arrows that arrows should not be treated as modifier keys.
const MAC_DISPLAY: { [key: string]: string } = {
Backspace: '⌫',
Tab: '⇥',
Enter: '↩',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⏎ might have a closer semantic meaning, but will often render as a less familiar icon

Copy link
Contributor Author

@jasongrout jasongrout Nov 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In VoiceOver, your character ⏎ is read as "return symbol", whereas the one in the PR (↩) is read as "return" (when they are in the place of keyboard shortcuts on a menu). I think the one in the PR is the official one to use.

Copy link
Member

@krassowski krassowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, especially for the current use case of displaying the shortcuts as labels.

For better accessibility we could implement aria-keyshortcuts. I guess that would be another function taking the keystroke and returning the aria-label (or maybe formatKeystroke could return both {label: string, aria: string} in a future major version). If it makes sense I will open a new issue to track this accessibility improvement.

@jasongrout
Copy link
Contributor Author

jasongrout commented Nov 3, 2021

If it makes sense I will open a new issue to track this accessibility improvement.

+1

Huh, the Aria Shortcuts document seems to vindicate a decision we made about how shortcuts are specified that sometimes people call us out on as controversial or confusing:

If the character used is determined by a modifier key, the author MUST specify the actual key used to generate the character, that is generated by the key, and not the resulting character. This convention enables the assistive technology to accurately convey what keys must be used to generate the shortcut. For example, on most U.S. English keyboards, the percent sign "%" can be input by pressing Shift+5. The correct way to specify this shortcut is "Shift+5". It is incorrect to specify "%" or "Shift+%".

For example, we don't say a shortcut is Ctrl +, instead we say it is Ctrl Shift = on a US keyboard.

@jasongrout
Copy link
Contributor Author

Thanks for the review @krassowski!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Change in arrow keys handling broke contract Format arrow shortcuts as arrow glyphs
2 participants