WP Speak assertive message and Firefox + NVDA bug

[afercia]

Looks like Firefox and NVDA have a weird behavior with the assertive live region used for wp.a11y.speak(). To make things more clear, I've prepared a short video:

​https://cloudup.com/cxI6TBs0xaa

Video direct link if you can't see it in the player:
​https://cldup.com/GcWiYceo7x.mp4

In the video, I'm just opening two "popup" modal dialogs used in WordPress. When the modal dialogs open, NVDA announces "Alert" and stops. Worth reminding wp.a11y.speak() uses two live regions that are injected in the DOM, the second one has an ARIA role="alert" and an aria-live="assertive" ARIA property. Worth also noting:

• seems it happens only with Firefox + NVDA
• tested with Internet Explorer 11 and NVDA and couldn't reproduce
• tested with Internet Explorer 11 and JAWS and couldn't reproduce

The good news: IMHO this is not a WordPress bug. As far as I know, the specification says that role=alert should be processed like an assertive live region, that means screen readers should monitor changes in the content of the live region. No content change happens here, so nothing should be announced.

The bad news: looks like screen reader support for live regions is inconsistent.

Turns out the CSS overflow: hidden set on the body when opening modal dialogs (and also in the Customizer) triggers this behavior. My only guess is that Firefox rebuilds something in the accessibility tree when the body gets an overflow other than "visible" and NVDA announces the live region even if there's no change in the content.

It would be great to hear the experts thoughts and recommendations, will try to ask around. Also, prepared two tests on Codepen, the first one tries to reproduce what happens in WordPress:
​http://s.codepen.io/afercia/debug/mPRKLa

the second one is a very simplified case, all that it does is toggling overflow with different values on the body and also on a DIV that contains an assertive live region:
​http://s.codepen.io/afercia/debug/zqZyKe

Would be great to find a workaround to improve the users experience, even if maybe this is something that should be reported upstream. I'd like to collect some feedback and then perhaps open a ticket upstream.
Any thoughts more than welcome :)

[Cheffheid]

What would the downside be of prepending, instead of appending, the live regions to the body?

I forked your simplified demo and moved the a11y.speak areas up to the top, which seems to alleviate the issue (until I click the buttons quickly, then alert pops back into the speech viewer). It makes very little sense to me that it would, though.

​http://s.codepen.io/Cheffheid/debug/mPwrYO

[afercia]

@Cheffheid yep I've tried to prepend instead of append, it alleviates a bit the issue but it is still there. To me, it seems a Firefox and NVDA bug :) The only workaround I can think of is to hide the assertive live region and make it visible just before it receives a message. After the message, it should be hidden again. I've tried using the attribute hidden and it seems to work. This would force us to make the WordPress implementation not so clean as it is now though. I wouldn't be so happy to do that to fix bugs that should be probably fixed upstream :(

[Cheffheid]

Yeah, I agree. And it does look like a Firefox issue, triggering an alert for NVDA to announce. It may consider the overflow change as "making the element visible" and trigger the alert, as described on Example 4: ​https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role.

But I do think we should handle this as a browser support issue and implement the workaround as best we can. Simply because at this point there's going to be two outcomes:

1. It's not intentional Firefox behaviour, which means we'll need to wait for it to be fixed and for people to adopt that version. I don't know exactly how Mozilla decides what fixes go where, but even if a fix were to land in 49 or 50 we'd be waiting for the end of Q3/early Q4 for it to be fixed. And potentially looking at Q1 of next year for full adoption. All the while we've got a bunch of irritating noise when using the Customizer.

2. It's intentional, in which case it will never get fixed and we'll need to implement a workaround anyway.

Let's assume it's not intentional for now, which means we'll definitely want to do that bug report on Bugzilla and get a definitive answer that Example 4 is actually what's happening here.

[afercia]

After some investigation I think it is caused by a mix of Firefox and NVDA behaviours. Firefox does repaint when setting CSS overflow other than visible, see screenshot below:

At this point, NVDA probably thinks an element with role=alert just appeared on the page and it announces it. I think this is not a correct implementation because, according to the specification:
​https://www.w3.org/TR/wai-aria/roles#alert

Alerts are assertive live regions and will be processed as such by assistive technologies.

This means when there's no content change in the live region, nothing should be announced. Will report upstream to hopefully get some precious insights and suggestions.

On the other hand, the two live regions use both a status/alert role and an aria-live attribute. This is redundant but it was done intentionally to maximize coverage with the various browsers and assistive technologies combinations. See for example:
​https://www.w3.org/WAI/GL/wiki/Using_ARIA_role%3Dalert_or_Live_Regions_to_Identify_Errors

The third example uses BOTH role=alert & aria-live=assertive on the error container for wider UA/AT support working in all combinations listed.

Specification:
​https://www.w3.org/TR/wai-aria/roles#alert

Note: Elements with the role alert have an implicit aria-live value of assertive

​https://www.w3.org/TR/wai-aria/roles#status

Note: Elements with the role status have an implicit aria-live value of polite

While waiting for some upstream feedback, I'd propose to completely remove the role attributes and just use aria-live. This solves the issue in Firefox+NVDA and should not cause new big issues. The worst thing that can happen is that assertive messages won't immediately interrupt what is being read out.

Any thoughts more than welcome.

[afercia]

Opened an issue on the NVDA GitHub, see:
​https://github.com/nvaccess/nvda/issues/5924

See also:
​https://github.com/nvaccess/nvda/issues/5657

[afercia]

The proposed patch removes the ARIA roles from the live regions, waiting for a fix upstream. Worth noting that using both the ARIA roles status / alert and all the aria-live related attributes is redundant but was done intentionally to maximise compatibility with all the various browsers / screen readers combinations.

[afercia]

NVDA 2016.2 is out since a few days without a fix for this issue. There are to related tickets upstream: ​https://github.com/nvaccess/nvda/issues/5924 (now closed as duplicate) and ​https://github.com/nvaccess/nvda/issues/5657 (pending).

As discussed with the accessibility team, the best solution for now is to remove the ARIA roles from the live regions. Having NVDA announcing "alert" even when there's no message dispatched and also interrupting what is being read out is a subpar experience for users and definitely something to avoid.

[afercia]

In 37734:

Accessibility: Remove the ARIA roles from the wp.a11y.speak() live regions.

When Firefox repaints some elements, NVDA may announce "alert" even when there's
no actual message dispatched to the live region. The NVDA implementation differs
from other screen readers and is currently under discussion. To avoid a subpar
user experience better to remove the roles since they're basically redundant.

Fixes #36289.