[wp-trac] [WordPress Trac] #46573: Introduce a Site Health module for users to self-service their site

[WordPress Trac]

#46573: Introduce a Site Health module for users to self-service their site
---------------------------------------+-----------------------
 Reporter:  Clorith                    |       Owner:  pento
     Type:  task (blessed)             |      Status:  assigned
 Priority:  normal                     |   Milestone:  5.2
Component:  General                    |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  has-patch has-screenshots  |     Focuses:
---------------------------------------+-----------------------

Comment (by afercia):

 1
 > That ticket doesn't specify an accessibility issue, just that it was
 confusing what was being copied. This could be rectified by modifying the
 button label (eg, "Copy Report to Clipboard").

 Actually, that GitHub issue makes a clear point:

 > The main key is giving people an opportunity to review what they're
 copying as a block prior to copying to clipboard

 The actual recommendation is displaying the content of the textarea. I'd
 say it's not just about accessibility: it's also usability.

 2
 > if we set aria-hidden="true" tabindex="-1" on the <textarea> elements
 that exist for the copy button to work, will that be sufficient to hide it
 from screen readers and keyboard navigation?

 It would be sufficient for keyboard users, not so much for screen reader
 users.
 - screen reader users navigate content primarily by using arrow navigation
 provided by ths screen reader: tabindex has no effect
 - the actual effects of `aria-hidden`
 [https://developer.paciellogroup.com/blog/2012/05/html5-accessibility-
 chops-hidden-and-aria-hidden/ vary across browsers] and assistive
 technologies, especially when used on form elements. For example, Chrome +
 VoiceOver still read out the textarea content

 3
 Show passed tests button:
 - as mentioned in [https://github.com/WordPress/health-check/issues/264 a
 related GitHub issue], it can't be hidden once activated: that would
 produce a focus loss
 - generally, I'm not in favor of dynamically changing a control's label:
 the label is the accessible name of a control; its state should be
 conveyed separately. Potential issue: screen reader users learn there's a
 control named "xyz". They continue navigation. Then, they look for the
 previous control and can't find it (or would be in doubt) because the
 control's name has changed to something else.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46573#comment:50>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform