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

Already on GitHub? Sign in to your account

NVDA with IE doesn't render visible descendants of hidden elements #2097

nvaccessAuto opened this Issue Feb 9, 2012 · 8 comments


None yet
1 participant

Reported by Wildebrew on 2012-02-09 14:55
It appears that NVDA does not recognize edit fields in IE9 if the fields are siwhin a layout table.
To reproduce this go to: http://hbleit.bbi.is/Account/Login.aspx
and try to use the "e" button to find the next edit field (there are two, kennitala = social security number, and lykilorð = password). Using the tab key will get you there and using Firefox this works 100%.
Same with Jaws and IE, works fine.
If in NVDa 2011.3 on this page, trying to use the "e" key the announcement "no more edit fields" is read.
My guess is that this has something to do with the edit fields residing inside a layout table, but this html code seems pretty straight forward, so it appears likely that there are lots of similar pages out there where NVDA does not behave as expected.
Thanks for a great product.

Comment 1 by briang1 on 2012-02-09 17:42

On Windows XP I get the following results. In Firefox 3.6 the e command fails as described, but succeeds in Firefox 11. No errors are produced in either case. In IE 8, not only does the E command fail, but when you tab to the fields, the error below is produced with a roughly50/50 chance of IE terminating itself as in the log fragment.
I hope this is of assistance.

Speaking ('en_UK'), u'lei\xf0arkerfi vefsins', u'link'
IO - inputCore.InputManager.executeGesture (17:18:46):
Input: kb(desktop):tab
IO - speech.speak (17:18:46):
Speaking ('en_UK'), u'focus mode'
IO - speech.speak (17:18:46):
Speaking ('en_UK'), u'table'
ERROR - virtualBuffers.MSHTML.replayFocusEnteredEvents (17:18:46):
Error executing focusEntered event: <NVDAObjects.IAccessible.MSHTML.MSHTML object at 0x0214B310>
Traceback (most recent call last):
File "virtualBuffers__init
_.pyc", line 1041, in replayFocusEnteredEvents
File "NVDAObjects__init
_.pyc", line 766, in event_focusEntered
File "baseObject.pyc", line 34, in get
File "baseObject.pyc", line 110, in getPropertyViaCache
File "NVDAObjects\IAccessible__init
_.pyc", line 1263, in get_isPresentableFocusAncestor
File "baseObject.pyc", line 34, in get
File "baseObject.pyc", line 110, in getPropertyViaCache
File "NVDAObjects__init
.pyc", line 701, in get_isPresentableFocusAncestor
File "baseObject.pyc", line 34, in get
File "baseObject.pyc", line 110, in getPropertyViaCache
File "NVDAObjects\IAccessible\MSHTML.pyc", line 438, in get_presentationType
File "virtualBuffers__init
.pyc", line 617, in isNVDAObjectPartOfLayoutTable
File "virtualBuffers__init
_.pyc", line 612, in makeTextInfo
File "virtualBuffers__init__.pyc", line 105, in init
File "textInfos\offsets.pyc", line 266, in init
TypeError: 'NoneType' object is not iterable
IO - speech.speak (17:18:46):
Speaking ('en_UK'), u'Kennitala: edit'
IO - speech.speak (17:18:46):
Speaking ('en_UK'), u'blank'
DEBUG - appModuleHandler.update (17:18:52):
application iexplore closed
IO - inputCore.InputManager.executeGesture (17:18:53):
Input: kb(desktop):control+alt+r
So, the actual issue seems to exist in ff3.6, IE8 and 9 and is more serious inIE8 in XP.

I used a current snapshot for the above tests.

Changed title from "NVDA with IE9 does not recognize edit field inside a table." to "NVDA with IE9 does not recognize edit field inside a table. (Also affected FF3.6 and IE 8 under XP)"

Comment 2 by briang1 on 2012-02-09 18:44
Could this page be detecting some users not in Iceland perhaps? Using Webbie I do not see the edit fields, only the javascript output for the error on both fields.
Invalid value

Its not very friendly nonetheless!

Comment 3 by Wildebrew on 2012-02-09 20:53
I can further confirm that this works with with NVDA 2011.3 with FF7 and FF10. Have not tried it with Webbie.
I see no difference between using the place inside or outside of Iceland (I am currently in North Carolina).
The page is created using a tool called DevExpress, and, yes, there is a lot of Javascripting going on (this being but one problem with the page, but others are more of a design issue).
As DevExpress is fairly widely used by developers, I believe it likely that other pages will have a similar look and feel to them, so the problem does not appear to be completely unique to this particular page.
This works fine with Jaws 13 and FF7 and FF10 and IE9, so the problem seems to be unique to NVDA with IE8 and IE9 .. perhaps the issue is IE's handling of Javascript rather than the table surrounding the input fields. I am just not enough of an expert to be able to say for sure, though I'd be happy to investigate further.

Comment 4 by jteh on 2012-02-09 22:26
The problem here isn't related to layout tables. The table is marked with a style of "visibility: hidden", but the table cells are marked with a style of "visibility: visible". I have no idea why they've done this, but it seems to be valid. The problem is that for IE, NVDA skips the entire element (including its descendants) if it sees visibility: hidden.

I'm not sure why this would affect Firefox 3.6, but I'm going to ignore this for the moment unless anyone desperately wants it fixed, in which case we'll file a separate ticket. Hopefully, we can start recommending users move away from Firefox 3.6 some day soon, at which point it'll be irrelevant.
Changed title from "NVDA with IE9 does not recognize edit field inside a table. (Also affected FF3.6 and IE 8 under XP)" to "NVDA with IE doesn't render visible descendants of hidden elements"

Comment 6 by jteh on 2012-02-09 22:30
Test case:

<div style="visibility: hidden">
<p style="visibility: visible">Visible text</p>

The line above this should say "Visible text". If it doesn't, you're seeing the bug.

Comment 7 by jteh on 2012-02-09 22:59
For reference, here's the relevant section on visibility: hidden from the CSS spec:
The generated box is invisible (fully transparent, nothing is drawn), but still affects layout. Furthermore, descendants of the element will be visible if they have 'visibility: visible'.
Btw, we need to treat visibility: collapse the same way.
Milestone changed from None to near-term

Comment 8 by briang1 on 2012-02-10 05:25
In the case of IE your test code leaves a line blank, but in FF3.6, the line seems to be missing altogether.

Comment 9 by mdcurran on 2012-10-09 23:57
Fixed in 079b8b4.
Milestone changed from near-term to 2012.3
State: closed

@nvaccessAuto nvaccessAuto added this to the 2012.3 milestone Nov 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment