Reported by hhillen on 2015-07-29 07:09
Normally, if a link or other focusable element is focused and the down arrow key is pressed, NVDA will start reading the next line from the link's location using browse mode. However, if the focused element is inside a scrollable container, pressing the down arrow key will cause keyboard focus to reset to the container itself. The user loses their position and will have to navigate back to where they were inside the scrollable container.
To reproduce, use the test case] provided (also attached). In this test case, "link 1" and "button 1" are placed outside the scrollable container and function as expected. "link 2, 3 and 4" and "button 2" are placed inside a scrollable container. Pressing the down arrow key while one of them is focused will cause focus to be set back on the scrollable container itself.
This only happens in the Firefox / NVDA profile, so please advice whether the solution should be provided by NVDA or by Mozilla.
Reported by hhillen on 2015-07-29 07:09
Normally, if a link or other focusable element is focused and the down arrow key is pressed, NVDA will start reading the next line from the link's location using browse mode. However, if the focused element is inside a scrollable container, pressing the down arrow key will cause keyboard focus to reset to the container itself. The user loses their position and will have to navigate back to where they were inside the scrollable container.
To reproduce, use the test case] provided (also attached). In this test case, "link 1" and "button 1" are placed outside the scrollable container and function as expected. "link 2, 3 and 4" and "button 2" are placed inside a scrollable container. Pressing the down arrow key while one of them is focused will cause focus to be set back on the scrollable container itself.
This only happens in the Firefox / NVDA profile, so please advice whether the solution should be provided by NVDA or by Mozilla.