At @BabbageCom, we noticed that there seem to be some visual issues in browse mode in several browsers. @feerrenrut, you might be interested in this in particular. We use nnvaccess.org for my examples.
Focus changes
As expected, when arrowing down a page in browse mode, the focus is continuously updated to reflect the last selected focusable element. So, when you navigate through heading level 2 news with the arrow keys, the focus is set to the link MORE TESTIMONIALS, since that's the link which received focus last.
However, undesirable behaviour rises when we set the virtual cursor to the top of the page and navigate to the news heading with quick navigation commands (either h or 2). The focus is still set to the NV Access link at the top of the page, so there is no visual focus indication that we scrolled past a bunch of links we skipped due to quick nav. Thus, a person who notices that the ptop link is focused, might expect that pressing tab moves to the second link on the page, and not the link after the heading selected in browse mode.
We'd like to propose that, when using forward quick navigation commands to navigate to an unfocusable element, the focus is moved to the last focusable element above the navigator object (below in the case of backwards navigation). In that case, people with vision at least will have an idea where the NVDA user is on the screen. Furthermore, the visual behaviour of browse mode moving will be identical in both quicknav and arrowing cases.
Inconsistency between browsers
Scrolling behaviour with browse mode differs between browsers and thus is inconsistent. We think we should strive to consistent behaviour whenever possible. We prefer the Internet Explorer approach for bringing the navigator object into view.
Firefox/Chrome
When navigating with tab (browser command), the focus is set properly and the focused element is visible at the very bottom of the page. When we use tab to navigate to the first news link, jump back to the news heading with shift+h and than down arrow back to the news link, the visual result is equal. When we navigate the page by heading, the heading is always one of the last visible elements on the screen, making it quite unusable for sighted users who follow the nnon-visual person's actions. Normal behaviour would be that one reads the text below a heading after selecting the desired heading, but the text below the heading is invisible for the most part.
Internet Explorer
When navigating with tab, the focus is set properly and the focused element is visible at the bottom of the page. However, when we use tab to navigate to the first news link, jump back to the news heading with shift+h and than down arrow back to the news link, the visual result differs entirely. The particular link is visible at the top of the page. When we navigate the page by heading, the heading is always one of the first visible elements on the screen, which is quite nice and desirable behaviour from a visual person's perspective. However, it is inconsistent with the browser's behaviour.
At @BabbageCom, we noticed that there seem to be some visual issues in browse mode in several browsers. @feerrenrut, you might be interested in this in particular. We use nnvaccess.org for my examples.
Focus changes
As expected, when arrowing down a page in browse mode, the focus is continuously updated to reflect the last selected focusable element. So, when you navigate through heading level 2 news with the arrow keys, the focus is set to the link MORE TESTIMONIALS, since that's the link which received focus last.
However, undesirable behaviour rises when we set the virtual cursor to the top of the page and navigate to the news heading with quick navigation commands (either h or 2). The focus is still set to the NV Access link at the top of the page, so there is no visual focus indication that we scrolled past a bunch of links we skipped due to quick nav. Thus, a person who notices that the ptop link is focused, might expect that pressing tab moves to the second link on the page, and not the link after the heading selected in browse mode.
We'd like to propose that, when using forward quick navigation commands to navigate to an unfocusable element, the focus is moved to the last focusable element above the navigator object (below in the case of backwards navigation). In that case, people with vision at least will have an idea where the NVDA user is on the screen. Furthermore, the visual behaviour of browse mode moving will be identical in both quicknav and arrowing cases.
Inconsistency between browsers
Scrolling behaviour with browse mode differs between browsers and thus is inconsistent. We think we should strive to consistent behaviour whenever possible. We prefer the Internet Explorer approach for bringing the navigator object into view.
Firefox/Chrome
When navigating with tab (browser command), the focus is set properly and the focused element is visible at the very bottom of the page. When we use tab to navigate to the first news link, jump back to the news heading with shift+h and than down arrow back to the news link, the visual result is equal. When we navigate the page by heading, the heading is always one of the last visible elements on the screen, making it quite unusable for sighted users who follow the nnon-visual person's actions. Normal behaviour would be that one reads the text below a heading after selecting the desired heading, but the text below the heading is invisible for the most part.
Internet Explorer
When navigating with tab, the focus is set properly and the focused element is visible at the bottom of the page. However, when we use tab to navigate to the first news link, jump back to the news heading with shift+h and than down arrow back to the news link, the visual result differs entirely. The particular link is visible at the top of the page. When we navigate the page by heading, the heading is always one of the first visible elements on the screen, which is quite nice and desirable behaviour from a visual person's perspective. However, it is inconsistent with the browser's behaviour.