Blockly v13 Beta Accessibility Questions

[Catherine Kettner]

Hi Blockly Team!

Just wanted to give kudos to your team on this Blockly beta v13 update. It's impressive and our team was so happy to pull it in. 😊 We'll also be at the summit in June, so if any of the items below are better discussed there, let me know!                                   

A few questions on accessibility and future direction:

1. First-letter/Type-ahead navigation. The toolbox uses role='tree', and the APG Tree View pattern lists type-ahead as expected keyboard behavior for that role, is implementing it on the roadmap? Not a WCAG requirement, but since the toolbox can be so long, it could be much faster for users to use the first letter navigation, so wanted to check and see!
2. Single-letter shortcuts. I can see how single-character keys could provide benefits, but they pose a dilemma for us. We provide text-based coding alongside block-based coding and want the keyboard controls between the two to feel cohesive - single characters to jump to the toolbox/editor don't fit that model. We also support blocks that embed a Monaco editor instance, which breaks the ability to use "t" to move to the toolbox while focus is inside the block. We know we can re-register shortcuts on our end; the real question is whether single-key shortcuts are the long-term direction, or something we should expect to evolve. That'll help us decide whether to invest in remapping or wait. 
3. Reflow (WCAG 1.4.10). We're interested in the Blockly team's interpretation of 1.4.10. The workspace's 2D scrolling makes it hard to meet the criterion without invoking the "content requiring two-dimensional layout" exception, and we're trying to figure out the right path. One idea: have horizontal scroll off by default, and only enabled if a user explicitly drags blocks past the workspace edge or blocks can't fit in a minimum-width workspace. Note: This one is more of a discussion-starter, we'd love to hear how you're thinking about it.

Thank you all!

[Rachel Fenichel]

Thanks for the questions! Long answer ahead and I'm excited to discuss this topic further.

First-letter/type-ahead navigation: We strongly recommend that you have a search mechanism or category in your toolbox, particularly if you have a lot of different categories or blocks. There should definitely be some mechanism for quickly navigating to a specific block in the toolbox. (Personally, I think search is generally a better pattern than typeahead here.)

The App Inventor folks may also have thoughts.

When you ask about type-ahead are you thinking about jumping between categories or within blocks in the flyout?

Single-letter shortcuts: This one has been controversial!

> We provide text-based coding alongside block-based coding and want the keyboard controls between the two to feel cohesive - single characters to jump to the toolbox/editor don't fit that model.

Can I get a screenshot or gif to see what you mean?

> We also support blocks that embed a Monaco editor instance, which breaks the ability to use "t" to move to the toolbox while focus is inside the block.

This should be okay because the user has to commit their change to the text editor before switching back to moving around the workspace. It should be no different from a normal text input field.

>  the real question is whether single-key shortcuts are the long-term direction, or something we should expect to evolve

Single-letter shortcuts are the long-term direction and I strongly encourage you to use the default shortcuts if you are able.

The reasons:

• Cross-platform compatibility: It's incredibly hard to come up with a set of keyboard shortcuts that work across OSes (Mac, Windows, Chromebook) and browsers (Chrome, Edge, Safari, Firefox). Maintaining a matrix of shortcuts for different OS+browser combinations is its own headache from both a technical standpoint and a user education standpoint.
• Manual dexterity: Typing with multi-key shortcuts requires extra manual dexterity, particularly if a child is in the hunt-and-peck stage of typing.
• Consistency across block-based programming environments: If you stick with the default shortcuts your users will be able to transfer knowledge in and out from using other environments.

Blockly's shortcuts meet the WCAG 2.1.4 requirements because they are only active while the user interface component is focused. But I'm also looking at whether we want to have an option to turn off all single-key shortcuts. Applications may want to let users remap shortcuts, but that probably has to happen outside of the scope of Blockly to make it possible to save to a user's profile and not conflict with application-level shortcuts.

Reflow (WCAG 1.4.10): I invoke the exception for "content requiring two-dimensional layout" at the Blockly level but support experimentation at the application level.

Users definitely use the two-dimensional layout to represent code in ways that are relevant to them, such as in this Scratch project where the scripts are positioned to be visible at the same time. Forced horizontal or forced vertical layout would make it harder to read the code and require the user to hold more state in their mind when reading or editing. It also means the drag distance required for edits goes up a lot.

However, applications can certainly choose to force vertical stacking (e.g. by automatically reflowing the blocks after every drag). That may be appropriate where the application wants to invoke text-coding norms. An intermediate approach is to point users to the "clean up" or "format" keyboard shortcut and reference it regularly in tutorials. (Personally, I hate formatters that change my code out from underneath me as I type.)

Cheers,

Rachel

[Catherine Kettner]

> We provide text-based coding alongside block-based coding and want the keyboard controls between the two to feel cohesive - single characters to jump to the toolbox/editor don't fit that model.

Can I get a screenshot or gif to see what you mean?

The VEXcode application supports python text editor coding that includes an editor and a toolbox list of Python commands. Since users have to code in the editor, we cant support single key shortcuts to hop between toolbox and editor and we want the experience between block coding and python text editor coding to be the same. (Image attached showing text editor workspace, and the python toolbox list of commands that are keyboard navigable and draggable into the workspace)

When you ask about type-ahead are you thinking about jumping between categories or within blocks in the flyout?

Since we use a continuous toolbox with no collapsible flyout categories, type ahead would ideally jump between headers in the toolbox and also the blocks. We will consider the general "toolbox search option" as well. 

Thanks for the extra context on Reflow!