#58573 closed defect (bug) (fixed)
Site Health: Improve the speak() messages
Reported by: | afercia | Owned by: | joedolson |
---|---|---|---|
Milestone: | 6.4 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Site Health | Keywords: | has-screenshots has-patch commit |
Focuses: | accessibility | Cc: |
Description (last modified by )
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
Attachments (4)
Change History (18)
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
17 months ago
#2
@
17 months ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to 6.4
- Owner set to joedolson
- Status changed from new to accepted
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.
#4
@
17 months ago
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.
#5
@
17 months ago
- Keywords has-patch added; needs-patch removed
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.
#6
@
16 months ago
@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.
#7
@
16 months ago
@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.
#8
@
15 months ago
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.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
15 months ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
15 months ago
This ticket was mentioned in PR #5289 on WordPress/wordpress-develop by @joedolson.
15 months ago
#11
Trac ticket: https://core.trac.wordpress.org/ticket/58573
#12
@
15 months ago
- Keywords commit added
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 commented on PR #5289:
15 months ago
#14
In r56670
Dashboard