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

Allow users to customize keyboard shortcuts #3218

Open
afercia opened this issue Oct 28, 2017 · 87 comments
Open

Allow users to customize keyboard shortcuts #3218

afercia opened this issue Oct 28, 2017 · 87 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback. Needs Dev Ready for, and needs developer efforts [Type] Task Issues or PRs that have been broken down into an individual action to take

Comments

@afercia
Copy link
Contributor

afercia commented Oct 28, 2017

Edit: Discussed during today's (March 1st 2018) bug scrub and agreed to consider a generic mechanism to allow users to customize keyboard shortcuts. Chances of conflicts are very high for any shortcut and many users would be unable to use the related features.

----- Original description:

Follow up to #3084

Keyboard navigation through the editor regions is currently implemented with the shortcuts ctrl+backtick and ctrl+shift+backtick, inspired by what Slack does.

However, not all the keyboard layouts have a physical key for the backtick. See for example the Italian keyboard layout. See the relevant discussion on #3084

until we find a single keyboard shortcut that's actually a standard, the closest is what we have here with ⌘+` that Slack uses. It seems worth trying this.
We could then supplement it, or replace it, with a simpler shortcut that doesn't change between keyboards, if we can find a good idea for what that should be.

Worth noting Slack has preferences for the language and the keyboard layout, though at the moment that's limited to just 4 languages.

A few options to consider:

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

afercia commented Oct 28, 2017

Gmail for example, does use Cmd/Ctrl + Shift shortcuts but uses also single key shortcuts or combinations of character keys:

screen shot 2017-10-21 at 15 21 54

screen shot 2017-08-11 at 14 30 35

As mentioned in #3084 single key shortcuts work, when not inside an editable field. Screen readers use single key shortcuts but they already have their own mechanisms to jump through landmark regions.

@aardrian
Copy link

Drive-by commenting here, but are we primarily concerned with only Latin or Western languages?

If so, then finding a shared key may be possible (if awkward). If not, then prior i18n experience suggests different languages / sets of languages will need to have different key mappings and we'll still need to allow users to customize anyway.

@afercia afercia mentioned this issue Jan 11, 2018
35 tasks
@afercia afercia changed the title Find a better shorcut to navigate the editor regions Consider a mechanism to customize shortcuts, e.g. Cmd/Ctrl + backtick Mar 1, 2018
@afercia
Copy link
Contributor Author

afercia commented Mar 1, 2018

Quoting ATAG A.3.1.5 https://www.w3.org/TR/2015/REC-ATAG20-20150924/#sc_a315

Customize Keyboard Access: If the authoring tool includes keyboard commands, then those keyboard commands can be customized.

The intent of this success criterion is to ensure that authors using a keyboard interface on platforms that support keyboard commands have the ability to remap the authoring tool's default keyboard shortcuts in order to avoid keystroke conflicts, use familiar keystroke combinations and optimize keyboard layout (e.g. for one-handed use).

@afercia afercia added this to the Merge Proposal milestone Mar 19, 2018
@afercia afercia changed the title Consider a mechanism to customize shortcuts, e.g. Cmd/Ctrl + backtick Consider a mechanism to customize shortcuts, e.g. Ctrl + backtick Apr 3, 2018
@karmatosed karmatosed modified the milestones: Merge Proposal, Merge Proposal: Accessibility Apr 12, 2018
@afercia
Copy link
Contributor Author

afercia commented Apr 12, 2018

Investigating on #5847 / #6144 I've read some Mousetrap (the tool used by Gutenberg to implement keyboard shortcuts) documentation. Reference:
https://craig.is/killing/mice
https://github.com/ccampbell/mousetrap

Worth noting that also sequences of keystrokes work, see https://craig.is/killing/mice#api.bind.sequence and also shortcuts that include sequences and combinations. For example, pressing Command (or Ctrl) twice would work. This opens up new possibilities, and maybe it's something easier to implement than customizable shortcuts. Any thoughts more than welcome. /cc @aardrian @rianrietveld @joedolson @samikeijonen etc.

@karmatosed karmatosed removed this from the Merge Proposal: Accessibility milestone Apr 13, 2018
@aardrian
Copy link

I do not know where else to put this, but please be cautious when applying keyboard shortcuts, particularly when using Slack as an example. Slack has made its accessibility worse for screen reader users who rely on keyboard navigation. This Twitter exchange between a skilled SR user and the Slack guy in charge of accessibility demonstrates that disconnect: https://twitter.com/LeonieWatson/status/974615133044359168

Further, many screen reader users and many keyboard-only users have motor impairments that make many complex (or even simple) combos possible. Shortcuts may be a nice add-on for many users, but they are not a guaranteed accessibility fix (so it is ok to have them, but don't make those the only means of interaction for a feature).

@aardrian
Copy link

@afercia

Investigating on #5847 / #6144 I've read some Mousetrap (the tool used by Gutenberg to implement keyboard shortcuts) documentation. Reference:
https://craig.is/killing/mice
https://github.com/ccampbell/mousetrap

Fired it up with NVDA. The first example on the page is to hit the 4 key to highlight the first line of code. Without NVDA it works fine. With NVDA, since NVDA (rightly) captures keystrokes, it jumps me to the first <h4> on the page.

In order to pass the key through to the OS, bypassing NVDA, I need to use NVDA Key + F2 and then I can hit 4. (note that NVDA Key will be either Caps Lock or Insert depending on the user's configuration).

In my experience, few screen reader users know what their passthrough key combo is, let alone know when or how to use it.

That being said, in a very quick glance at the library, I saw no statements about how to implement it and account for screen readers. The answer from the developer may be "Meh", which should be documented if that is the approach.

@karmatosed karmatosed added this to the Merge Proposal: Accessibility milestone Apr 13, 2018
@afercia
Copy link
Contributor Author

afercia commented Apr 13, 2018

@aardrian thanks. Yep I'm aware the passthrough key is not so used, and I'd say it's not acceptable to ask users to use it. I haven't looked at the Mousetrap examples, however the good part is that Mousetrap is "agnostic" and allows to really use any shortcut. It's up to the implementation to make them work with AT for example making SR enter forms mode or application mode where appropriate.

Shortcuts are probably more useful for pro-keyboard users (non screen reader users). Worth nothing the Ctrl + backtick shortcut mentioned here basically matches the ARIA landmarks so screen reader users can just use their screen reader to jump through landmarks.

@aardrian
Copy link

Ah, I get it. The things you want to designate as targets for Ctrl + backtick correspond to named regions / landmarks. I like that.

@afercia
Copy link
Contributor Author

afercia commented Apr 13, 2018

Yep, it's an attempt to emulate landmarks for non-screen reader users 😆

@afercia
Copy link
Contributor Author

afercia commented Apr 16, 2018

Just to confirm the "Ctrl + backtick" shortcut doesn't work on various non-English layout keyboards and thus the ability to jump through the main editor sections is not available to all users (see also #1182):

  • not available on an Italian keyboard layout (@afercia)
  • not available on a Dutch keyboard layout (@rianrietveld)
  • not available on a Finnish keyboard layout (@samikeijonen)
  • not available on a French keyboard layout (@audrasjb)
  • likely way more

@fuzzbomb
Copy link

fuzzbomb commented Apr 25, 2018

Yep, it's an attempt to emulate landmarks for non-screen reader users

Facebook has an interesting approach to landmark navigation. A landmarks menu as an early tab-stop on the page, where you'd often find a skip-to-main link. I think it's notable, because I presume a lot of keyboard users have found it already. I'm not a Facebook user myself, but it's used on the sign-up screen too, so I played with it there.

Description here: https://a11ywins.tumblr.com/post/170270963528/facebook-ax-navbar

@samikeijonen
Copy link
Contributor

That's interesting approach. I actually logged in to Facebook the test it out, worked as described.

@afercia
Copy link
Contributor Author

afercia commented Apr 25, 2018

@fuzzbomb interesting. I see they use Alt + / to invoke the menu, so the keyboard shortcut issue still stands. On my Italian keyboard for example I'd need to press Shift+7 to get a slash /. Not sure about other keyboard layouts but it would probably still need some kind of customization mechanism. (@samikeijonen where's the slash / on your Finnish keyboard?)

However, you made me think at a core Trac ticket that asked to make the existing Skip link accessible to developers (see https://core.trac.wordpress.org/ticket/36644). While the proposal there is not exactly the same thing, I'm now wondering: what if we try to make the existing Skip link extensible, i.e. more skip links can be added there via a filter or something?

screen shot 2018-04-25 at 09 02 45

Then, it should be changed to an ARIA menu with arrows navigation and it would be great to have a customizable shortcut to invoke it.

@samikeijonen
Copy link
Contributor

@afercia Same here with /, I could not access with Alt + /. But at least it was the first Tab stop.

@afercia
Copy link
Contributor Author

afercia commented Apr 25, 2018

@samikeijonen thanks. That's the point, we need a tool users can access when focus is in the Gutenberg UI 🙂

@jasmussen
Copy link
Contributor

we need a tool users can access when focus is in the Gutenberg UI 🙂

For the sake of argument and pretending it would be the easiest thing in the world: what if we were to add regions to all of the WordPress UI, not just Gutenberg — would this be an a11y benefit?

@fuzzbomb
Copy link

fuzzbomb commented Apr 25, 2018

Sure, the Facebook landmark navigation can be accessed via a keyboard shortcut, but you can also get there quickly by tabbing after loading a page. The ALT+slash would be just another customizable shortcut.

The thing that interests me about Facebook's approach, is it includes links to their accessibility help pages too, but keeps the whole region to a single tab-stop. The region isn't just a fancy skip-link alternative, it's a region for a11y tools in general.

Now, you could potentially add other things there too, like a headings navigation drop-down, or... links to customize accessibility settings per user. So that's where a mechanism to customize keyboard shortcuts could live - in an a11y-tools region, just one TAB key (and a couple of arrows) away from the start of the page. If ALT+/ doesn't suit you, a keyboard-only user could still find a way into customizing that without much effort.

An always-visible button to reveal the "accessibility tools" region could live on the main toolbar, quite unobtrusively. So the a11y tools region is easily reached by a single TAB after loading the page, or lots of Shift-TABs form somewhere in the middle of the page, or a mouse click, Dragon, or whatever keyboard shortcut it has.

I don't know how many shortcuts are being proposed, but I think something on the scale of Gmail is too much. One way to avoid excess would be a system where lots of actions can have a keyboard shortcut, but most of them are unassigned by default (an empty setting). KDE Plasma desktop and GNOME desktop do it this way.

(For what it's worth, Ctrl+backtick is used by Ubuntu Unity desktop for "cycling through windows in the current application", while KDE Plasma uses Alt+backtick, and GNOME uses Win+backtick, and macOS uses Splat+backtick for the same task. So it goes.)

Going even further, keyboard shortcuts could be completely turned off by default - users would have to opt-in, but there'd much less risk of frustrating assistive tech users with key conflicts. For users who want them, I'd trust the handbook, and all those "10 things to do after installing WordPress" articles to get the word out. Imagine if everyone was told to check out the accessibility settings link....

P.S. I'm a Drupal a11y maintainer, rather than a WordPress contributor. I found this issue because I follow WP-a11y news. We don't have any keyboard shortcuts yet, we've preferred basic sequential keyboard controls. I expect it's a matter of time before we need to look at this issue in Drupal's authoring tools initiative too.

@afercia
Copy link
Contributor Author

afercia commented Oct 5, 2020

Thanks so much for the proposal and to help this issue finally move on.

Very first observations:

  • Besides the global "Restore defaults" button I think there's the need for a button for each single shortcut. As a user, I might want to reset a single, specific, keyboard shortcut to its defaults and not lose all the other custom shortcuts I previously set. Intead, the current UI allows only to reset them all or none.
  • We should avoid icon-only buttons and use buttons with visible text instead. Icon-only controls are an accessibility anti-pattern and we shouldn't use it, at least here since this is a user interface mainly targeted to users with accessibility needs. The "edit" icon for example should be replaced with plain, visible, text: "Edit".
  • Regarding "As you type the new desired shortcut keys combination, the characters appear in the input field" we need to consider that on Windows the modifier keys don't use single characters. They're plain text for "Ctrl", "Shift", "Alt"... so this would need a different technical mechanism but also the design should account for that. Screenshot of the current keyboard shortcuts list on Windows:

Screenshot (137)

I have some reservations on the following things:

  • The input field to enter a custom shortcut appears and replaces part of the UI: the accessibility team already pointed out this isn't a good pattern (see for example the discussion on the toolbars). It would be worth considering a disclosure pattern instead: click the Edit button, an input field is revealed after the Edit button in addition to the other UI elements.
  • The "Save" and "Cancel" buttons displayed inside the input field look weird to me and are potentially confusing for users. Besides details on technical implementation, I don't see the need to display them this way and I'd encourage a more standard, expected, placement of these buttons.
  • The "Cancel" button is another icon-only button which uses a "X". Besides the fact that the "X" suggests the idea of "closing" instead of "cancelling", also this button should use plain text instead of an icon.

Re: @alexstine's concern on conflicts: yes there should be a mechanism to detect conflicts and warn users that a keyboard shortcut is already in use. I think this is technically doable but yep, it's about implementation details while we're still on the initial design phase 🙂

@enriquesanchez
Copy link
Contributor

Thank you for the feedback, @alexstine and @afercia! Here's an iteration on the design that addressed some of the points you made.

Since we'd want to have the options to Edit, Disable and Restore for each individual keyboard shortcut, I'm looking at having these options surfaced in a popover menu instead:

Frame 34

The image above shows a list of keyboard shortcuts. For each item, there's a label/description on the left followed by the shortcut keys to the right in the same row. Next to that, there's an ellipsis menu button, similar to what's found in the editor and block toolbars. On one of these keyoard shortcuts, the ellipsis menu button is activated and a popover with three menu items appears below it: 'Edit shortcut, 'Disable shortcut', and 'Restore to default'. That last one, 'Restore to default' should only appear when/if the keyboard shortcut has been customized.

If I were to click on 'Edit shortcut', a dialog would appear in place. I agree with you @afercia, that this dialog should not replace any content. What I'm proposing is that the dialog sits on top and aligned with the keybord shortcut row for clarity and proximity. What I like about this solution is that the shortcut label/description is kept visible, so it's easier to correlate the two.

Frame 36

The image above shows a UI dialog that contains an input field with the keyboard shortcut combination, and a Save and Cancel buttons to the right of it.

As for conflicts, I think we need to show an error message in place, near the input field. Here's what I'm proposing:

Frame 37

The image above shows the previous UI dialog that appears when editing a shortcut. The input field has a red border around it to indicate an error state, and below it there's an error message that reads "This shortcut is already being used.". The 'Save' button is in a disabled state because the action cannot be performed.


What do you think about this iteration? I believe it addressed the feedback your brought up.

@alexstine
Copy link
Contributor

@enriquesanchez Sorry, now I am gonna be difficult.

Since we'd want to have the options to Edit, Disable and Restore for each individual keyboard shortcut, I'm looking at having these options surfaced in a popover menu instead:

From my point of view, I think a menu inside a dialog is not a good idea. It adds another required selection to get in to the menu and then find edit, delete, or restore. Anyway to just not put those in a menu?

I can see both sides... It will probably not fit well on smaller screens, but just something to think about.

Thanks.

@enriquesanchez
Copy link
Contributor

Sorry, now I am gonna be difficult.

Not at all @alexstine, I really appreciate your feedback and understand your point.

My reasoning for having these three options inside a menu was that having them exposed and repeating in every row, in a list of dozens of shortcuts, will add a lot of clutter and visual noise. That can make this UI hard to parse for some folks.

I'll definitively look at alternatives. One idea I had initially but haven't fully explored is to have these options exposed once you click on the 'Edit' button for the shortcut. We'll need a bigger dialog to fit everything, but I think it's worth a try.

@kellychoffman
Copy link
Contributor

Latest iteration feels close. Couple details to consider, but aren't blockers:

  • Popovers/modals usually have the CTA button (Save) to the far right.
  • Inline error message might be a bit awkward interaction in that the container has to resize for it to show. Might be worth exploring some other options here. A couple ideas that come to mind: have helper/instructional text in its place that gets replaced with the error msg, have the error show as a banner error on Save attempt, or something else.

@mariohamann
Copy link

  • Popovers/modals usually have the CTA button (Save) to the far right.

@kellychoffman To focus on the keyboard settings in this issue, I wrote a more general answer over here: #24965 (comment)

In short: I think Save-Buttons could be used contextually in relation to the preference category. Maybe keyboard settings could profit from one general Save button. What is better accessible? One single Save button or a save button for every shortcut? (Maybe that relates to the question when and where conflict errors should show up.)

@enriquesanchez
Copy link
Contributor

enriquesanchez commented Oct 12, 2020

@mariohamann This is great feedback Mario. Thank you!

Maybe keyboard settings could profit from one general Save button. What is better accessible?

I think it depends. If I'm only going to change one keyboard shortcut, then having the confirm button right there next to the shortcut field is definitively easier for most folks. I wouldn't have to navigate to find the Save button somewhere else below the list.

If I were to be changing a lot of these shortcuts, then maybe having only one Save button will be easier. That said, I suspect the latter will be the least common case here, and we should optimize for single-edit actions.

@enriquesanchez
Copy link
Contributor

  • Popovers/modals usually have the CTA button (Save) to the far right.
  • Inline error message might be a bit awkward interaction in that the container has to resize for it to show. Might be worth exploring some other options here

Thank you! Here are some iterations that address your feedback, @kellychoffman

error

I like the direction of using the default notices banner we use elsewhere. The notice is prominent and because it appears inside the modal, it's near where the error happens. There's also the benefit that these notices get properly communicated to assistive technologies with wp.a11y.speak().


I also explored alternatives on how to access the editing options (Customize, Disable, and Restore). In the previous exploration I looked at having a dropdown menu next to each shortcut with the three options:

95244122-2ed4e780-07d7-11eb-9180-ed998880cd11

The image above shows a list of keyboard shortcuts. For each item, there's a label/description on the left followed by the shortcut keys to the right in the same row. Next to that, there's an ellipsis menu button, similar to what's found in the editor and block toolbars. On one of these keyoard shortcuts, the ellipsis menu button is activated and a popover with three menu items appears below it: 'Edit shortcut, 'Disable shortcut', and 'Restore to default'.

This time I looked at how we could condense all three actions into a single dialog:

alt-edit

The image above shows a list of keyboard shortcuts. For each item, there's a label/description on the left followed by the shortcut keys to the right in the same row. Next to that, there's an Edit menu button. On one of these keyboard shortcuts, the Edit button is activated and a dialog sits right under it. The dialog has a text field with the shortcut key. This is where the user will be able to customize the shortcut. Below this text field, there's a toggle control with the label 'Disable shortcut'. This is the control users will activate if they want to diable the keyboard shortcut. Below follows a row of three buttons. The first one is 'Restore to default', which should only appear if the shortcut has been customized. Then follows 'Cancel' and 'Save'.

I'm torn between these two. On the one hand, I like the clarity of choices on the previous version and how it keeps the edit dialog minimal. But on the other, I like how this last exploration simplifies the flow by just offering one choice to make up front.

I'd love to hear your feedback or suggestions.

@mariohamann
Copy link

mariohamann commented Oct 13, 2020

Really like those explorations. I would like to add some thoughts about the visuals, I hope that's fine:

  • Notices banner: Personally I have the feeling the notice could deserve a bit more margin especially to the top. It feels a bit "urged". Maybe using the same margin as for the title (like "Keyboard shortcuts") would be fine, so it visually "replaces" the title?
  • Really love the last one. I would prefer the dialog field appearing ABOVE the edit button if there is enough space. As the shortcut is definetely changed with keyboard, the next possible interaction with the mouse would be clicking the "Save" button. Therefore, if the dialog appears above, the way with the mouse to the "Save" button is much shorter.
  • Another thing I'm asking myself: Would it support the process, if the shortcut being edited at the moment would be more emphasized (or the others being more reduced?). I think the current "blue" may be too decent to indicate the current state – especially in terms of a11y. Next image shows two ideas: The first one making the other non-selected items more transparent, the second one inverting the clicked button. The latter feels better for me. You can give it a try over here on Figma: https://www.figma.com/proto/WwbLC4uG5BGW38ZlCRh9uz/Preferences?node-id=8%3A66&viewport=-1374%2C108%2C0.36925479769706726&scaling=scale-down

image

Mockup of all three suggestions below.

image

@enriquesanchez
Copy link
Contributor

Here's one last update from me on this issue.

I've made some minor updates to the flow:

  • Reduced the amount of UI: I’m no longer using a popover inside the modal (thanks @alexstine for the feedback on this!)
  • Simplified a few actions such as restoring and disabling shortcuts: removed the buttons and toggles I was previously using. Added some clarification to the section's description on these: "These are the keyboard shortcuts available in the block editor. You can customize them to your needs or leave the field empty to disable them."
  • I’m now using the current shortcuts modal in the block editor to have a clearer picture of where these will live.

Here's a GIF of the updated prototype:

kbd-shortcuts

And some static mockups for a more detailed overview:

current UI

Description: The image above shows the keyboard shortcuts modal open in the block editor. The modal contains a list of all the shortcuts available and next to each an edit button (a pencil icon).


current UI-1

Description: Clicking the edit button for any of the shortcuts will display inline a text field with the currently assigned shortcut. Users can enter a different shortcut if needed. There is a save button next to the field.


current UI-2

Description: If the user enters a shortcut that is already being used, we display an error message "Shortcut already in use." below the field and highlight the field in red. This error message needs to also be communicated to Assistive technologies.


current UI-3

Description: If a field is left empty, the shortcut is disabled and a label "None" appears in place of the shortcut. Once a shortcut has been edited/modified, we display a little dot indicating that the shortcut has been customized. This should help uses keep track of which shortcuts they've modified. The dot should include a tooltip for clarity and this state change should also be communicated to assistive technologies.

If we find that the dot does not work here, we can also opt for an asterisk instead:

Screen Shot 2020-10-29 at 15 31 25


current UI-4

Description: A shortcut that has already been modified will show an additional "Restore" button when editing it. This restore button will appear next to the Save button. Clicking on restore returns the shortcut to the default value and closes the edit field.


I think the above is in a good place to try for a v1 of this feature. I did not spend much time on this, but for a follow up effort it'll be great to consider @mtias suggestion:

Should it be extensible? (I could imagine a plugin or a configuration set people could pull from the repo for, say, a good set of shortcuts for a Spanish keyboard layout on Mac, and so on.)

This could be as simple as adding an option to import a key bindings configuration:

current UI

Description: The image above shows the same keyboard shortcuts modal from this proposal with an additional button that says "Import configuration" just below the modal's description.

If we give this option to users, we should also offer a way for users to restore and go back to defaults.


And lastly, I also mocked up what the keyboard flow for this feaure will look like. Considering that this will be a feature that will greatly benefit keyboard users and users of assistive technologies, I thought it'll be important to consider how the flow will work in that scenario:

kbd-shortcuts-kbd

_Description: the gif above shows the keyboard focus flow of the same shortucts modal described above. It's a step by step flow of each focus stop needed to customize one shortcut field.

@mariohamann
Copy link

Really like those explorations!
At one point of your
last GIF I was a bit irritated: After having "written" a new shortcut, I would have expected to use return key to save it. In your GIF you are using tab to get to save button instead. I think you needed this to make it possible to reach the button to revert a setting? Otherwise I definitely would expect to press "return" to save shortcut and to press "escape" to forget new shortcut.

@mariohamann
Copy link

mariohamann commented Nov 5, 2020

What do you think about directly using an "Undo" icon to indicate changes and make it reversable? (Raised the space between "Undo" and "Edit" icon a bit in the following screenshot.)

That would even make the "Edit" flow cleaner, as the "Undo" there wouldn't be needed anymore. (In my opinion clicking outside of the edit area or pressing esc would revert the current changes as well.

image

@nickchomey
Copy link

nickchomey commented Aug 15, 2021

I'd just like to add my meager support to this effort. I find most of the keyboard shortcuts to be extremely laborious and unintuitive and would like to change most, if not all of them. The various mockups that I see above look wonderful, so I hope it'll get some focus soon to bring it to fruition!

@mtias mtias added [Type] Task Issues or PRs that have been broken down into an individual action to take and removed [Type] Enhancement A suggestion for improvement. labels Aug 16, 2021
@TheSimArchitect
Copy link

Nice! If/when implemented, will we be finally able to add shortcuts to things like superscript, subscript and strikethrough while editing, so we don't have to stop typing to use the mouse/menu?

That would be fantastic!

@eduwass
Copy link
Contributor

eduwass commented Feb 10, 2023

Would love to see this implemented! 👀 ❤️

@joedolson joedolson added the Needs Dev Ready for, and needs developer efforts label May 26, 2023
@joedolson
Copy link
Contributor

This would be a very beneficial change for some users; if we can get some dev attention on this, it would be much appreciated.

@alexstine
Copy link
Contributor

CC: @annezazu @jeryj. This is a good example of an issue that just stops after a while and should be picked up again by active contributors.

@annezazu
Copy link
Contributor

Thanks for noting. This does look like a big undertaking as is. Does this feel higher priority than other items you've mentioned?

@alexstine
Copy link
Contributor

I would not call it high priority compared to the other fires right now but would be nice to get it on the roadmap considering all the work already being done around commands in the site editor. There is no reason we shouldn't give users more power to choose their shortcuts to make editing a better experience. I do not want to see it become a forgotten issue.

@afercia
Copy link
Contributor Author

afercia commented Jan 19, 2024

After ongoing interesting discussion on #52386 I'm wondering if we could take a different approach for this important issue.

Trying to deal with all the potential keyboard shortcuts conflicts across different operating systems and browsers is almost impossible. There will always be conflicts. Additionally, when other software is running, for example screen readers, some keyboard shortcuts may conflict with the screen reader ones. See for example #11154

Instead of allowing users to customize the entire set of keyboard shortcuts, I'm wondering whether customizing only the modifier would be more effective. Even better, consider to introduce a 'WordPress key' as a customizable modifier for all the WordPress keyboard shortcuts.

Let's try what screen readers do.

Likely, screen readers are the ones who have to deal with keyboard shortcuts the most. Fort this reason, thei use their own modifier keys. Each screen reader has its own main modifier key and it calls it in a different way.

VoiceOver refers to it as the VO key. It's Control + Option, or Caps lock. Screenshot:

Screenshot 2024-01-19 at 12 03 32

NVDA calls it the NVDA key. It's either the Insert key or the Caps lock key.

JAWS calls it the JAWS key. It's either the Insert key or the Caps lock key.

What if we introduce a WordPress key or, in a more WordPress style a WP key which behaves as a modifier? Would that allow to use simpler key combinations and hopefully avoid conflicts?

Cc @joedolson @alexstine @andrewhayward

@TheSimArchitect
Copy link

I think it would be fantastic! Having a settings page where we can customize whatever we want is ideal. I have a Stream Deck, for example, so things like superscript could be assigned to a button and I could use any key combination that doesn't produce conflict without even worrying about its usability, as to me it would be a single button like Bold and Italic. 😁

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). Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback. Needs Dev Ready for, and needs developer efforts [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests