Improve accessibility of drop–downs

[oleq]

1. The screen reader should properly announce that the button has a popup, (Buttons with dropdown should feature proper semantic markup #12258)
   1. The screen reader should explain the way to open it, (this will also be handled by Buttons with dropdown should feature proper semantic markup #12258)
2. The screen reader focus should move properly to the drop–down and follow the navigation across its content (The placement of focus after opening dropdowns #11838)
3. Exiting the drop–down should also be explained by the text reader. (not needed as discussed later)

[oleq]

1. Our dropdowns have no aria-expanded but should have (see an example from w3c https://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-collapsible.html)
   • The only places that have that attribute are CollapsibleView (list properties: start index, reversed section) and SplitButtonView (a button for dropdowns with an “extra arrow”).

[wimleers]

AFAICT this overlaps with #11568, #11041, #10368, #3184, #5146, #2000, #3215, #3185, #3176 and #11838.

What seems different about this ticket is that it seems to stress the screen reader aspect.

So I propose to retitle/rescope this to Improve screenreader support of dropdowns, and to do this after it's been made keyboard-accessible. Doing that first is necessary anyway, and may solve some of the problems outlined here 😊

[Comandeer]

The screen reader should properly announce that the button has a popup,

It can be done by adding the [aria-haspopup] and [aria-expanded] attributes to buttons triggering dropdowns. Depending on what the dropdown is, the [aria-haspopup] attribute can take different values instead of generic true (e.g. menu if the dropdown is some kind of a menu). We also need to ensure that the dropdown itself has an appropriate role (e.g. [role=menu] in case of menu dropdown). ARIA Practices contains a decent menu button sample.

The screen reader should explain the way to open it,

Using the combination of [aria-haspopup] and [aria-expanded] attributes should be enough for that.

The screen reader focus should move properly to the drop–down and follow the navigation across its content,

As @wimleers pointed out, keyboard accessibility will be covered in other issues and should resolve the issue with screen reader focus.

Exiting the drop–down should also be explained by the text reader.

IMO it does not need to be if exiting the dropdown can be done by a standard means (e.g. pressing Esc) and the focus is moved back to the button that opened the dropdown. If really needed, this behavior can be described in the accessibility help dialog (#1014).

[wimleers]

FYI: tracking this at https://www.drupal.org/project/drupal/issues/3283804 😊

IMO it does not need to be if exiting the dropdown can be done by a standard means

Agreed: having a screen reader speak too much is not a great experience either!

[mlewand]

Closing this umbrella issue as the only one open part is #12258.