Comment 1 by jteh on 2015-07-27 00:42
I believe this triggers another instance of (or is at least closely related to) MozillaBug:659886. When the CSS pseudo-element content is changed, the accessible for the affected element (div.title) gets completely regenerated, which includes any children (meaning the button). As a result, NVDA is told that focus landed on a new element which just happens to occupy exactly the same space.

So, the fact that the behaviour is different between the two cases (with and without the pseudo-element content change) is a Firefox bug. The fact that we don't speak anything at all (even a focus change) is an NVDA bug. Note that even once this NVDA part is fixed, you'll still hear, for example, "Toggle button collapsed" instead of just "collapsed" as you do with the other button (focus versus state change).

Comment 2 by afercia on 2015-07-27 12:21
James thanks very much for your quick feedback. Thanks to your detailed explanation now I have a clue about the reason why also some other browser/screen reader combinations announce "Toggle button collapsed" instead of just "collapsed" :)

One possible workaround, until this gets hopefully fixed by Mozilla, is wrapping the CSS generated icon, or any other "visual decoration" that gets updated and triggers the accessible regeneration, within a span element with aria-hidden="true".
For what is worth, this workaround is actually used by WordPress in a few places, and it works. However, there are situations where we can't really use a wrapper element. Any suggestions on alternative workarounds would be greatly appreciated :)

Hello everyone. I'd greatly appreciate any suggestion to workaround this. For what is worth, it's an issue we're facing in various places in WordPress, including the new editor Gutenberg, see WordPress/gutenberg#1387

Until now, one of the workarounds was to wrap the icons with a span element with a aria-hidden="true" attribute. Unfortunately, this is very hard to implement in Gutenberg so I'm wondering if there's any known solution we can use. Thanks in advance!

@afercia: Is this also a problem in other browsers like Chrome and Edge?

@LeonarddeR thanks for the ping. To recap: testing again the pen linked above https://codepen.io/afercia/full/dogjjv/ with NVDA 2018.2.1 nothing has changed. When activating the first button, nothing gets announced, there's just silence.

Testing with NVDA and all the other major browsers (even IE 11!), the state change is announced correctly and just "expanded" or "collapsed" get announced.

Other combos tend to announce the whole accessible.
For example, Safari + VoiceOver announce the whole accessible, and they do so for all the three buttons (so I guess it's a specific VoiceOver case):

• toggle, expanded, button
• toggle, collapsed, button

I've found particularly interesting the JAWS behavior with Firefox:

• on the first button, it announces the whole accessible:
  • toggle button, expanded
  • toggle button, collapsed
• on the second and third buttons, it announces just the expanded state:
  • expanded
  • collapsed

Seems to me this is perfectly inline with what James said above, as it seems a mix of Firefox and NVDA behaviors. However, I'd say announcing the whole accessible is better than nothing 🙂

Yes, this bug is still open on our side. As you can see from comment 3 of that bug, the way Firefox currently implements accessibility, this is actually kind of expected behavior, since the elements are being moved from somewhere off-screen to on-screen, not hidden vs. visible in the display:none; or visibility:hidden; kind of sense. See the comment, which reads:

Yes, because the position changes which changes the frame tree in general (e.g. if the anchors had positioned descendants they would need to be parented to a different frame due to the position change).

In other words, the change in position and the resulting reframing of the element(s) causes a significant enough change to tell accessibility "OK, this is a big change, you better recreate from scratch rather than try to mutate the existing one". Not sure, if, and how, this can be solved, but the fact that this has been open for so long and the related meta bug is still open, too, indicates that this is a difficult problem to solve in the right way. Sorry about the inconvenience this causes!

@MarcoZehe thanks so much for diving into this. For what is worth, I'd say that having NVDA announce something (even if that's the whole accessible) would be better than being just silent.

@afercia commented on Jun 21, 2018, 9:00 PM GMT+10:

@MarcoZehe thanks so much for diving into this. For what is worth, I'd say that having NVDA announce something (even if that's the whole accessible) would be better than being just silent.

For sure. However, this, too, requires a pretty major refactor of some core NVDA code related to browse mode. Essentially, you're caught between two really-hard-to-fix bugs in two different pieces of software. The NVDA part is essentially the same as #5825 (comment). Hopefully, this would be addressed as part of #2039, though a previous attempt at addressing #2039 caused all sorts of pain and had to be reverted, which is why this hasn't been dealt with yet.

Thanks so much @jcsteh. Any idea for a temporary workaround would be super helpful too. As said, wrapping the icons with a span element with a aria-hidden="true" attribute seems to work but that's not always possible to implement (layout breakage etc.).

This is fixed by #8869 (now in NVDA alpha builds). I've verified the fix for @afercia's test case from #5247 (comment).

Note that NVDA will report the full control instead of just the change ("collapsed" or "expanded") as it should. This is because NVDA sees it as a focus change (not a state change) due to the (still not fixed) Mozilla bug. There are plans to fix the Mozilla bug (for this and many other reasons), but in the interim, this is an acceptable situation for NVDA.

Hello. I read in #8341 that #8869 had to be reverted. Should this issue be reopened then?

Yes, I would say let's reopen it because the discussion in this issue is also very relevant. Thanks for asking.

Fixed for Firefox 70 by https://bugzilla.mozilla.org/show_bug.cgi?id=686400. Fix available for testing in nightly.