WordPress.org

Make WordPress Core

Opened 15 months ago

Closed 3 months ago

Last modified 3 months ago

#36853 closed defect (bug) (fixed)

Safari and VoiceOver don't announce repeated, identical, aria live messages

Reported by: afercia Owned by: afercia
Milestone: 4.8 Priority: normal
Severity: normal Version: 4.3
Component: General Keywords: has-screenshots has-patch fixed-major
Focuses: accessibility, javascript Cc:

Description

Noticed while investigating on #36848. Unlike other browsers / screen readers combinations, seems Safari and VoiceOver don't announce repeated aria-live messages when the message text string is the same string used in the previous message.

wp.a11y.speak() uses an aria-relevant attribute set to a value of additions text (which is the default value) thus only added text should be announced. To make repeated strings work, in [33000] wp.a11y.speak() has been changed in order to clear the aria live region before dispatching a new message.

Seems this works in all browsers / screen readers combinations I've tested with, except Safari and VoiceOver.

One place where this happens is in the Themes Installer screen, to reproduce:

  • run a search with a non sense string, e.g. "qwertyuiop"
  • the message "No themes found. Try a different search." gets announced

https://cldup.com/5ua5iUBHrz.png

  • add one character to the previous search string, e.g. "qwertyuiopa"
  • a new search runs, the aria live gets cleared out and the same message gets dispatched
  • Safari and VoiceOver don't announce the message, seems they don't get the "change" in the aria live region

I'm not sure how to fix this, also not sure if this is a Safari/VoiceOver bug or just a different implementation.

Using aria-relevant=all would make other combos announce both the removed text and the added text so it's not an option.

Maybe, try to find a way to force VoiceOver to think the new string is different, adding some not-readable character. Any thoughts more than welcome.

Attachments (1)

36853.diff (964 bytes) - added by afercia 4 months ago.

Download all attachments as: .zip

Change History (19)

#1 @afercia
15 months ago

Simplified test case:
http://s.codepen.io/afercia/debug/ZWNGPO

Just use Safari + VoiceOver, click the button and wait for the message, then click again. Compare with other browsers/screen readers combinations.

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


15 months ago

#3 in reply to: ↑ description ; follow-up: @GrahamArmfield
14 months ago

Replying to afercia:
Have you tried setting a delay between blanking out the message in wp.a11y.speak() and setting it to new value? A few miliseconds may be all that is required.

Alternatively, have the wp.a11y.speak() function automatically clear the aria-live region after a few seconds every time it's called.

#4 @arush
14 months ago

  • Status changed from new to closed

When I tested the simplified use case using iOS 9.3.2, I'm unable to reproduce this bug. The most current thorough support notes I can find in aria-relevant are at http://pauljadam.com/demos/aria-atomic-relevant.html but it appears to be two years out of date based on the version number of NVDA referenced. According to https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions there's also no current info on which screen reader/browser combo supports what with regard to live regions. I wonder if we can create a test for this and send it to the test team, with VoiceOver and Safari on OS X as the specified testing environment.

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


14 months ago

#6 @Cheffheid
14 months ago

  • Status changed from closed to reopened

#7 in reply to: ↑ 3 @afercia
13 months ago

Replying to GrahamArmfield:

Replying to afercia:
Have you tried setting a delay between blanking out the message in wp.a11y.speak() and setting it to new value? A few miliseconds may be all that is required.

Forgot to comment that yes, I've tried adding a delay and things get a bit better. Started with a few milliseconds and nothing happened, then progressively increased till 150ms and VoiceOver magically started to read out identical, repeated strings. Sometimes :) Sometimes not though, during my testing the behaviour was a bit inconsistent.

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


13 months ago

#9 @afercia
13 months ago

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

@afercia
4 months ago

#10 @afercia
4 months ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Future Release to 4.7.5

One possible way to fix this Safari+VoiceOver issue is appending a no-break space character \u00A0 to a repeated string, this way the new message will be "different" and VoiceOver will announce it. I've tried also with other invisible characters, but the no-break space looked "safer" to me. Any thoughts welcome.

The post Tags meta box is one place where testing this is very easy:

  • without the patch applied, click on "Choose from the most used tags"
  • then click on a few tags: VoiceOver will announce "Term added." just the first time
  • same when removing tags, clicking on the "X" close to the tag names

With the patch applied:

  • repeat the steps above
  • VoiceOver will announce "Term added." and "Term removed." each time a tag gets added or removed

https://cldup.com/NNzLwjC9Hx.jpg

Would greatly appreciate any thoughts on the addition of the \u00A0 character. If no objections, I'd like to propose to consider this for the 4.7.5 release, as it's a long standing, annoying, bug for VoiceOver users.

#11 @afercia
4 months ago

  • Keywords commit added

Tested in:

  • Safari 10 + VoiceOver
  • Firefox + NVDA
  • Firefox + JAWS
  • IE 11 + Jaws

the \u00A0 character solves the Safari 10 + VoiceOver issue and doesn't break anything in other combos. Looks good to me. Note: IE 11 and Edge show the added character in their DOM inspector only when "Editing as HTML" the live region div. Chrome shows a   but the actual character is \u00A0.

#12 @afercia
4 months ago

  • Owner set to afercia
  • Resolution set to fixed
  • Status changed from reopened to closed

In 40479:

Accessibility: Make Safari 10 + VoiceOver announce repeated, identical, wp.a11y.speak() messages.

Safari 10 + VoiceOver don't announce repeated, identical, strings sent to an
aria-live region. Appending a no-break space to a repeated message string,
forces them to think the strings are different.

Fixes #36853.

#13 @afercia
4 months ago

  • Keywords fixed-major added; commit removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for 4.7.5 consideration.

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


4 months ago

This ticket was mentioned in Slack in #core by desrosj. View the logs.


3 months ago

#16 @desrosj
3 months ago

  • Milestone changed from 4.7.5 to 4.8

#17 @afercia
3 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Yep this was reopened just for back-porting it to 4.7.5 and can be closed now.

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


3 months ago

Note: See TracTickets for help on using tickets.