aria-hidden ignored when using mouse in Firefox

[nvaccessAuto]

Reported by jethac on 2014-07-23 09:16
We're currently redeveloping some interfaces in Moodle with an eye to removing redundant and extraneous content for users of assistive technologies, and we ran into an interesting bug using NVDA 2014.2 with Firefox 31.0 on Windows 8.1.

With markup like this:

<a role="presentation" href="http://10.211.55.3/m/stable_master_46285/user/profile.php?id=2" aria-hidden="true">
    <img src="http://10.211.55.3/m/stable_master_46285/theme/image.php?theme=clean&amp;component=core&amp;image=u%2Ff2" alt="Picture of Admin User" title="Picture of Admin User" class="userpicture defaultuserpic" role="presentation" height="35" width="35">
</a>

when the link is mouseovered, the href attribute is read out by NVDA, ignoring the aria-hidden attribute. This isn't something we would like to have happen, as it doubles the elements read out by the screen reader; John Foliot posted a series of tests on issue #2117 ( http://john.foliot.ca/aria-hidden ) that do a much better job than I ever could describing the issue. Indeed, mouseovering the image in John's first test illustrates the problem.

Using the HTML5 hidden attribute or visibility:hidden in CSS won't meet our requirements either, as we want sighted users to be able to see and click the user picture in question. A partial workaround can be achieved by removing the href attribute from the anchor tag, but that's not really an option either.

The issue does not present in Chrome.

[nvaccessAuto]

Comment 1 by jteh on 2014-07-28 07:43
Note that, unless I'm misunderstanding this report, this only applies to mouse tracking, which is not how the majority of users will interact with the web using NVDA. If you use browse mode (i.e. using the keyboard), you should not see this content.

Nevertheless, we should probably make mouse tracking ignore invisible elements.
Changes:
Changed title from "links with aria-hidden still read out on Firefox" to "aria-hidden ignored when using mouse in Firefox"

[nvaccessAuto]

Comment 2 by jteh on 2014-07-28 07:44
Moving to core, since this isn't related to browse mode. (Mouse tracking doesn't use browse mode.)

[steverep]

This bug is not limited to Firefox and occurs in IE as well. Also, it is coming up in the context of creating new techniques for WCAG 2.1 that have strong accessibility support (see w3c/wcag21#297).

Note that, unless I'm misunderstanding this report, this only applies to mouse tracking, which is not how the majority of users will interact with the web using NVDA.

From a statistical perspective of NVDA's users, I can understand relegating bugs like this to low priority for such reasons, but isn't that reasoning a bit hippo critical considering it could be turned around and applied to do nothing about inaccessibility? From a business perspective, it would also make sense to fix and expand such features to include a wider range of visual impairments within users.

[LeonarddeR]

CC @jsteh:

Honestly, I belief the major part of this issue should be treated as expected behavior. Note that aria-hidden doesn't mean visually hidden. So, it should make the screen reader ignore the content when using screen reader specific commands, but when the mouse hovers over the object which is actually on screen, I belief that NVDA should read the hovered content, even though aria-hidden is True. The unexpected part here is that NVDA seems to read the href content, not the alternative text for the inner image.

[bekza]

if you hover over aria-hidden="true" will not work, but if you just let the NVDA read the screen it will read whatever needs to read, and
<span aria-hidden="true" role="presentation">NVDA screen reader Doesn't read this content</span>

[jcsteh]

aria-hidden content is no longer exposed by Firefox at all as of Firefox 63 (currently nightly). See Mozilla bug 1349223. @LeonarddeR's argument that aria-hidden content should be read on mouse over does make some sense, and similar arguments have been made concerning magnification. At the end of the day, right or wrong, the spec says that aria-hidden should remove elements from the tree, and despite years of fighting this, being inconsistent with the spec (and other browsers) wasn't sustainable. aria-hidden, as poorly specified and broken as it is, is here to stay. See the comments in the Mozilla bug (and other bugs referenced therein) for more discussion about this than you could ever possibly want to read.