Regression: fix the usage of aria-pressed vs. aria-expanded / aria-haspopup

[afercia]

Describe the bug https://github.com/WordPress/gutenberg/pull/17748 and https://github.com/WordPress/gutenberg/pull/20951 introduced many changes to to various buttons in the UI, including the main inserter button. In some cases, these buttons now use the aria-pressed attribute inappropriately and miss important ARIA attributes that were previously used. In other cases, aria-pressed is used in combination with aria-expanded, which is inappropriate as well.

To reproduce Steps to reproduce the behavior:

1. activate latest Gutenberg plugin (I tested with 7.9.1) 2.see the main "Add block" button at the top left corner of the editor
2. see the button now uses these attributes: aria-pressed="false" aria-label="Add block"
3. deactivate the plugin, see the button on WP 5.4 uses these attributes: aria-haspopup="true" aria-expanded="false" aria-label="Add block"
4. This button was previously rendered by the <Inserter> component, which used the appropriate aria-* attributes
5. It now uses a <Button> component with an isPressed prop. It's also inconsistent with other "inserter" buttons in the UI, which still use the correct attributes.

Also:

1. See the Settings button at the top right
2. See it uses these attributes: aria-pressed="false" aria-expanded="false" (or true depending on the Settings sidebar state)
3. Note this is already released in WP 5.2 so there's no need to activate the plugin.

Notes:

• There are probably more cases, I didn't test everything, e.g.: Pinned plugins button
• Not sure why the isPressed prop is sometimes passed directly to the SVG icons. I guess this is used for the mobile app?

Expected behavior

• Buttons that open "popups and the like" need only an aria-expanded attribute to indicate the controlled element expanded state. In this case, the usage of aria-pressed is wrong and also noisy for screen reader users.
• If the opening of the controlled element requires manual activation, as in most of the cases in Gutenberg, the button needs also an aria-haspopup attribute.
• Instead, toggle buttons are of a different nature and need only an aria-pressed attribute.

TL:DR The aria-pressed attribute identifies the button as a toggle button. A toggle buttons is a special semantic-type of button, with its expected interaction. It's a two-state button and its state persists together with the result of the associated action until users toggle the button again.

Thus, aria-pressed must not be used to indicate a "selected" or "active" state. It must be exclusively used to identify the button as a "toggle" button.

References: https://www.w3.org/TR/wai-aria-1.1/#aria-pressed

Indicates the current "pressed" state of toggle buttons. See related aria-checked and aria-selected. Toggle buttons require a full press-and-release cycle to change their value.

https://www.w3.org/TR/wai-aria-1.1/#button

An input that allows for user-triggered actions when clicked or pressed. See related link. Buttons support the optional attribute aria-pressed. Buttons with a non-empty aria-pressed attribute are toggle buttons. When aria-pressed is true the button is in a "pressed" state, when aria-pressed is false it is not pressed. If the attribute is not present, the button is a simple command button.

https://www.w3.org/TR/wai-aria-practices-1.1/#button

Toggle button: A two-state button that can be either off (not pressed) or on (pressed). ...

See the "Mute audio" example: https://www.w3.org/TR/wai-aria-practices/examples/button/button.html

aria-pressed identifies the button as a toggle button.

Screenshots Examples of good toggle buttons in the Gutenberg UI:

The heading level state persists: this is a correct usage.

The selected color persist: correct usage.

The HTML block view mode persists: correct usage.

Instead, buttons that open sidebars, menus, and the like need to indicate:

• they open something => aria-haspopup
• the expanded thing state => aria-expanded

[afercia]

Practical impact of using aria-pressed together with aria-expanded (incorrect usage). tested with Firefox and NVDA on Windows:

To reproduce:

• navigate to the Settings button using the keyboard
• see the button is announced as "toggle button"
• activate the button multiple times
• verify that each time the screen reader announces both the pressed and the expanded/collapsed state
• this is incorrect, redundant, and pretty noisy for users