[Screen reader] consider excluding instances of FieldImage from block aria labels

[microbit-robert]

Check for duplicates

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

Description

While integrating the latest screen reader work into MakeCode, we found that the fluent block readout included the aria labels from instances of FieldImage in the block. In the MakeCode case, these are buttons to add / remove else and else if clauses. While we want these aria labels when navigating to the mutator buttons themselves, it was confusing and overloading to have these labels included in the overall block output.

Examples below (these use a tweaked block readout, but the impact of the FieldImage labels is evident regardless).

With FieldImage labels (the more clauses you have, the worse it gets):

Without FieldImage labels:

We don't know how other consumers of Blockly use FieldImage, so excluding by default might not be appropriate.

Reproduction steps

Priority

No response

Stack trace

Screenshots

No response

Browsers

No response

[rachel-fenichel]

Would it work to have the alt text for the image read out when doing the block overview, and normal aria label/info when navigating?

[microbit-robert]

Would it work to have the alt text for the image read out when doing the block overview, and normal aria label/info when navigating?

Potentially, then people can configure as they need. In our case for the if/else above we could put an aria label into the config and leave the alt text empty.

[BenHenning]

Would it work to have the alt text for the image read out when doing the block overview, and normal aria label/info when navigating?

FWIW the distinction here confuses me. Right now there are two things that can be used to produce a FieldImage's ARIA label:

• Its image's alt text.
• Any custom ARIA name defined for that field (per the corresponding block definition).

If both are present then they produce a comma-separated label, otherwise alt text is used exclusively.

As of #9446 this is only used by clickable FieldImages (though that distinction is moot since users can't navigate to non-clickable ones, anyway, so removing them from the node tree doesn't meaningfully change anything in this discussion).

Fluent block labeling uses a field's text if present and, if not, falls back to its value when representing the field. The text here is the image's alt text again so, as far as I can tell, the block readout will always use the alt text and, in most cases, so will navigation when directly focusing the image field.

I'm wondering if we instead need a more explicit way for a field to provide its 'summary' ARIA context (which could default to text/value like it's defined today) but can be overridden as needed. More broadly, I'm not sure it makes sense to include field images in the block's top-level readout by default. I can see arguments for and against (for: very important context may represented in images, against: alt text can be a poor proxy for an image's ARIA context without writing it with that specifically in mind).