Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Components: Speak Notice message #15745
This pull request seeks to move spoken message handling for notices from the notices store into the
I could use some accessibility feedback here. Per #9442, there's a recommendation to use the
Verify there are no regressions in the spoken messages of notices (example: published post "Post published!" notice).
Verify that notices mounted by
@aduth thanks for working on this, I've finally found some time to have a look at it.
speak() vs. alert and status roles
That was a suggestion: given the notices don't use
The alert and status roles are just specialized types of live regions. The
One difference is that the
Basically, never use both
Which one should be used?
Theoretically, we should leverage existing standards and prefer role alert/status. However, there's one big caveat.
Some screen readers are able to announce elements with role alert / status that are "rendered on the fly" and added to the DOM. Not all screen readers are able to do that though. And that's not the recommended way to use these roles.
For maximum compatibility with the various browser/screen reader combos, it is expected that the elements with role alert / status are present in the DOM on page load. Typically, this is not the way the Gutenberg Notices work. They're added to the DOM. Instead, the
Using ARIA role=alert or Live Regions to Identify Errors
Using role=status to present status messages
Considering all this, I'd recommend to use
Code related considerations
Looking at the code, I was initially confused by this. It's just about naming. With this implementation, we're not setting ARIA roles, so I'd suggest to rename the prop and the
Seems to me what is needed here is to just determine the politeness level. Considering also that developers are not required to know what a role is, I'd suggest to:
Looks good to me, as long as there's a way to override the default politeness level. As you pointed out, there's no 1-to-1 mapping between the notices type and the politeness level. For example, there may be cases where a
I'd also suggest to well document this and make very clear the difference is:
Worth also noting that these values are suggestion and assistive technologies may override them based on internal heuristics. For more details: https://www.w3.org/TR/wai-aria-1.1/#aria-live
Yes. I'd just rename things as commented above.
Not sure I fully understand, I guess the previous considerations cover this point?
Add a way to pass a custom message
While testing the
In some cases, we're intentionally using a shorter, simpler message. For example in the
While we've opted to use a horter, simpler, message for
This is because the longer messages would add a lot of noise and in this cases a shorter message is preferable.
While the use of
Note on current documentation:
Not sure this part is accurate:
Referring to "medium importance" could be a bit misleading
Question on NoticeList
I'm not sure I understand if all this will work with the
Apologies for my delay in revisiting this pull request, and a belated "Thank you!" to @afercia for your extended feedback.
I've had a chance to refresh this today. Specifically, this includes: