Mouse and keyboard navigation interoperation

[BeksOmega]

We think that we should probably have clicking on a block with the mouse (or via a touch screen) should move the focus of the keyboard navigation. Does this make sense? Or should clicking control selection but not focus? Or should clicking disable keyboard navigation?

Ref, the ARIA discussion of focus vs selection related to this: https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/#kbd_focus_vs_selection

[rachel-fenichel]

Summary of discussions between micro:bit and Blockly on November 12-13, 2024:

To facilitate interoperation, clicking should move the focus to the clicked location, and also move selection if it is possible to select the clicked element.

[kmcnaught]

This is an initial attempt to outline some minimal core UX flows we expect for mouse+keyboard interoperability.

1. Click workspace to get started in code editor

• Load page, so focus has not moved from initial location
• Click on an empty part of the workspace
• Expected behaviour: The workspace is focused, exactly as if you used tab to get there. Cursor location is the same as if you used tab to get there.

Similar UX flows should apply to selecting the toolbox, if/when this is a standalone tab stop.

Note that this could be a common UX flow for someone who is using assistive tech to control the computer, and they see that "the arrow keys aren't working". It's not unusual to require focus on the element you are trying to control (e.g. a game window) but it is nearly always fixed by clicking on the element to force focus. If this is implemented well, we shouldn't require people to know how to use tab navigation, if they are able to use a mouse for initial focus (e.g. can use an mouse but fine control is hard.)

2. Click a block to get started in code editor

• Load page, so focus has not moved from initial location
• Click on a block in the workspace
• Expected behaviour: The workspace is focused, and the block is selected exactly as if you used keyboard navigation (tab then arrows) to get there. Arrow keys navigate through the workspace from this initial cursor location.

This might be a useful UX flow for a user with a visual impairment who is using a mouse (large high contrast cursor, with zoom) and wants to use mouse as a primary control method, but sometimes misclicks and wants to adjust selection with the arrows. They might be able to select a block okay, but struggle with selecting a field in the block

3. Changing cursor location

• Navigate to code editor using keyboard controls, until a block is selected
• Click on another block elsewhere
• Expected behaviour: The selected block is highlighted, and the cursor location moves here.

This might also be relevant to the persona in (2), who uses mouse or touch controls to move to a different part of the code, but uses keyboard to modify fields and delete blocks.

4. Multiline selection

• Click on a block
• Hold down Shift
• Click on a block a few blocks down in the same stack
• Expected behaviour: A contiguous selection of blocks is highlighted, and you can e.g. delete or cut/copy them.