WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 5 weeks ago

#47156 assigned enhancement

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

Reported by: afercia Owned by: afercia
Milestone: 5.3.1 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots wpcampus-report needs-patch
Focuses: accessibility, javascript Cc:
PR Number:

Description

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.

Attachments (1)

live region at the end of the page source.jpg (118.7 KB) - added by afercia 7 months ago.

Download all attachments as: .zip

Change History (28)

#1 @afercia
7 months ago

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.

#2 @afercia
6 months ago

  • Keywords wpcampus-report added
  • Milestone changed from Awaiting Review to 5.3

This ticket was mentioned in Slack in #core-media by anevins. View the logs.


3 months ago

#4 @adamsilverstein
3 months ago

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?

#5 @anevins
3 months ago

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.

This ticket was mentioned in Slack in #accessibility by anevins. View the logs.


3 months ago

#7 @anevins
3 months ago

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.

Last edited 3 months ago by anevins (previous) (diff)

This ticket was mentioned in Slack in #core-media by anevins. View the logs.


3 months ago

This ticket was mentioned in Slack in #core-media by anevins. View the logs.


3 months ago

This ticket was mentioned in Slack in #accessibility by anevins. View the logs.


3 months ago

#11 @adamsilverstein
3 months ago

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

@afercia Ok to close this one out?

#12 @afercia
3 months ago

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?

#13 @adamsilverstein
3 months ago

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?

#14 @anevins
3 months ago

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 ?

#15 @afercia
3 months ago

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.

#16 @anevins
3 months ago

Okay gotcha!

#17 @adamsilverstein
3 months ago

@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/)

#18 @afercia
3 months ago

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?

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 months ago

#20 @afercia
3 months ago

  • Owner set to afercia
  • Status changed from new to assigned

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


3 months ago

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


2 months ago

#23 @desrosj
2 months ago

  • Keywords needs-patch added
  • Milestone changed from 5.3 to Future Release

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.

#24 @afercia
5 weeks ago

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.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 weeks ago

#26 @afercia
5 weeks ago

  • Milestone changed from Future Release to 5.3.1

#27 @afercia
5 weeks ago

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.

Note: See TracTickets for help on using tickets.