Site Health: Improve the speak() messages

[afercia]

When the Site Health tests run, a few audible messages are sent to the speak() ARIA live regions. These messages are announced by screen readers and provide users with audible feedback about what's going on.

However, I'm not sure the current messages provide users with the best experience, as they are somehow confusing and sometimes they seem to happen in an incorrect order.

Note: in the screenshots below, I'm using a small plugin to dump to the console the audible messages text, to better illustrate what screen reader users get.

1
When the admin Dashboard page loads, the Site Health widget triggers two audible messages. They have the same text:

`
All site health tests have finished running. Your site is looking good, and the results are now available on the page.
`

• I found this message confusing: as a user, I just landed on the Dashboard and I have no idea why I'm getting messages related to this thing called 'Site Health'. Actually I may not even know what Site Health is.
• The message text says that 'the results are now available on the page'. What page? There are no results on the Dashboard page.

2
Tools > Site Health > Status

• Visually, some text at the top informs sighted users that Results are still loading…. There's no equivalent info for screen reader users. It is worth considering to add a speak message to provide an equivalent information to screen reader users.
• When all the tests results are available, a message informs users that All site health tests have finished running. Your site is looking good, and the results are now available on the page.. That's okay.

3
Tools > Site Health > Info
This is perhaps the most confusing case. At first, two messages inform users that All site health tests have finished running. Your site is looking good, and the results are now available on the page.

Then, a new Please wait... message informs that something is still running.

After that, a new message informs that all results are available: All site health tests have finished running. Your site is looking good, and the results are now available on the page.

Then, a bit unexpectedly, a new message informs again that All site health tests have finished running.

Overall, I think all the audible feedback has room for improvements to make the messages:

• better match the actual state of the tests and the state of the UI
• avoid repetition
• be more concise

[afercia]

Dashboard

[afercia]

Site Health > Status

[afercia]

Site Health > Info

[joedolson]

I don't think that these messages should be announced at all on the Dashboard; the dashboard has the potential to have a ton of different things going on, and if they were all making announcements, it would be pure chaos, as well as making context much more difficult to track.

[afercia]

For clarity and testing:
The Please wait... message and the following ones are triggered only if the directory sizes test response takes more than 3 seconds. Normally, you won't get these messages. For testing purposes, you may need to throttle your network via your browser dev tools and/or throttle PHP execution.

[afercia]

58573.diff​ is a first pass.

• Moves the speak() calls to a new function.
• Prevents the messages from being announced on the Dashboard page by checking for SiteHealth.screen.
• Shortens a couple messages by removing the part 'and the results are now available on the page.', which seems not necessary to be specified.
• Prevents a redundant message from being announced.

Regarding the last point: seems to me recalculateProgression() already triggers a speak message anyways. I moved a call to recalculateProgression() within the setTimeout that was used to trigger the 'redundant' message. This way, when the directory sizes test takes more than 3 seconds and then completes, score calculations and visual updates will run after some delay. Also, a speak message will be triggered. Unless I'm missing something, this seems OK to me. On one hand, it is good that the visual updates and the speak message happen at the same time. On the other hand, it's an edge case anyways because in the majority of the cases thi test will likely take _less_ than 3 seconds.
Cc @azaozz when you have a chance, I'd greatly appreciate your feedback.

[alexstine]

@afercia This is testing well but I cannot replicate the longer than 3 seconds loading message. Tried slowing network performance in dev tools but no luck. This is a great improvement over current trunk.

[afercia]

@alexstine thanks for testing this.

I cannot replicate the longer than 3 seconds loading message.

Yes this is difficult to reproduce. I don't think throttling the network helps. Instead, this directory sizes calculation is really about the amount of directories and files within the WordPress install. Having a lot of plugins with thousands and thousands of directories and files may make this calculation take more than 3 seconds. Or some hosting hiccup in production. In my case, having the Gutenberg plugin development trunk installed bring in its node_modules directory which contains a huge amount of files, thus triggering the 3 seconds thing.

[alexstine]

Copied in my local Gutenberg repo and it still wasn't large enough to cause a delay. All Node modules and local builds had been done. This sadly is not easy to test.

Trac ticket: https://core.trac.wordpress.org/ticket/58573

[joedolson]

I haven't been able to reproduce the 3 second delay, either - I think it's something with the directory file size recursion, though, or with some kind of directory size caching. I haven't explored it in detail, but I added *all* of my local plugin repos (about 60 repos) in their entirety to the plugins directory, approximately 2 GB of data, and it's reporting a directory size of 92 MB. The delay is not, however, *new* to this patch, so I don't think that's crucial to verify.

Otherwise, everything worked as expected for me. I think this should get committed for 6.4; removing these announcements from the dashboard alone is a significant improvement. The less verbose announcements are also beneficial.

[joedolson]

In 56670:

Site Health: Improve wp.a11y.speak() notifications.

Improve the experience for screen reader users by removing announcements produced in the Dashboard, simplifying the text to reduce verbosity, and ensuring that messages are spoken in the correct order to match the state of the user interface without repetition.

Props afercia, alexstine.
Fixes #58573.

In r56670