Global styles menu: avoid unnecessary mismatch between visible label and accessible name

[afercia]

Description

See related discussion on #22332

Cc @joedolson @alexstine

For the highest level of accessibility, the visible label of a control should determine the control's accessible name.

Sometimes, with good intent, both Core and Gutenberg use the aria-label attribute to provide more context but by doing so a mismatch between the visible label and the actual accessible name occurs.

While the expanded info in the aria-label may be beneficial for blind screen reader users, it introduces potential barriers for other users. For example:

• Sighted screen reader users will see the visible label but the screen reader will announce the invisible aria-label.
• Speech recognition / Voice control users won't be able to activate the control via a voice command, because of the label / accessible name mismatch, at least with some of the voice control software. See discussion on Add screen reader only text format #22332

The Web Content Accessibility Guidelines success criterium Label in Name states that the accessible name must contain the visible label and that the best practice is to have the text of the visible label at the start of the name.

Unfortunately, that doesn't work with some voice control software, which makes the WCAG criterium arguably useful.

As such, each time there's a mismatch between visible label and actual accessible name, a new accessibility barrier is introduced for some users. This kind of mismatch should be avoided when possible.

I'd like to reinstate a good general principle:

Important

When possible, let the visible label of a control be its accessible name. Do not override or expand with screen reader text or aria-label / aria-labelledby.

A good example of unnecessary mismatch is in the Global Styles root menu. Screenshot:

Where the buttons visible labels are:

• Typography
• Colors
• Shadows
• Layout

However, these buttons do have aria-label attributes that only adds the word 'styles'. As such, their accessible name becomes, respectively:

• Typography styles
• Colors styles
• Shadow styles
• Layout styles

This mismatch prevents users of some voice control software to use a voice command.

In this specific case, the added word 'styles' doesn't add much value. These buttons are already placed in a panel that has a heading 'Styles'. The context appears to be clear enough and the mismatch should be avoided. Keeping things simple is always the best option.

When some meaningful, useful, additional context and information are necessary, a better option would be to place the extra info in the control description rather than unnecessarily altering the accessible name.

Step-by-step reproduction instructions

• Go to Site Editor > Styles
• Observe the root menu in the Styles panel.
• Observe the visible label of the buttons Typography, Colors, Shadows, Layout, mismatches the accessible name provided by the aria-label attributes.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

[afercia]

Same applies to some of the sub-menus, for example the Typography elements:

where, additionally, the Aa should be hidden from assistive technology.

[afercia]

Some of the sub menus items use a HTML title attribute that just repeats the visible text. This is redundant and WordPress has being removing this kind of attributes over the last years, see https://core.trac.wordpress.org/ticket/24766 and all the related tickets and chagesets.

[afercia]

The Typeset button has an aria-label={ __( 'Typeset' ) } that completely mismatches the meaning and visible label:

[afercia]

The Palette button conditionally shows:

• When there are no palette colors, it shows a visible label 'Add colors'.
• Otherwise, it shows a visual representation of the palette colors. This is not OK for accessibility, as the accessible name provided via an aria-label Edit palette is not visually exposed.