Skip to content
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

Shortcuts: a way forward? #15190

Open
ellatrix opened this issue Apr 25, 2019 · 1 comment
Open

Shortcuts: a way forward? #15190

ellatrix opened this issue Apr 25, 2019 · 1 comment
Labels
[Feature] Rich Text Related to the Rich Text component that allows developers to render a contenteditable [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).

Comments

@ellatrix
Copy link
Member

ellatrix commented Apr 25, 2019

Shortcuts have always been a bit problematic:

  • they can be remapped by the user,
  • they may conflict with the OS, browser, or assistive technologies,
  • and some keys may not be available by the user, as keyboard layouts changes based on the OS and language.

Examples:

Solution: we need to look at intention instead of trying to interpret key combinations.

Key interpretation must be removed if it includes at least one key that is not universal. For example: A, B, C...
In editable areas (textarea and contenteditable), the InputEvent.inputType can be used. For example: formatBold means the user wants to format something bold.
The problem is that this cannot be used for block selection. When a modifier key is pressed (Ctrl, Cmd or Alt/Option), we could insert an invisible textarea with two characters and place the caret in the middle. Attach input and selectionChange event listeners. With these we can see if the user wants to select all content (check selection), undo or redo something (historyUndo, historyRedo), or delete something (deleteContentForward). If the modifier key is released again, restore focus to the block wrapper.

There one thing that is hard to resolve however: documentation for these shortcuts. We are completely unaware which key combination would be the right one for e.g. bolding text. We could make the combination text translatable though, and note in the shortcut modal that it may not be accurate if your OS language is different or if you have mapped the shortcuts.

Thoughts? Cc @afercia.

@ellatrix ellatrix added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Feature] Rich Text Related to the Rich Text component that allows developers to render a contenteditable [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... labels Apr 25, 2019
@afercia
Copy link
Contributor

afercia commented May 2, 2019

Related: #15335, #3218 (October 2017).

I'm not fully sure I understand how inputType can be used to avoid keyboard shortcuts conflicts. Probably I'm missing something 🙂

Re: the translations issue, I'd just note that historically most of the keyboard shortcuts on Windows don't change depending on the language. I guess that's to make them consistent across languages. Also, I'm guessing (operating systems aren't really my area of expertise) that the responsibility to change keyboard shortcuts depending on the language is up to the single applications. For example, see below the Windows Notepad, in English and Italian:

notepad English

notepad Italian

Most fo the keyboard shortcuts don't change. Only "Find" does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Rich Text Related to the Rich Text component that allows developers to render a contenteditable [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).
Projects
None yet
Development

No branches or pull requests

3 participants