Define strategy for keyboard shortcuts

Layout Paragraphs allows moving a layout section or component via keyboard shorctuts:

1. Focus the "move" link in the section or component's floating toolbar using the browser default: click it, or tab/option-tab to it then press enter. The move tooltip is revealed.
2. Use the arrow up/left and down/right keys to move the item.
3. Click return or tab to accept the move, or escape to cancel. The tooltip is hidden.

To keep in mind:
- avoid conflicts with users accessibility technology (https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts)
- about navigating grids, includes examples of common keys (https://www.w3.org/WAI/ARIA/apg/patterns/grid/#keyboardinteraction-setti...)
- navigation matching html-element and visual (eg. no radio-button grids with directional arrows, if non-visually only prev-next)

It looks like Wix doesn't have a full keyboard support, since some shortcuts say fe. "while dragging" https://support.wix.com/en/article/wix-editor-keyboard-shortcuts-in-the-...

This page includes Wordpress shortcuts for Gutenberg https://www.zettahost.com/wordpress-tutorials/gutenberg-keyboard-shortcuts/

For navigation between/within layout element, I'm pretty sure we should use something like "roving tabindex" to have less tabbing and more arrow keys.

Saw a video on Youtube and now I'm sold ;-)

https://www.youtube.com/live/lLrmnFJKFAM?feature=shared

Copy/Cut/Paste

Here it's best to use the usual Ctrl-C, Ctrl-X, Ctrl-V

For duplicating common would be Ctrl-D but here (because of nesting) it is not clear what it should do. Eg. if one is inside a component that has 1 slot and duplicates the component in the single slot, what would happen with duplicate?

While pasting an improved focus highlight is needed in addition to understandable keyboard navigation. Pasting a component could limit navigation to component slots, but to exit the paste mode we need a shortcut to clear clipboard. C for clear, F for Flush and R for reset are not available as shortcuts. A fair option could be Ctrl-Alt-Z since action is an undo of a sort (even if that keyboard is used by some Google apps for accessibility features)

Navigation between components

Default grid navigation is done with arrow keys and for accessibility the area navigated with arrows may be limited.
Tab is used for navigating between components.

With Experience Builder the structure may be wild and deviate from a basic grid a lot. This is due to possibility of complex nesting.

Experience Builder has the layer view that is a well formed hierarchial list. For this keyboard navigation can well use standard patterns moving between components. We should utilise this view as an keyboard usability/accessibility feature and allow accessing component properties from here easily. While testing an older version of XP the layers and the layout view were both highlighted when navigating in the structure. Using layers to navigate components should activate highlighting in the layout area, but in a way that the user is not confused where the keyboard focus actually is (I'd maybe use some shading overlay with active component with normal brightness, but did not look into current best practices).

For navigating a complex layoutdirectly in the layout view there are tradeoffs required. It might not be a straight grid. Following standards might not reult in fulfilling user expectations. I have a few example cases where I think user expect different focus change to that which structure would provide. See the attached PDF, ask for more detail.

To add to the discussion. There might be an approach to solve the fundamental problem of how to handle hotkeys, aka keyboard shortcuts in Drupal. Instead of solving that problem just in the context of Experience Builder, why not solve things consistently for core and contrib, in general - that approach would be more sustainable, beneficial, and future proof. Recent discussions in the accessibility track for Drupal CMS lead to ✨ Add an API for hotkeys to Drupal core Active . That proposal would provide a solid foundation for hotkey management in core and contrib, which is also the reason why the proposed API probably would not work as a contrib module. People new to Drupal could potentially be unaware that they have to install the module, and it would be rather challenging to establish a consistent, well-adopted pattern for the entire contrib space, plus it would be pretty unusual for core to integrate with a module in contrib.
The other option to mention might help to improve how keyboard users are able to navigate more easily on pages in the Drupal front and backend. https://www.drupal.org/project/skipto → integrates https://skipto-landmarks-headings.github.io/page-script-5/ into Drupal. It also exposes the page’s landmark regions and headings to sighted users by making them keyboard accessible (WCAG2.2 SC2.4.1). The SkipTo module is currently a work in progress, with no stable release yet. In interplay with well-thought-out and structured landmark regions, keyboard users would be able to navigate more flawlessly between the main regions of complex pages such as Experience Builder.
Those two suggestions might provide a solid foundation for keyboard usage and could be expanded and interwoven with approaches like the roving tabindex ( #7 → ) and others, suggested on this issue. Another good resource to mention for inspiration is: https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/