Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aria-expanded and CSS pseudo elements #5247

Open
nvaccessAuto opened this Issue Jul 26, 2015 · 13 comments

Comments

Projects
None yet
6 participants
@nvaccessAuto
Copy link

commented Jul 26, 2015

Reported by afercia on 2015-07-26 15:06
Looks like NVDA doesn't announce the aria-expanded attribute when it's dynamically changed and a CSS pseudo element content nearby gets changed too.

Please refer to the following example:
http://codepen.io/afercia/full/dogjjv/
tested in Firefox 39 + NVDA 2015.2

Though the CSS pseudo eleent is unrelated to the button element, in the first example NVDA doesn't announce "expanded" and "collapsed" when activating the button.

In the second example, the CSS pseudo element doesn't change and NVDA correctly announces "expanded" and "collapsed" when activating the button.

Tested in JAWS, it works in both examples. FWIW tested also in ChromeVox and it works there too.

@nvaccessAuto

This comment has been minimized.

Copy link
Author

commented Jul 27, 2015

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).

@nvaccessAuto

This comment has been minimized.

Copy link
Author

commented Jul 27, 2015

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" :)

@afercia

This comment has been minimized.

Copy link

commented Jun 28, 2017

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 :)

@afercia

This comment has been minimized.

Copy link

commented May 31, 2018

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!

@leonardder

This comment has been minimized.

Copy link
Collaborator

commented Jun 20, 2018

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

@afercia

This comment has been minimized.

Copy link

commented Jun 21, 2018

@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 🙂

@MarcoZehe

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2018

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!

@afercia

This comment has been minimized.

Copy link

commented Jun 21, 2018

@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.

@jcsteh

This comment has been minimized.

Copy link
Contributor

commented Jun 25, 2018

@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.

@afercia

This comment has been minimized.

Copy link

commented Jun 25, 2018

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.).

@jcsteh

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2018

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.

@jcsteh jcsteh closed this Oct 29, 2018

@afercia

This comment has been minimized.

Copy link

commented Mar 16, 2019

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

@Adriani90

This comment has been minimized.

Copy link
Collaborator

commented Mar 17, 2019

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

@Adriani90 Adriani90 reopened this Mar 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.