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

Adjust clashing shortcuts used for character input #14681

Merged
merged 3 commits into from
Apr 12, 2019
Merged

Conversation

ellatrix
Copy link
Member

@ellatrix ellatrix commented Mar 28, 2019

Description

Fixes #13118. Replaces the shift+alt combination with the "standard" WordPress access combination.

Also adds a check to KeyboardShortcuts to prevent this mistake from happening in the future.

How has this been tested?

Screenshots

Types of changes

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.

@ellatrix ellatrix added the [Type] Bug An existing feature does not function as intended label Mar 28, 2019
@ellatrix ellatrix added this to the 5.4 (Gutenberg) milestone Mar 28, 2019
@draganescu
Copy link
Contributor

This is great! It globally replaces Shift+Alt with Ctrl+Alt (on OSX). This is also the basic behaviour (Ctrl+Alt) that the HTML accesskey has:

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey

I tested and it worked as described, but I am not aware if this has other implications.

@draganescu
Copy link
Contributor

@afercia @mcsf would you think is is actually a better solution than solving one individual shortcut? It also addresses @talldan 's suggestion to update all shortcuts. 'accesskey' seems a viable way to handle generic shortcuts that use one letter.

@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Mar 29, 2019
@afercia
Copy link
Contributor

afercia commented Mar 29, 2019

It has already been pointed out that the "standard" WordPress access combination is a problem, as it conflicts with native shortcuts used on macOS for VoiceOver. See for example:

Keyboard shortcuts that use the access modifier don't work with VoiceOver
#11154

Help shortcut conflicts with VoiceOver Help shortcut (Mac)
https://core.trac.wordpress.org/ticket/39271

So this is a known issue, and I'm not sure why we'd want to keep using access.

In #11154 I've also linked to a useful resource by the W3C: in the new WAI-ARIA Authoring Practices 1.1 there's a section dedicated to keyboard shortcuts. It's more about what not to do, see: https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_shortcuts_assigning

There's a list of combinations to avoid and, among others, it's clearly stated to avoid:

macOS only: Control+Option + any combination of other keys.

Also:

It globally replaces Shift+Alt with Ctrl+Alt (on OSX)

This actually means all these shortcuts are not available to VoiceOver users so I'm afraid I can't support this change as it creates an accessibility barrier.

@ellatrix
Copy link
Member Author

@afercia I'm very well aware that access has its own problems, and that we should move away from that combination as well. For now, this is the quickest solution. The shift+alt combination needs to go away as soon as possible.

Which VoiceOver commands will clash with these two?

Other options:

  • ctrl+option+↑ and ctrl+option+↓
  • ctrl+option+tab and ctrl+option+shift+tab

@afercia
Copy link
Contributor

afercia commented Mar 29, 2019

@ellatrix thanks. Can you please clarify globally replaces Shift+Alt with Ctrl+Alt? At a first reading, I got it was going to use access everywhere. Looking at the code, seems to me it's changing only the navigate region shortcuts.

Anyways, here's a list of the VoiceOver commands, where VO stands for Control+Alt:
https://www.apple.com/voiceover/info/guide/_1131.html

Other options:

  • ctrl+option+↑ and ctrl+option+↓
  • ctrl+option+tab and ctrl+option+shift+tab

VO + Down and Up arrows are widely used for navigation and to change settings;
VO + Tab is used to "Tell VoiceOver to ignore the next key combination"

@talldan
Copy link
Contributor

talldan commented Apr 1, 2019

@ellatrix This looks good. There's one extra place to update the documented shortcut:
https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/faq.md#editor-shortcuts

@talldan
Copy link
Contributor

talldan commented Apr 1, 2019

Looking at the code, seems to me it's changing only the navigate region shortcuts.

@afercia - I can help answer that. My understanding is that the two navigate regions shortcuts are the only ones bound in Gutenberg that are using shift+alt on mac os, which is where the problem is.

Copy link
Contributor

@draganescu draganescu left a comment

Choose a reason for hiding this comment

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

Hi @ellatrix there is this doc file that should be updated once the shortcuts are changed,
https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/faq.md#editor-shortcuts

Do you have the time to update it or may I edit your PR?

Otherwise with the follow-up confirmation from @talldan I think we're good to go!

@talldan
Copy link
Contributor

talldan commented Apr 11, 2019

@draganescu yep, I'm happy. It might be worth just pushing the changes to that file in a commit and then merging. I'm sure @ellatrix won't mind.

@draganescu
Copy link
Contributor

rebased, updated the docs and inlined the script based on @aduth suggestion

@ellatrix
Copy link
Member Author

Thanks for the updates @draganescu!

@ellatrix ellatrix merged commit dd81bcc into master Apr 12, 2019
@ellatrix ellatrix deleted the fix/input-shortcuts branch April 12, 2019 15:12
mchowning pushed a commit to mchowning/gutenberg that referenced this pull request Apr 15, 2019
* Adjust clashing shortcuts used for character input

* Update modal

* adds docs correction to correspond, adds inlined script to remove production dead code
aduth pushed a commit that referenced this pull request Apr 16, 2019
* Adjust clashing shortcuts used for character input

* Update modal

* adds docs correction to correspond, adds inlined script to remove production dead code
aduth pushed a commit that referenced this pull request Apr 16, 2019
* Adjust clashing shortcuts used for character input

* Update modal

* adds docs correction to correspond, adds inlined script to remove production dead code
This was referenced Apr 17, 2019
forEach( this.props.shortcuts, ( callback, key ) => {
if ( process.env.NODE_ENV === 'development' ) {
const keys = key.split( '+' );
const modifiers = new Set( keys.filter( ( value ) => value.length > 1 ) );
Copy link
Member

Choose a reason for hiding this comment

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

Won't this capture much more than just modifiers, like escape, or space, or tab ? While ultimately it has no impact one way or the other since the subsequent lines only care to check for alt or shift specifically, it begs the question at that point why to filter at all (vs. hasAlt = keys.includes( 'alt' )).

( modifiers.size === 1 && hasAlt ) ||
( modifiers.size === 2 && hasAlt && hasShift )
) {
throw new Error( `Cannot bind ${ key }. Alt and Shift+Alt modifiers are reserved for character input.` );
Copy link
Member

Choose a reason for hiding this comment

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

I guess it's expected this should crash the application (to make the problem exceedingly obvious)? As there's been some prior conversation at #13405 and alternative approaches at #14151 to address these sorts of "wrong usage" violations, it seems we might consider having a unified approach to when and how they should be introduced. Personally I'd favor ESLint rules since they can be captured at build-time than at runtime, but I could grant that (a) there's more effort involved in creating the rules (though not always) and (b) this assumes that the developer has opted into using ESLint and the custom rules, which is not a given.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CZ quotation marks in Gutenberg don’t work
6 participants