[wp-trac] [WordPress Trac] #50512: Improve accessibility of the Plugin & Themes Auto-Updates feature

[WordPress Trac]

#50512: Improve accessibility of the Plugin & Themes Auto-Updates feature
-----------------------------------------------+-------------------------
 Reporter:  ryokuhi                            |      Owner:  (none)
     Type:  defect (bug)                       |     Status:  new
 Priority:  normal                             |  Milestone:  5.5
Component:  Security                           |    Version:  trunk
 Severity:  normal                             |   Keywords:  needs-patch
  Focuses:  ui, accessibility, administration  |
-----------------------------------------------+-------------------------
 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
 [https://developer.wordpress.org/coding-standards/wordpress-coding-
 standards/accessibility/#semantics-for-controls 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50512>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform