Comment 1 by jteh on 2011-01-04 20:44
In future, please add a comment to the existing ticket (in this case, #1295). There is an option to reopen the ticket if the problem still exists and you believe it was closed incorrectly.

These seemingly missing links are dropdown menus which only appear when you move the mouse over the About link. In NVDA, you can do this by using the Move mouse to current navigator object command (NVDA+numpadDivide on a desktop keyboard) while on the About link. This definitely works for me in Firefox.

It also works in IE. However, NVDA doesn't see the new links until you refresh the buffer with NVDA+f5. This last problem is not ideal and needs to be fixed if possible. Leaving this open to investigate.
Changes:
Changed title from "links to subpages don't read" to "Some mouse over dropdown menus not updating the buffer in IE"
Milestone changed from None to near-term

Comment 2 by abletec on 2011-01-04 21:10
1st, James, even if it works in firefox, the person would need to know to use the command, e.g., they'd need to know the menu had those properties or they simply wouldn't use it. U knew the links were there because I told u, but if u didn't, u probably would not have used the numpad divide. 2nd, for those of us not using a desktop, is there an equivalent key for the laptop layout?

The only reason I reported this, frankly, is because I wonder how much information we're missing simply because there are folks creating websites out there w/these types of menus, happily thinking all is well, but blind people aren't able to access all the information &, in addition, they are likely blissfully unaware of the fact. If u don't know something's out there hiding, you're not going to go look for it.

Comment 3 by jteh (in reply to comment 2) on 2011-01-04 21:20
Replying to abletec:

1st, James, even if it works in firefox, the person would need to know to use the command, e.g., they'd need to know the menu had those properties or they simply wouldn't use it.

Nor does a sighted person until they mouse over it, so the situation is the same. I agree this isn't ideal, but that isn't NVDA's fault. That is an issue you should take up with the site/software developer. There are ways to make this more accessible such as using ARIA.

U knew the links were there because I told u, but if u didn't, u probably would not have used the numpad divide.

Perhaps, although I personally tend to check for this sort of thing when I suspect I'm missing something. Granted, I'm a very experienced web user and most users may not think to do this.

2nd, for those of us not using a desktop, is there an equivalent key for the laptop layout?

Yes. It is NVDA+shift+f9, as documented in both the User Guide and the Keyboard Command Quick Reference.

The only reason I reported this, frankly, is because I wonder how much information we're missing simply because there are folks creating websites out there w/these types of menus, happily thinking all is well, but blind people aren't able to access all the information &, in addition, they are likely blissfully unaware of the fact. If u don't know something's out there hiding, you're not going to go look for it.

Right, but again, this isn't NVDA's fault. There are limits to what we can and should do to work around sites with accessibility problems. Site/software developers need to take some responsibility in this too.

Comment 4 by parham (in reply to comment description) on 2011-01-05 07:50
I have an idea, but I'm certain this has already occurred to developers, so this comment is more of a "why not?" thing. You see, while navigating over an element, it could be checked for the onMouseOver attribute. If there is one, it could be reported. This would mean that upon going to the about link, you'd hear something like "about (has onMouseOver)" or something alike.

Comment 5 by jteh (in reply to comment 4) on 2011-01-05 22:43
Replying to parham:

while navigating over an element, it could be checked for the onMouseOver attribute. If there is one, it could be reported.

There are several reasons against this:

• technical: Firefox doesn't expose the onMouseOver attribute via accessibility APIs, which means we can't access it.
• practical: These days, I suspect a lot of nodes set the onMouseOver attribute to do various things, not all of them necessarily updating document content. This means you'd hear onMouseOver in a lot of cases where it isn't useful at all, thus creating unnecessary verbosity and potentially making it more of a hindrance than a help.
• principle: No other user knows that there is an onMouseOver unless they move the mouse over the node. I don't see why screen reader users should be any different.

Comment 6 by abletec on 2011-01-05 23:09
James, u wrote:
 * principle: No other user knows that there is an onMouseOver unless they
 move the mouse over the node. I don't see why screen reader users should
 be any different.

Well, in this case, that's not true. My business partner has some eyesight & she could see that the subpages were there & could click on them, though they weren't being read by either Jaws or NVDA. So it's not actually a mouse-over in the sense that you're thinking of a mouse-over. I know what you're describing, but this is different.

Comment 7 by parham (in reply to comment 5) on 2011-01-06 05:42
Replying to jteh:

There are several reasons against this:

• technical: Firefox doesn't expose the onMouseOver attribute via accessibility APIs, which means we can't access it.

Oh, that's quite unfortunate.

• practical: These days, I suspect a lot of nodes set the onMouseOver attribute to do various things, not all of them necessarily updating document content. This means you'd hear onMouseOver in a lot of cases where it isn't useful at all, thus creating unnecessary verbosity and potentially making it more of a hindrance than a help.

True point.

• principle: No other user knows that there is an onMouseOver unless they move the mouse over the node. I don't see why screen reader users should be any different.

The sighted do not know of an OnMouseOver event, but most of the time they unknowingly draw the mouse over the item. This is also, as I hear, shown to the user using different methods (a down pointing triangle, a different colour, etc). I have never heard of a sighted person (who might just have started using the Internet) complain about links that appear when you move the mouse over an item. It has to be reported to the user somehow, because even drawing the mouse over a whole page to see if any hidden items suddenly pop up is not practical, even for the sighted.

Comment 8 by jteh (in reply to comment 7) on 2011-01-06 05:54
Replying to parham:

The sighted do not know of an OnMouseOver event, but most of the time they unknowingly draw the mouse over the item. This is also, as I hear, shown to the user using different methods (a down pointing triangle, a different colour, etc).

Right, so this needs to be made accessible to screen reader users somehow. The point is that reporting the presence of an onMouseOver event is not the right solution to do this. For one, it causes the practical problem I described.

Comment 9 by parham (in reply to comment 8) on 2011-01-06 07:17
Replying to jteh:

Right, so this needs to be made accessible to screen reader users somehow. The point is that reporting the presence of an onMouseOver event is not the right solution to do this. For one, it causes the practical problem I described.

Yes, you are right. I think then, the best way to go about this is to analyse pages that have this behaviour. Maybe users could compile a list of websites that they come across, and then after looking at those websites, the NVDA developers could decide how to go about this. The reason I suggested the OnMouseOver event is because there are infinite ways of reporting this to a sighted user, such as using an image, using CSS, using alignment, using background/foreground colour, using font types, using icons, and many other ways. NVDA can't take all of these into account, and needs to go to the very core, where all of these would be implemented the same way; through OnMouseOver and Javascript. Another thing that just occurred to me at this instant is reporting only a few elements that are suspected of making the DOM (I.E. HTML document). I am not certain if this is possible though, or how practical it is. Just something to think about.

Comment 10 by mdcurran on 2012-10-10 03:24
This web address no longer seems to work for me. If this is true, can another address to a page that shows the same issue be provided?
Changes:
Milestone changed from near-term to None

As @michaelDCurran said, this web address no longer seems to work for me. Can another address to a page that shows the same issue be provided if there is one?

closing as this is something which a developer coded wrong.