feat: make flyouts and workspace labels properly accessible

[maribethb]

The basics

• I validated my changes

The details

Resolves

Fixes #9495 and various other smaller things mentioned in the design doc but not filed as issues

Proposed Changes

• Uses role of presentation rather than generic in many places related to the flyout and workspaces.
• Updated the svg dom utils to do the above for svg and g elements.
• Updated the flyout aria context to use the roles and labels agreed upon by the design doc (mostly)
  • only non-autoclosing flyouts are regions
  • flyouts for category toolboxes are labelled with the category name + "blocks"
  • blocks in the flyout get their roles updated to listitem by the flyout inflater. this was the best place to do this as you don't always have the information you need when the block's normal label is updated
  • hides non-top-level blocks from the aria tree in the flyout since they are not focusable. this keeps the list count correct.
  • labels and buttons are inflated with the correct role and labels
  • added instructions in the flyout inflater interface that states all inflated items must be marked up correctly
  • note this work does NOT include updating labels for blocks themselves to read differently when they're in a flyout
• Updated the workspace aria labels to match agreed-upon (or mostly agreed-upon) language and also include the count of block stacks in the workspace

Reason for Changes

• The role of "generic" is not meant to be used by web authors and we should refrain from using it. The role of "presentation" should be used for most other instances of this, but there are special things to consider for focusable items. Focusable elements probably shouldn't get the role of generic either. But I didn't fix all usages of this, only the ones relevant to flyout/workspace
• Flyouts are lists, and it's tricky to get the list/listitem roles correct so that the numbered contents are correct
• Adds more context to the workspace and flyouts for screenreader users
• Trying to avoid words that don't mean anything to users such as "flyout" and "mutator" -- instead using vocabulary we've either agreed on or my best suggestion for places where we haven't agreed on anything formally

Test Coverage

Manually tested in Voiceover:

• simple toolbox (flyout toolbox) case
• basic category toolbox
• test blocks, specifically the Drag category is useful as it has several labels and blocks that have multiple blocks connected together (both shadow and non-shadow) so you can ensure the list count is correct (it should count the number of focusable things, i.e. stacks of blocks, not every block in the flyout)
• flyout buttons and labels
• mutator workspaces and flyouts
• labels are correct for workspaces and flyouts (not blocks)

I think this should be unit tested, but before writing unit tests, we should validate this in other screenreaders. therefore I propose submitting this and testing as part of beta.2 before committing to writing unit tests, given how much contention there was previously about what the correct markup should be.

Documentation

Additional Information

Related work remaining:

• update labels of blocks so they read correctly in the flyout (particularly for stacks of connected blocks where you can only focus the first one)
• implement heading shortcuts to jump to heading or provide hints if you try to press enter on a heading

[gonfunko]

Does this include non-block flyout items? If so it might be better to say "items" or the like than "blocks". And if not, it might be good to offer a count of all items?

[maribethb]

This is the label for the flyout generally, so like "Logic blocks"

yeah, it might contain things like buttons and labels but that's not really the main point of the flyout so I don't think we need to include other things. "Logic blocks" is a lot more clear than "Logic items" imo

We don't need to include the count here because it's a list, so the screenreader will already include the item count in the label (and it will include all focusable things, not just blocks, in that count)

[gonfunko]

Should we include workspace comments?

[maribethb]

No, microbit said just block stacks. You can press i on the workspace to hear more details including how many comments there are