Consider a way to clear the wp.a11y.speak() live regions

[afercia]

Splitting this out from the WPCamput/Tenon accessibility report, see ​https://github.com/WordPress/gutenberg/issues/15296. See also #47144.

When wp.a11y.speak() is used to make screen readers announce a message, it updates the content of the visually hidden ARIA live regions placed at the end of the page source.

In most of the cases this is not a problem but, when screen reader users continue to navigate the page content by arrowing, they may encounter again the text that was previously announced, because this text is perceived as normal content by assistive technologies.

Ideally, there should be a way to clear the ARIA live regions before users get to them by arrowing. This aw also the feedback from the WPCampus report:

clear the live region so that users who encounter it while manually reading do not hear it.

However, clearing the live regions shouldn't depend on a specific user action or scenario. It would require a more generic solution, preferably avoiding setTimeout() which seems to me a very fragile solution by its own nature.

This applies to the a11y JavaScript package as well.

[afercia]

In the screenshot above: the ARIA live region (notice the highlighted area in the bottom left corner) read out as normal page content after it has been populated by a previous speak() message.

[adamsilverstein]

However, clearing the live regions shouldn't depend on a specific user action or scenario. It would require a more generic solution, preferably avoiding setTimeout() which seems to me a very fragile solution by its own nature.

Any ideas for when we should clear the field if not after a delay of x seconds? Can we tell when the screen reader has completed speaking? Otherwise how can we know the announcement has been spoken before removing the message?

In most of the cases this is not a problem but, when screen reader users continue to navigate the page content by arrowing, they may encounter again the text that was previously announced, because this text is perceived as normal content by assistive technologies.

I wonder if we can make the region not show up for users when arrowing thru the page?

[anevins]

Discussed in the Media meeting for a pragmatic solution. We think it would be best to explore whether we can hide the aria-live area from reading and focus order, while still letting these messages announceable - Just as @adamsilverstein mentions above.

[anevins]

I've talked this over with the Drupal Accessibility team and there doesn't seem to be a solution to this issue. This seems to be just part of the parcel of using aria-live.

We've discussed and experimented with the possibility of hiding the aria-live regions, however in doing so we noticed that the aria-live region no longer announced as per its correct behaviour - Props @andrewmacpherson for doing that testing.

Now we may want to consider taking this to the W3C community and discuss a better way of implementing aria-live without leaving stray text in the DOM. When that ticket is raised I think we can close this one.

[adamsilverstein]

Thanks for the research and feedback @anevins! That is great to know (and a little disappointing).

@afercia Ok to close this one out?

[afercia]

consider taking this to the W3C community and discuss a better way of implementing aria-live without leaving stray text in the DOM.

I'm not sure there's anything wrong in the W3C aria-live implementation. Live regions are not necessarily meant to be visually hidden. It's the WordPress implementation that uses invisible live regions.

Ideally, the same content (or at least a comparable experience) should be served to all users. Ideally, messages sent to a live region should be seen and heard simultaneously, creating ​comparable visual and aural experiences.

Since WordPress makes live regions visually hidden, it's a WordPress responsibility to explore a way to make them not perceivable via regular navigation with a screen reader.

As a last resort, we could always try setTimeout() with a relatively long interval: after all navigating to the end of the page source requires time so, for example, 10 seconds could work. Better options would be welcome. @stommepoes when you have a chance: any suggestions on a solid way to clear out the live region content?

[adamsilverstein]

Since WordPress makes live regions visually hidden, it's a WordPress responsibility to explore a way to make them not perceivable via regular navigation with a screen reader.

Often spoken messages are used to re-enforce activity on the page that is already obvious to sighted user (eg. "five results were found") I think thats why its generally been hidden.

I wonder if we can consider an "accessible mode" for WordPress (user based) where spoken messages would also show visually. We already have an accessibility mode for certain screens (thinking menus), this would a profile setting instead.

Do screen readers offer an option to visually show (caption) what they are speaking?

[anevins]

The issue of the live region being announced when it is not relevant is not one that WordPress has introduced; whether we visually hide the region, the issue would persist. I might be misunderstanding things here, can you clarify what you meant there @afercia ?

[afercia]

Do screen readers offer an option to visually show (caption) what they are speaking?

• VoiceOver shows spoken text by default.
• NVDA has a "Speech viewer", but it's mainly meant for debugging and development
• JAWS has a "Braille Viewer", which is a separate window that shows the spoken text and a "Speech History", basically a log meant for debugging purposes

But I guess this isn't what you hoped for.

The issue of the live region being announced when it is not relevant is not one that WordPress has introduced; whether we visually hide the region, the issue would persist.

It really depends on the implementation.
Think at a visible live region that displays the number of search results (and it's also spoken). Why one would ever want to clear the visible message?

Other visible live regions examples:
​https://inclusive-components.design/notifications/#liveregions101

Also relevant for better understanding (though related to Microsoft PowerApps):
​https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/accessible-apps-live-regions

Position the live region in a logical position in the app, even if it isn't visible. Ensure that its contents are sensible in context with the elements before and after it. Users can access a live region anytime through regular navigation with a screen reader, not just when changes happen.

[anevins]

Okay gotcha!

[adamsilverstein]

@afercia thanks for the links! I'll read up and get back to you here. it feels like we should at least ensure our live region is structurally well placed, and perhaps even consider adding it as a visible element instead. Possibly something that could be part of the notifications api? (​https://make.wordpress.org/core/2019/08/20/wp-notify-kick-off-meeting-announcement/)

[afercia]

Yuo, the notifications API opens up new, interesting, scenarios.

Re: placement and visibility: the speak() live regions are used as "generic" live regions for any sort of message. They're not tied to a specific functionality or a specific kind of information. I'm not sure we can identify a proper context and place them close to the elements related to a specific message, as the context changes.

Maybe, the notifications API could consider a generic, visible, area to display these messages. Even in this case, I guess the visible area should be cleared out after some time interval to avoid messages to stick indefinitely in the UI?

[desrosj]

Per the ​discussion in a recent #accessibility scrub, a reliable way to solve this has yet to be thought up. I'm going to punt this one, but if a patch is written before the 5.3 beta 1 deadline on 23 September, it can be reconsidered.

[afercia]

Looking back at this issue, the main problem with clearing the ARIA live regions after a certain delay is that the delay value would be totally arbitrary. For example, let's consider a 10 seconds delay. What happens if, after some user action, a second message is sent to the ARIA live after 10 seconds or a bit before / after? Would screen readers be able to get the text change soon before or after the regions has been cleared? In my experience, screen readers need some time to get aware of and announce a text change. Thus there's always the change they might miss a text change and not announce anything.

During the recent WordCamp Verona (Italy), ​Simone Mignami suggested an alternative, simpler, option. Placing some visually hidden text before the ARIA live regions would allow to communicate those are a "notification area", letting users understand the text is a notification that might be no longer relevant. I'd like to hear the accessibility team thoughts on this approach, which seems reasonable to me.

[afercia]

Discussed during today's accessibility bug-scrub: quoting:

If we come up with a reliable way of clearing the data - which is problematic, since it depends on the knowledge that AT has announced the message, which we don't have, or arbitrary timing, which is... arbitrary, then we can implement that later. For now, this seems likely a reasonable way to handle the problem.

[audrasjb]

As per today's accessibility bug scrub, it's not realistic to keep it in milestone 5.3.1, expected to be released in a couple of weeks. Moving to 5.4.

[MarcoZ]

I have seen these live region artifacts in a lot of places. Big companies like FB or others don't properly clear them often enough. :-) Probably due to similar reasons, clearing on a timer is not really a good idea. I like Simone's suggestion to put some explanatory bit before the actual text, but not have that spoken automatically, probably by setting aria-live="off" on that particular extra bit. That way, it would appear in the buffer, but not clutter up the actual announcement.

[afercia]

Thanks @MarcoZ. I was actually thinking to place the explanatory text outside the live region, right before it.

[MarcoZ]

Replying to afercia:

Thanks @MarcoZ. I was actually thinking to place the explanatory text outside the live region, right before it.

Oh OK, yes that would of course work, too, to not speak it during a live region update.

[davidbaumwald]

@afercia With this still needing a patch, do you see this making in before the 5.4 Beta 1 deadline in a few days?

[afercia]

@davidbaumwald this would need to be patched in the a11y package so I'm afraid it won't make it.

[afercia]

Pull request available on the Gutenberg GitHub at ​https://github.com/WordPress/gutenberg/pull/22112.

[afercia]

This has been fixed in the @wordpress/a11y package on the Gutenberg GitHub repository, see ​https://github.com/WordPress/gutenberg/pull/22112, and will be merged in core with the next NPM packages update.