Navigating between toolbox, flyout and workspace

[cpcallen]

At the moment, the t key moves between the main workspace and the flyout, but feedback from testers includes:

Also, could the toolbox be accessible via tab?

This raises the question of tab order within Blockly:

• (non-Blockly) > toolbox > flyout > main workspace > (non-Blockly), or
• (non-Blockly) > main workspace > toolbox > flyout > (non-Blockly), or
• should it depend on where the toolbox / flyout are (top / bottom / left / right)?

[microbit-lucy]

Can you confirm what you mean by the flyout please? Do you mean the section currently on the left including Run code and the shortcut list?

[rachel-fenichel]

The flyout is the section on the left that contains blocks that can be dragged out. You usually open it by clicking on the name of a category in the toolbox. This visual glossary may help us with standardized terminology.

[kmcnaught]

I would expect tab between these areas to follow standard conventions of top->bottom, left->right. I am imagining that the blockly parts are always going to be grouped in the visual order and tab order, is this likely to be the case, or could someone wrapping blockly inject their own parts in between the toolbox and main workspace, for example?

[rachel-fenichel]

It's fair to assume that Blockly parts will always be grouped. I like following the standard conventions as you have suggested.

I think a few components should act as navigation landmarks:

• Toolbox (or flyout if there is no category toolbox)
• Block workspace (where the active blocks are)
• Zoom controls, if present
• Trashcan, if present

Blockly visual glossary in case these terms are unclear.

An open question: should those only act as landmarks when already within the context of the block editor, or should they always be active? That is, should a user be able to jump to the toolbox from anywhere on the page, or should they have to jump to the block editor and then jump to the workspace?

[kmcnaught]

Good question. I'm not sure. How much "non block editor" webpage do you expect to be present? I'm picturing mainly third parties wrapping Blockly (a la MakeCode or Scratch), without substantial extra content on the page - are there existing deployments where the Blockly workspace is embedded as a smaller component on a page with a lot more content?

As per the visual glossary I'm not sure how we are describing the block editor itself - is it a child of the Workspace ? In which case I think the question would be whether you have to navigate to the workspace (which might put default focus on one of the children, such as the block editor) before you can navigate to a specific child? When I look at the micro:bit MakeCode editor for example, I (visually) interpret the simulator / toolbox / block editor as on the same level of the hierarchy, and I don't parse a semantic "parent". So I think I'd expect a shortcut to the toolbox to work regardless of my current focus. It's possible the trash can and the zoom controls would be reasonably interpreted as sub components of the block editor.

Re navigation, I think there are 2 approaches that need not be exactly equivalent
1 - keyboard shortcuts to jump to certain areas
2 - aria regions to add (potentially more) navigation for screen reader users

I assume we are mainly talking about (1) here, but we should bear in mind that (2) might be a different way to give certain shortcuts if more appropriate to a screen reader user vs a sighted keyboard user.

One thought - I'm not immediately convinced whether zoom controls are an essential landmark - I'm open to being persuaded, but they seem less essential than the other parts you've listed. It's important that zoom controls are keyboard accessible of course, but if we have keyboard shortcuts for zooming actions, then maybe you don't necessarily need to be able to jump straight to the controls?

[rachel-fenichel]

I consider both Scratch and MakeCode to have substantial extra content outside of Blockly:

• Top nav bar
• Footer
• Runtime environment, which is interactive
• (Scratch): sprite selector, sound editor, etc
• (MakeCode and sometimes Scratch): tutorial elements

"Block editor"--yes, that's missing from the visual glossary (oops). As a Blockly person I think of the block editor and the toolbox/flyout as parallel components that are both children of the workspace. But if it visually parses the other way for you and that means we can remove a level of hierarchy, I'm down to try treating them as parallel with no Blockly parent.

Re zoom controls: Good point. Let's assume that they aren't essential landmarks at this point.

[rachel-fenichel]

Summary of discussions between micro:bit and Blockly on November 12-13, 2024:
(Please disagree if you thought we agreed on a different solution)

Any subset of { block editor, toolbox, flyout } that are always visible will be part of the tab order.

In Scratch, with both a toolbox and an always-open flyout, all three will be in the tab order:

In MakeCode, with a toolbox and a collapsible flyout, only the toolbox and block editor will be in the tab order. The flyout is entered from the toolbox.

In the current test page, which has an always-open flyout and no toolbox categories, the flyout and block editor will be in the tab order.

We will probably make the tab order match the layout on the page, taking into account RTL and the positioning of the toolbox/flyout at start or end of the workspace. For a first pass, the order is toolbox, flyout, block editor.

Zoom controls and scrollbars can be reached from inside the block editor if they are positioned inside the block editor.