Opened 4 years ago
Closed 4 years ago
#50512 closed defect (bug) (fixed)
Improve accessibility of the Plugin & Themes Auto-Updates feature
Reported by: | ryokuhi | Owned by: | |
---|---|---|---|
Milestone: | 5.5 | Priority: | high |
Severity: | normal | Version: | 5.5 |
Component: | Upgrade/Install | Keywords: | has-patch |
Focuses: | ui, accessibility, administration | Cc: |
Description
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.
- 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”).
- 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.
Attachments (1)
Change History (12)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
4 years ago
#5
@
4 years ago
- Priority changed from normal to high
I'm marking this as a high priority because these a11y issues should be fixed prior to release.
I read through the chat log discussion, and it seems only items 3 & 4 remain.
#6
@
4 years ago
Correct thanks @desrosj! Only 3) Button text change, and 4) Inline notifications remain.
Not sure 3) can be addressed for 5.5 as it would need some design decision. I'll test 4).
#7
@
4 years ago
Double checking 4) Inline notifications:
I see the pattern where a notice with an empty paragraph is printed out and hidden until it receives some text is already used in a few places, for example:
- the posts/terms quick edit/bulk edit
wp_comment_reply()
We should check all those instances. For what concerns the specific instances used for the auto-updates, I see that whenever there's an error, the notice gets revealed to display an error message and the same message is sent to the polite ARIA live region via wp.a11y.speak()
👍
The only thing I'd change is the politeness level of the ARIA live messages. Since these notices are errors, I'd use assertive
so that the audible messages are equivalent to alerts and assistive technologies will immediately notify the user interrupting the current announcement.
Quick patch incoming.
Re: 3) Button text change:
I think this should be postponed to the next release cycle. Will wait for the next accessibility team meeting on Friday to make a final decision. To summarize what was discussed so far:
- the auto-updates links are more an on/off toggle
- the more appropriate native element for that would be a checkbox
- concerns were expressed for the presence of too many checkboxes in the plugins and (network) themes tables
- we'd need to evaluate some other kind of "toggle" control
- for example a toggle button with normal and "pressed" state, or a switch toggle
- the goal for this change is, as usual:
- a control's text should not change dynamically to represent its state
- the state should be conveyed separately
- the control should only communicate the underlying action and maybe have a visual hint for its state (like the checkmark for native checkboxes) but it should never change its text
#8
@
4 years ago
- Keywords has-patch commit added; needs-patch removed
50512.diff does two things:
- changes the politeness level of the two calls to
wp.a11y.speak()
for the error messages introduced in [47835] toassertive
- removes the parameter
polite
from all the other usages: unnecessary becausepolite
is the default level
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
4 years ago
#11
@
4 years ago
- Keywords commit removed
- Resolution set to fixed
- Status changed from new to closed
Per the last linked a11y chat by Slackbot, the remaining issues will be tackled in 5.6 through a new ticket. Closing this one out.
Can someone please just make sure to open new tickets for any other remaining issues?
Related: #50516