Improve accessibility of the Plugin & Themes Auto-Updates feature

[ryokuhi]

The Accessibility Team made a review of the Plugin & Themes auto-updates feature, recently introduced into core through #50052. A few accessibility issues where pointed out.

Enable / Disable controls as links

Currently, Enable / Disable controls are links. According to the ​accessibility coding standards (see the third row in the table):

• the control should be a link when JavaScript is not available and
• a button the rest of the time.

According to the current implementation, instead:

• when JavaScript is off, the links work because they have a working href attribute;
• when JavaScript is on, the links behave like buttons, but they’re still perceived as links.

A partial solution would be to add the CSS class aria-button-if-js, that adds a role=button for these cases; this doesn't make the link-as-button work through spacebar as expected, though.
To replicate the standard button behaviour, there's the need to:

• add a keydown event and prevent the default action (page scrolling);
• add a keyup event to trigger a click on the link, as native buttons are activated when the spacebar is released.

A better solution would be to change the link element to a button element, but the class aria-button-if-js should be changed with caution because of the risk to break existing behaviour (in case keydown and keyup events are already attached to the link).

Another solution might be to create a new CSS class aria-button-behavior-if-js, that can be assigned instead of aria-button-if-js whenever it is safe to do that.

Icons don't use aria-hidden=true

This problem was already addressed and solved during WordCamp Europe Contributor Day (see #50293)

Button text change

Currently, the "enabling / disabling" button text changes depending on the state, but it's a pattern that shouldn't be encouraged in general.

Two possible solutions were proposed.

1. Create two separate notifications for enabling and disabling, insert them after the button and then transition the text of the button after the event (for example, from “Enable auto-updates” to “Disable auto-updates”).
2. Have two buttons, one for enabling auto-updates and the other for disabling them.

The first solution might cause problems to some users. For example:

• Users learn there’s a button that says “Enable auto-updates”.
• Users do their job and enable (or disable) updates for various plugins.
• They search again for a button named “Enable auto-updates”, because the UI taught them there’s such a button.
• The button isn’t there any longer, at least apparently, because it now has a different name.

The second solution means there are always two buttons and one of them is always disabled, since it can't be used.

It's possible that there won't be a good solution for this specific issue and that it would be better to leave the interface as is.

Inline notifications

There's some code for inline notifications in case of errors: it's an empty paragraph that probably gets filled with some error message. It should be tested on how the message is announced and exposed to assistive technologies.