JAWS, Window-Eyes and display:none: Return to 2007

The JAWS Bug

Back then, the situation with JAWS 7.1 was that it announces content in a span element hidden with display: none if it is in an anchor element. This only works with a span element; other inline elements used in an anchor element, such as em, strong, abbr, code, and so on, are not announced in JAWS. Additionally, this only happened with JAWS in Internet Explorer.

Having just tested this, I can confirm that this bug no longer affects JAWS 12 in Internet Explorer 9. After all, it has been about four years since that bug was discovered. In which specific version of JAWS this was fixed I can't say, having only tested the latest version.

The Window-Eyes Bug

While Window-Eyes 5.5 worked as expected with such hidden content, as soon as you added a CSS background image to the anchor itself or any other ancestor, up to but excluding the body element, Window-Eyes would announce the hidden content. Even if the link itself was hidden using display:none, if an ancestor element had a background image applied, Window-Eyes would read the link.

Using this test page, it is clear that Window-Eyes 7.5 in Internet Explorer 9, but not in Firefox 5, still exhibits the same bug. That is, content hidden using display:none is read by Window-Eyes in IE9 if the element itself or an ancestor has a CSS background image.

As was noted by Jared Smith all those years ago, doubling up display:none with visibility:hidden solves this problem with Window-Eyes. So if you are applying CSS background images and want to keep hidden children hidden from Window-Eyes in IE, this is what you'll need to do.

Browser Complicity?

Working with AViewer, the very useful tool from the Paciello Group, it seems that the accessible name that Internet Explorer 9 passes to the MSAA accessibility API for each of the anchors in the test page includes both the visible link text and the nested span hidden using display:none. On the other hand, Firefox 5 passes only the visible link text to both the MSAA and IAccessible2 APIs, leaving out the hidden span content.

This leads me, without completely understanding it all, to wonder if this might have something to do with Window-Eyes' behaviour where both the visible and hidden link text is read in certain conditions in IE9, but not in Firefox. If you can shed any light on this, please do.

2 Responses to JAWS, Window-Eyes and display:none: Return to 2007

hi jason, I think it is highly likely that the behaviour exhibited by window eyes is due to it taking the accessible name for the link from MSAA, this is a desired and expected behaviour (using the info provided via acc API properties) which should afford a measure of cross browser and cross AT interoperability if browsers do the right thing and calculate acc names in the same way. Unfortunately they do not in quite a few cases, which leads to problems for users and developers.

Hi Steve. Thanks for the feedback. I wonder, then, why Window-Eyes is still doing what it does with display:none versus visibility:hidden all these years later. JAWS gets the same info via MSAA but happily doesn’t read the hidden content. Is it really just some old legacy behaviour to account for inaccessible image replacement techniques?

In any case, I do look forward to that (mythical?) day when browsers are agreed on what info to pass to the APIs and screen readers on what to do with it 🙂