Introduce better field labeling and accessibility for screen readers

[BenHenning]

Check for duplicates

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

Problem

Screen reader experimentation (RaspberryPiFoundation/blockly-keyboard-experimentation#673) currently has somewhat insufficient labeling and context support for fields.

Specifically, block fields may lack type context (e.g. proper ARIA setup for drop-downs), or may not have a sufficiently clear described context for custom fields (e.g. colour picker).

Request

Field accessibility largely comes down to three things:

1. Supporting a descriptive label for what the field actually represents along with its value.
2. Providing additional context for how the field works semantically (and provide some hint for how its editor will work).
3. Ensuring that field editors are themselves accessible.

(1) can be solved by introducing an expectation for a new getter for Field that can dynamically determine a good fitting label for the field. This getter can be provided in custom fields without an override, and is thus fine to introduce without custom versions or complicated NPM linking in plugins (since the getter will simply go unused outside of the screen reader experimentation work). Some specific considerations here:

• When does the field need to recompute its label and possibly update its properties? Some invariants/assumptions need to be established in the getter's or class's contract.
• Custom getters in plugins should be tracked so that they can be removed or changed if the long-term solution doesn't end up using them in the same way.
• How should the getter be defaulted? This should largely be on a class-by-class basis, but the specific field value may need to be considered as well.

(2) needs to be solved by introducing correct ARIA roles and, in some cases, elements on a field-by-field basis. #8205 has additional details for implementing ARIA for different fields. This is tracked by the following issues (may not be comprehensive):

• ARIA for checkbox fields #8206
• ARIA for dropdown fields #8210
• ARIA for image fields #8255
• ARIA for text input fields #8211
• ARIA for label fields #8254
• ARIA for number input fields #8212
• ARIA for variable fields #8213

(3) needs to be done, at minimum, for any external plugins that the keyboard navigation plugin playground uses, plus for all built in fields. The latter are covered by the issues mentioned in (2), and the former are covered as follows:

• To be done in a follow-up issue as discovered.

Alternatives considered

One alternative considered was introducing a utility that can determine a label based on the specific class, though this is a dependency inversion and is largely tricky to manage (even in an experiment) vs. using a more inheritance-based approach (which in this case is a bit easier to work with).

Additional context

This solution was largely determined in a team discussion this week with contributions from essentially the whole team.