Audit and improve ToolsPanel's a11y

[apeatling]

(semantics, focus management, announcing changes to screen reader users)

[ciampo]

@afercia @joedolson @WordPress/gutenberg-components @aaronrobertshaw in the context of looking to stabilize the component, is there any feedback that you'd like to share?

[afercia]

Besides the genereal considerations i reported on #67954, from an a11y perspective I would like to see a few points to be considered:

1. This component is an ARIA menu. As such, I would like to see the component enforce via code, or at the very least have some linting, to only allow the children expected in an ARIA menu. See similar issue for DropdownMenu Enforce DropdownMenu to follow the ARIA menu pattern or add linting to make sure it does #67795
2. It should not use an ellipsis icon. This icon has inherent problems as it's little visible for low vision users. See Make the ellipsis button more visible #61909. More importantly, the concept of the ellipsis icon is 'more' but the editor is extending this icon usage to many other concepts and I'm not sure that's ideal. This component is about toggling the visibility of settings. It should be identified with an icon related to settings.
3. The labeling of the menuitems when the 'reset' action is available should be improved. The visible text mismatches the actual aria label, as the order of the words is different. E.g.

• Visible text: Block spacing RESET
• Aria label: Reset Block spacing

4. The strings for the speak message __( '%s reset to default' ), __( '%s hidden and reset to default' ), __( '%s is now visible' ) don't follow the WordPress best practices for l10n. In gendered languages, the name of a setting may be masculine or feminine and the adjectives like 'hidden' and 'reset' can't be translated correctly when the gender is unknown.

Screenshot of mismatching visible text and accessible name:

[joedolson]

I'll second @afercia's comments. In regards to point 3, referring to the usage of aria-label, I'd go a bit further and say that we really need some kind of control over when aria-label is used; this is a completely unnecessary usage of of the attribute, as the visible text of these buttons is completely adequate to convey what they do. All aria-label does in this case is introduce the potential for a WCAG 2.5.3 violation, and introduce the probability of best practice problems with mismatched text, as cited by Andrea above.

In my opinion, if a control has a visible text label, it should not have an aria-label unless there is a very strong reason that this control needs additional explanation.

[afercia]

unless there is a very strong reason that this control needs additional explanation

To further clarify: any 'explanation' as in: a description, should not be used for labeling. A description should be separated and be part of the accessible description. Instead, a label is determines the accessible name, which is what the control is about. It's the what the control does. In some cases, the what can be expanded a little but longer descriptions or explanations should go in a description.