screenreader / keyboard navigation of blocks containing multiple statement inputs

[maribethb]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

Blocks with multiple statement inputs, like if/else if/else blocks (I may call them if blocks below) currently have some problems:

• The screenreader reads the entire block at once when you focus on it, which is too much information
• The plus/minus button mutator model that makecode uses doesn't work cleanly with navigation. You have to focus on the block and use the right arrow key to hit the buttons, instead of focusing on them in the vertical order they appear in.
• You can't easily access the minus button on the "else" branch, or any button that appears in a branch that does not have another value input.

Solutions:

• The label for the block should only include the text of the first branch, plus the number of branches. e.g. "if, has 3 branches"
• You can already hear the output for each individual branch by focusing on the connections for those branches, so no changes needed there.
• Fix the navigation so that plus/minus buttons are visited in a sane order (need to check whether makecode uses fields or icons for these)
• The "shift+i" shortcut when you're on a child block of an if block, should only read information for the current branch. If you want to hear the full text of the if block you'll have to focus on the if block as a whole and press i.

Reproduction steps

Priority

High priority, one of the biggest remaining problems from user testing

Stack trace

Screenshots

No response

Browsers

No response

[mmc-jorene]

From the recent testing, we directed users to Makecode's page and they found Makecode’s implementation of the if/else block intuitive. The branch readouts were clear and users navigated through them easily.

However, one user did experience confusion with having to use the right arrow to get to the minus buttons on the else if branches compared to having the focus land on the minus button right away on the else branch.

[microbit-robert]

However, one user did experience confusion with having to use the right arrow to get to the minus buttons on the else if branches compared to having the focus land on the minus button right away on the else branch.

We also noted the same confusion. It's a consistent approach, focus the first thing in the 'row', but the fact the first thing in the else if branch is a boolean and the first thing in the else branch is a button is not helpful for us.

It does raise the question of what you focus in a 'normal' else branch which has no focusable elements in the 'row'. Just move inside the branch? That's more inconsistent, but without introducing real row navigation, I don't see what else can be done.

[BenHenning]

Also important to consider (tangentially related): #9496 (comment) while we implement a fix for this.

[mikeharv]

Closing as I believe that #9868 resolves the last of the issues stated. Navigation improvements are already present in v13 as well as the shift+i shortcut.