[META] 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.