CZ quotation marks in Gutenberg don’t work

[sibiranka]

Describe the bug
Gutenberg doesn’t react to Czech quotation marks: „ and “

To Reproduce
Steps to reproduce the behavior:

1. Press cmd+n (for „) or cmd+h (for “)
2. See that nothing happens
3. Be sad and start your GitHub account to report this bug

Desktop (please complete the following information):

• OS: MAC OS Mojave
• Browser: Chrome
• Version: 70.0.3538.110

Additional context

• Gutenberg version: 4.7.1

[draganescu]

Hi @sibiranka welcome to project Gutenberg's Github.

The commands for „ and ” with a CZ keyboard layout are Shift + Option + N and Shift + Option + J and it appears that using Gutenberg Shift + Option + J works and inserts ” but Shift + Option + N is bound to a specific action inside the editor:

Navigate to a the next part of the editor (alternative). | Shift+Alt+N | ⇧⌥N

https://wordpress.org/gutenberg/handbook/contributors/faq/#are-there-keyboard-shortcuts-for-gutenberg

I believe other locales may be affected by binding the shift + option + LETTER keys because it is OSX's way to allow for extra special chars.

[talldan]

Hi @afercia—If I remember correctly, you know a bit about these shortcuts?

I think the only way forward might be to change these shortcuts to something else. 😢

[afercia]

In the Gutenberg accessibility report, it was noted that keyboard shortcuts create their own problems and are very likely to produce conflicts with existing shortcuts.

Different browsers on different operating systems, assistive technologies, different locales: they all implement different shortcuts and it's basically impossible to avoid conflicts. That's one of the main reasons why Gutenberg shouldn't rely on keyboard shortcuts: they can help but they shouldn't be the only solution to usability and accessibility problems.

That said, the only way to mitigate this problem is a mechanism to allow users to remap the existing keyboard shortcuts. This was pointed out in #3218 one year and a half ago 🙂

[mcsf]

A couple of thoughts:

• How reliably could we have RichText look at input chords (such as Option-Shift-n) and determine whether to let it bubble up to be picked up as a keyboard shortcut (such as navigating to the next part of the editor) or, if the input event carries a character sequence we deem valid (such as „), catch it so that the characters are inserted and the keyboard shortcut isn't fired? cc @iseulde

• Assuming we have alternative ways to navigate around the editor with the keyboard (presumably with a tabbing-oriented method), could we let locale managers decide whether a shortcut should be suppressed? There are precedents of locales handling technical aspects, such as delegating decisions on font families. Example:

// Translators: Use this to specify an alternative shortcut that doesn't interfere with
// character input in your locale's typical keyboard layouts. Do not translate.
// Set to 'off' to disable the shortcut.
shortcut = _x( 'Option-Shift-n', 'Keyboard shortcut: Navigate to the next part of the editor' );

Aside: I used Emacs key notation for the examples above Edited for clarity.

[draganescu]

Could we start the mechanism to remap the existing keyboard shortcuts by simply allowing users to disable certain shortcuts? I am thinking a basic local storage key / value that won't map the shortcut to the listener if present.

Then, in the UI, we could go for something like:

I am thinking that a full blown keyboard shortcut manager is a complex feature, finding actions, registering keys as shortcuts and so on and so forth. Disabling some defaults is easy and can be linked to a manual page. In theory, we could also detect if a user is struggling with shortcuts and suggest them to review the list :)

Also 👍for @mcsf 's idea with * locales handling these situations on a one by one basis.

[marekhrabe]

Disabling shortcuts sounds like a good idea that can probably happen the fastest. I'm all for it 👍

However, it still feels like a band aid - we know certain shortcuts will be always broken in certain locales. And not even locales because this really depends on the keyboard layout, not a locale. I'm using English interface with Czech keyboard layout. As far as I know this is undetectable in the browser environment 😕

[ellatrix]

Any reason not to use something like alt+tab?

[marekhrabe]

alt+tab is a system shortcut on Windows for switching between apps (like cmd+tab on mac).

It's a tough problem as most of those shortcuts that "make sense" are already used by the operating system or a browser for a different purpose. In general, you are right about trying to figure out a shortcut that doesn't involve keys with potentially printable chars.

[ellatrix]

Is there any combination free on Windows? We could use alt+tab on Mac and ?+tab on Windows, just like we have this distinction for cmd/ctrl.

[marekhrabe]

I haven't used Windows in last 10 years but I believe tab shortcuts might be taken.

• alt turns it into app switching
• ctrl turns it into browser tab switching

In both cases, the combination with shift works too, just browses things in reverse order so we cannot use that either.

Maybe ctrl+alt+tab and ctrl+alt+shift+tab could be used? I don't have means to test it myself. Edit: definitely taken on Ubuntu, Windows not confirmed. https://defkey.com/what-means/ctrl-alt-tab

[ellatrix]

Isn't there also the AltGr and Windows modifier keys. Or is the presence on the keyboard inconsistent?

[ellatrix]

Another dumb idea: press one of the modifier keys (maybe ctrl/cmd) for x amount of seconds, or maybe better, twice uninterrupted, and switch between "tab modes". Normally it tabs between elements, otherwise between areas. Do the same thing to switch back. Of course, this should have audible and visual feedback etc.

[marekhrabe]

AltGr presence is not consistent but mainly, it's roughly equal to pressing ctrl+alt instead of being a unique detectable modifier key https://en.wikipedia.org/wiki/AltGr_key#Control_.2B_Alt_as_a_substitute

[mcsf]

Another dumb idea: press one of the modifier keys (maybe ctrl/cmd) for x amount of seconds, or maybe better, twice uninterrupted, and switch between "tab modes". Normally it tabs between elements, otherwise between areas. Do the same thing to switch back. Of course, this should have audible and visual feedback etc.

This is reminiscent of #5709, which also hinged on separate modes for tabbing/navigating.

[ellatrix]

@mcsf Any learned lessons there? What do you think about the tabbing modes?

[draganescu]

Hi @ellatrix! I think the main problem with 'modes' is that they're based on short term memory, keeping in mind what mode you're in. That means we'd need a visual or/and other kind of helper that alerts the user on what mode they're currently in. Would it reset when leaving the page?

I have 'mouse keys' set to turn on after X times pressing 'some' key and I never know how to revert back b/c I never remember which key it is. I use the mouse to disable mouse keys :))) If I blog once a week switching KBD shortcut modes in GTB might be just as hard, all that just insert a quote sign! :)

[ellatrix]

@draganescu Yeah, I know the problem. :) The fact that the areas are clearly marked when you navigate through them could tell me that I'm in this mode. To go back to the "normal" mode, you could press escape or again double press ctrl/cmd. We could also show a message during that mode if escape or the combination is not enough. Leaving the page would escape the mode too.

[ellatrix]

Something else that we could do is return to normal mode on click. So then we'd have: click, escape, or press cmd/ctrl twice to go back.

[mcsf]

Any learned lessons there? What do you think about the tabbing modes?

There was a lot of discussion there, and I'd have to dig back in to refresh my memory. However, Andrei identifies one of the salient issues:

I think the main problem with 'modes' is that they're based on short term memory, keeping in mind what mode you're in. That means we'd need a visual or/and other kind of helper that alerts the user on what mode they're currently in. Would it reset when leaving the page?

Related to that, I think one important point of criticism with modes was that, just like arbitrary keyboard shortcut, they avoid the question of a clear tab-ready flow through the application. IIRC.

[talldan]

I personally think we should change those shortcuts, as they conflict for quite a wide number of users, and most would have the expectation that the key combinations for those quotation marks work out of the box.

The 'access' modifiers (Ctrl+Option on Mac / Shift+Alt on Windows) might be decent options for the shortcut if we can test they don't clash. Could probably still use 'N' and 'P', which would mean the shortcuts only change for Mac users.

Here's a big spreadsheet where I've tried to compare Gutenberg shortcuts against browser/os shortcuts, though it might be a bit out of date now:
https://docs.google.com/spreadsheets/d/1nK1frKawxV7aboWOJbbslbIqBGoLY7gqKvfwqENj2yE/edit?usp=sharing

[afercia]

The 'access' modifiers (Ctrl+Option on Mac ...

See #11154. I'd like to remind it's not just about browser/os shortcuts (which may change based on the locale). It's also about assistive technologies shortcuts. Also, default shortcuts may change for a variety of reasons. There's really very little chance to find key combinations that don't conflict with anything. That's also the reason why any software shouldn't rely exclusively on keyboard shortcuts.
Seems to me #3218 is still the only solid approach.

For reference, I've already mentioned in another issue that in the new WAI-ARIA Authoring Practices 1.1
there's a pretty good section dedicated to keyboard shortcuts. It's more about what not to do:
https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_shortcuts_assigning
There's a list of combinations to avoid including (macOS only) "Control+Option + any combination of other keys".

[talldan]

That's unfortunate. Shift+Option+Command is the other option.

I still feel strongly that the shortcut should be changed. A user shouldn't have to change a setting to be able to type punctuation—this is an editor for the written word.

[afercia]

I still feel strongly that the shortcut should be changed.

All the shortcuts have the same potential problem 🙂 It's certainly possible to consider to change this specific shortcut but still we're not solving the broader issue.

this is an editor for the written word.

It's a web application too. Not a full-page editor application like Google Docs and the like. Thus, it has to balance two (often conflicting) needs: keyboard navigation through the interface and preserving native text input/selection keystrokes.

[mcsf]

I still feel strongly that the shortcut should be changed.

All the shortcuts have the same potential problem 🙂 It's certainly possible to consider to change this specific shortcut but still we're not solving the broader issue.

This specific improvement is orthogonal to two other discussions mentioned here:

• Allowing customisation of shortcuts (Allow users to customize keyboard shortcuts #3218)
• Not requiring the use of keyboard shortcuts, i.e. making sure plain keyboard interactions are enough (Steps to make keyboard navigation usable #11581, Improve keyboard navigation between the block inspector and the block content #13663, etc.)

As it's orthogonal, let's make the change. We won't ever fix shortcuts for everyone, but will improve things for many.

[afercia]

let's make the change. We won't ever fix shortcuts for everyone, but will improve things for many.

Till the new shortcuts will conflict with something else 🙂

[mcsf]

let's make the change. We won't ever fix shortcuts for everyone, but will improve things for many.

Till the new shortcuts will conflict with something else 🙂

That's fine, we'll reassess then. Presumably by then there'll be a solution set up to disable problematic shortcuts, whether per locale or per other criteria.

[afercia]

That's fine,

I kindly disagree. I don't see how a solution that isn't a solution can help in any way. Added the accessibility label as the change proposed here impacts a11y.

[mcsf]

I don't see how a solution that isn't a solution can help in any way.

Shortcuts can be problematic in many ways. Some of them we have identified, some we haven't yet. They will also impact a11y. Which is why I think this is an important area to work on, and why I identified separate discussions that fit into it. However, right now, people on Czech keyboard layouts can't input Czech quotation marks, and it's likely that other configurations are similarly affected. I'd rather fix that identified case now and reassess our possibilities as we go. A partial solution remains a solution.

[ellatrix]

This is an issue for every keyboard in every language on a Mac. Shift+Alt is reserved for character input. In my case, I cannot insert ∏ and ˜. Alt and Shift+Alt modifiers should be forbidden. :)

[ellatrix]

#14681 should fix this issue.