Finalize prototype dynamic ARIA states for moving and inserting blocks

[BenHenning]

Check for duplicates

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

Problem

The screen reader experimental branch doesn't currently do a great job of representing block movement and insertion which is likely to lead to confusion in upcoming user studies.

Request

More discussion is needed on what the ideal state should be here, but at minimum:

• It should be clear to the user whether they are inserting or moving a block.
• It should be clear to the user which block they are inserting or moving.
• It should be clear to the user where the block is being added in the workspace.

Alternatives considered

No response

Additional context

No response

[BenHenning]

@rachel-fenichel, @maribethb, and @gonfunko: I wasn't around for discussions last week when I think you were all discussing move mode behaviors. Is there anything that needs to be updated in the requested behaviors before this begins being worked on per that discussion?

[microbit-robert]

We've made some quick changes to the move mode announcements to better facilitate user testing, so I'll share the approach we've taken so far. In general, we've lost the use of "child of" in favour of what we believe is more user friendly language. When moving references a block (rather than an input), we use a minimal readout of the block which excludes its status, inputs and child count to keep the readout short. When moving to an input in a block, we do the same, but keep the number of inputs in the output as it's likely useful to know that you might have more than one input to choose from.

When moving to the first position inside a c-shaped block:

When moving after a statement block:

When moving before a statement block:

When moving to an input, we use the lowercased input name to refer to the input, not its current value. To support MakeCode, we've actually added a public label field to Input and given it a setLabel method as the input name isn't always that good - we use the input name as a fallback:

When inserting or putting a block in move mode when there are no constrained positions (currently reads out nothing) we've opted for a simple announcement:

Thoughts and feedback very welcome.

[BenHenning]

Thanks @microbit-robert! I'm sure others will have their own thoughts here, but I really like the direction this is heading and I think is largely compatible with what the team was discussion last week. We envision using RaspberryPiFoundation/blockly-keyboard-experimentation#764 to provide additional context while in move mode to provide extra positional context if it's needed but otherwise keep readouts brief so that we don't overwhelm in move mode. There's an obvious question about how much to share, but that's still an open question.

#9450 is relevant for the input label bit, I think. I'm hoping having clear field labels is sufficient for all input cases, but if it isn't then we'll need to consider something additional to put things in a good place.

It's also worth mentioning that the team discussed unconstrained movement last week. I like the 'Moving to workspace' as the default. We've also discussed for unconstrained movement to just indicate the direction of travel (e.g. up/down/left/right) and to drop actual coordinates since they're likely to add confusion (until we get evidence from users that coordinates are beneficial).

[rachel-fenichel]

I also like the changes above and support pulling them into blockly.

The implication here is that the user needs a brief reminder of what block they are in/above/below while moving, rather than a full read-out. I think that's absolutely right and matches how we talk about where to move code (above the set variable block, below the draw block, etc). Additional information can be requested, but is not provided by default.

[maribethb]

Since microbit has something working for their user testing, we're moving the priority on this lower to focus on things that they still need. We do still need to pull their work or something else into core blockly at some point though.