Moving keyboard focus between the Blockly workspace and the runtime environment for generated code

[rachel-fenichel]

Most blockly-based applications have a code workspace and a runtime.

Many of them expect interaction with the runtime: micro:bit has a simulator that can be clicked and tilted, code.org has clicking in flappy bird, and so on.

That means we need to have a standard way to move between the workspace and the runtime, since we don't want keypresses aimed at (e.g.) playing a game in the runtime to actually move blocks around in the blockly workspace.

[cpcallen]

If navigating via up/down/left/right, I think the intutive thing would be that an attempt to navigate beyond the boundary of the current contents of the workspace would move focus to other parts of the app (including the workspace)—but for this to feel seamless it would probably necessitate the rest of the app implementing a very similar navigation strategy, which might be exceedingly tricky in many cases.

Treating a workspace as a single focusable element and allowing tab and shift-tab to enter/exit the workspace in the normal way might be the most generally compatible approach. (Flyout workspaces could be separate entities and so be accessed via tab / shift-tab as well, or they could be treated as sub-parts of the main workspace and accessed via a separate key binding like T-for-toolbox.)

[cpcallen]

Somewhat orthogonally to the question about how focus is moved: I think we should ensure that the cursor is only shown in the workspace when the workspace has focus, so that one's current location is always clear when navigating between the page (browser current location indicator) and workspace (cursor indicator).

Suggestion in response to this comment from external testers:

People who are used to using keyboard navigation, expect to use TAB to get around and instinctively use that as the first key on arrival. This seems to cause a lot of initial confusion – I’ve had to tell them they are ‘already in’ the workspace and can use the arrows immediately. Even then they instinctively use tab to orient (which leads to confusion since you end up with 2 focuses). Is there a way to make these 2 things work better together?

[kmcnaught]

I agree that arrow navigation should be context dependent - it should only work if you are "in" the workspace / toolbox / flyout. I think it would be quite reasonable for the different workspaces to be separate focusable elements, which you tab between to enter/exit, as @cpcallen suggests.

I think this approach is independent of whether tab is used at all inside workspaces as per #63.

[kmcnaught]

A follow up from this one - what are the current arguments for requiring an "Enter" action on the workspace? If we aren't using Tab within the code editor (or at least - not loads of tab stops), what's stopping us from just requiring focus to use keyboard shortcuts on the editor, rather than focus + "some action to enter" ? And then you just Tab away from it if you need to go somewhere else, and the shortcuts are inactivated.

I've been looking around at implementations of embedded rich text editors, and for those that care enough about accessibility to have published an accessibility statement / guidance page, it seems a common convention to just have keyboard shortcuts start working when the element is focused, but you don't have to press Enter to enter, and Tab still moves you on to the next element.

e.g. CK Editor and Tiny MCE (the editor on this page is live). TinyMCE has a good page on screenreader access and shortcuts. Fwiw that also demonstrates the use of toolbars which use Tab internally but require a shortcut key to jump to, i.e. they don't pollute the main tab order.

(@microbit-lucy for visibility)

[rachel-fenichel]

@BenHenning to discuss.

[BenHenning]

The first idea was to create a strongly enforced boundary of input between Blockly nav and regular page nav (and using enter/escape as keys to explicitly enter/exit the two different modes). I think this gets confusing when enter needs to be paired with Blockly being focused.

There's no technical requirement why enter and escape need to be used, and we could definitely see how just tab focus works with it. At the moment, my concern would be whether tab navigation is ever needed within the Blockly workspace since then we would have an ambiguity situation in trying to understand which tab the user intends to use. If we ensure tab is never used for Blockly elements, then we can avoid the ambiguity.

I think this specific scenario (tab meaning something different within Blockly vs. the broader page) is what I'm most concerned with. Blockly doesn't exactly match the normal modality of an element being highlighted since it's an entire page of elements with their own interaction and navigation rules.

I do want to note one thing: as I've continued exploring the read-out side of things, it seems possible that we may end up being required to include readable elements in the tab index. I'm not yet sure how much we can override navigation order with tab for elements in the tab index (@rachel-fenichel had some ideas on this that I still need to process), but one possible outcome here is that we may be required to support tab navigation within the workspace.