Comment 1 by jteh on 2013-06-06 23:54
Following your steps, I do see focus (and thus the virtual cursor) jump, but it jumps to a StumbleUpon link, not the top of the page. Can you confirm this?

The problematic area is a "More sharing services" link. As soon as this is focused, it automatically expands and throws focus to the StumbleUpon link. Imo, this is pretty bad authoring; setting focus to something shouldn't throw focus to something elsewhere on the page.

There are good reasons we move focus as you move through the page, such as enabling the applications key, control+enter and other commands that operate on the focus to work correctly.

Ideally, this widget needs to be fixed, but we're starting to see more of this sort of craziness happening, so we should discuss possible solutions.

Comment 2 by camlorn on 2013-06-07 03:30
I see that. It seems to jump there, but when arrowing down you somehow end up back at the top. I assumed that it was just going to the top until I just looked at it again, as I always just navigate to the heading for the forecast. Maybe it's adding the stumble upon nodes first in the DOM, and then being helpful and moving the keyboard there?
I think that this falls under the same thing as Aria: people using it incorrectly because they don't know better, and I think that this is one of those generic pieces of code. The kind that'll be popular for the next 2 or 3 years, before fading into obscurity. If I can find another example URL, I'll post it. It may be worth figuring out who originally wrote the code for this particular sharing extension and contacting them, as adding such extensions to web sites is a fairly popular thing to do.
As for an actual workaround, we could go a similar route to jaws--it may not be the best, but it's what I've got at the moment and can at least provide a useful starting point for discussion. Jaws makes mouseover and the like independent of web page focus. To get such functionality, you can either press enter (for things that are on mouseover elements by whatever definition Jaws uses) or press a key which I can't remember for doing mouseover on anything. I've tried this with and without carrot browsing, and am not sure how NVDA interacts with the web site on a low level, but this may end up being a firefox issue: unless I am in focus mode, I would expect all navigation to not be communicated to the web site. This is the first indication I've had--barring carrot browsing--that web sites could tell where NVDA was, so I'm assuming NVDA's moving some sort of focus, but I'm probably wrong. The only solution I can offer is to intercept the "activation" keys, space and enter but maybe others, and only move this imaginary focus then. That has its own set of issues, however

Comment 3 by jteh on 2013-06-07 05:22
StumbleUpon is added near the end of the DOM. However, it looks like the next link after that disappears after a while of having focus, but focus doesn't get moved anywhere else, which causes you to be thrown to the top.

I don't follow the expectation that navigation shouldn't move the focus. Using the cursor keys in any other application does move the visible caret/focus, as does the tab key. In addition, doing as you suggest breaks any key command that depends on the focus. We'd then have to try to intercept every key that depends on the focus in every possible situation. This is what JAWS does, but this solution does cause other problems.

Note that you can review the page without moving the focus by using NVDA's text review commands.

Comment 4 by camlorn on 2013-06-08 23:58
I know the Jaws approach causes problems; I am fully aware of them. I had to deal with them for a very long time before switching to NVDA, and don't really advocate that approach. Still, it's all I've got at the moment.
the specific problem is probably that web authors don't know about screen readers; they assume that the focus being moved is definitely not someone reading and is probably the mouse pointer. If we go by population using screen readers, this is somewhere around 90 to 95% correct. I assume that you know this already. Actually dealing with it is of course complicated, and if something brilliant occurs to me I'll post it.
I shall have to try the NVDA review keys. Unfortunately, this changes how I browse majorly: I typically use ctrl+arrow keys to move by paragraph rather than individual lines, because it provides for a longer time between key presses and an experience that "flows". This is what I did to make the initial report, so I do know it works--I'm not sure how newbie friendly it is, however.
I saw this again today, but am now unable to repeat it no matter what I try, so it was probably just temporary weirdness.
Edit: on another web site, the example page still does it.

Comment 5 by jteh on 2013-06-10 00:39
One possible approach I've been considering is not allowing a focus change to move the browse mode cursor if the focus changed occurred very soon after a browse mode navigation command (cursor keys, quick navigation, etc.). This will also solve #2039. However, this needs to be considered and tested very carefully.

It appears that this example no longer works for me. Does anyone have an updated example to provide?

I had something similar on google groups but thats another issue whic is not reproducible anymore.
I cannot reproduce this issue either. I suggest closing it unless someone reports it again. Then we can reopen it.

Closing as worksforme