Visual issues in browse mode

LeonarddeR commented 8 years ago

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.

LeonarddeR commented 7 years ago

It seems that one of the inconsistencies is caused by how the scrollIntoView method is implemented:

For MSHTML, scrollInToView is called on the HTML Node. This, by default,places the object at the top of the screen.
For IAccessible 2: the [scrollTo](https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/IAccessible2#scrollTo()) method is used. We now use IA2_SCROLL_TYPE_ANYWHERE. It seems that IA2_SCROLL_TYPE_TOP_EDGE gives results similar to IE.
For Adobe Acrobat: IPDDomElement.ScrollTo is used, but the documentation doesn't tell us whether it has preference for top or bottom.

I think it would be good if we choose similar behaviour for those three. So, either place the object at the top or the bottom of the window.

@Qchristensen and @feerrenrut. What is your opinion about this behaviour?

jcsteh commented 7 years ago

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.

I'd argue that focus and scrolling are not related even for sighted people. When a sighted user scrolls the screen, they do not move the focus. The only reason NVDA moves the focus when you move the cursor to a focusable element is so that keyboard commands which operate on the focus (control+enter, applications key, etc.) work as expected.

I also don't think this will give desired results in many cases. This might seem to make sense when the nearest focusable element is only a few lines away, but it's entirely possible that it's several screens away.

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.

This might be true for quick navigation. However, always scrolling to the top is not appropriate in all cases. If we always scroll the element under the cursor to the top, this will make moving by line constantly scroll the screen. As I understand it, this isn't what happens in, for example, a text editor; the screen only scrolls when you reach (or approach) the bottom of the current screen of content.

Qchristensen commented 7 years ago

Scrolling certainly seems inconsistent across browsers So, trying current browsers: Chrome: When jumping to an element that is off screen, scrolls so that the element is just below the middle of the screen.

Firefox: When jumping to an element that is off screen, scrolls so that the element is on the bottom line of the screen.

Internet Explorer: When jumping to an element that is off screen, scrolls so that the element is in the top visible line on the screen.

Edge: Doesn't scroll when jumping to an element that is off screen.

Re how to scroll when reading, I would suggest if something is on screen, don't scroll, only scroll if moving to something (either the next line down or the next element of a particular kind) is off screen. In that case, if the behaviour was to scroll the element to the top of the screen, then pressing down arrow to move through text would essentially move through one screen, then scroll one screen, then move through that screen, then scroll, which should work (from a user perspective) quite well. If the screen was only scrolled to bring the element to the bottom line of the screen, then this would be in line with what happens in say, Word or a text editor when down arrowing through text.

LeonarddeR commented 7 years ago

@Qchristensen commented on 19 jul. 2017 10:43 CEST:

Chrome: When jumping to an element that is off screen, scrolls so that the element is just below the middle of the screen.

Firefox: When jumping to an element that is off screen, scrolls so that the element is on the bottom line of the screen.

Hmm, that suggests that Firefox and Chrome treat IAccessibleHandler.IA2_SCROLL_TYPE_ANYWHERE differently, so it should be considered to change that to be consistent.

Edge: Doesn't scroll when jumping to an element that is off screen.

Hmm, it seems scrolling isn't implemented for UIA at all. @MichaelDCurran, any idea why not? See this MSDN article which might be of use

Adriani90 commented 5 years ago

@mltony I think part of this issue could be solved in your PR. Maybe you have time to consider this one in your implementation. But for this, I guess we should really make fast browse and traditional browse mode optional and explain it in the user guide. A checkbox in the browse mode settings is maybe also needed, in case we need both browse mode methods (i.e. in case magnification is used).

mltony commented 5 years ago

@Adriani90, My PR doesn't touch scrollIntoView() call. It only changes when .setFocus() function is called - instead of on every keystroke, it is now only called right before Enter or similar keystroke. I think taht fast browse mode may only make visual appearance worse, since system focus will no longer be updated on every keystroke. That's the tradeoff. Also, there is already a checkbox for fast browse mode in the preferences.

LeonarddeR commented 5 years ago

I'm taking the scrollIntoView part as part of #7075, trying to make it consistent across Edge, Chrome and Firefox. I"m afraid Internet Explorer will always be the exceptional case here.

jcsteh commented 5 years ago

I'm really struggling to follow this, as I don't really understand how scrolling ought to work to feel natural. However, there's a discussion about changing the Firefox behaviour for a11y API scrolling: https://bugzilla.mozilla.org/show_bug.cgi?id=1572680 This might be worth considering here. In short, there are top/bottom banners on some sites that can obscure anything scrolled underneath them and the browser doesn't necessarily know what these are or how far it needs to scroll so the target isn't obscured. Scrolling to top/bottom might cause problems here, so there's discussion about whether we should be scrolling to centre.

LeonarddeR commented 5 years ago

I assume this would only have impact on the behavior of IA2_SCROLL_TYPE_ANYWHERE, which we now use. We also have explicit scrolling constants.

As for navigating in browse mode, I think it makes sense if:

The scrolling behaviour is as uniform as possible across browsers
Is somehow similar to the scrolling behaviour in a word processor

XLTechie commented 3 weeks ago

@LeonarddeR, @Qchristensen what is the status of this in 2024?

nvaccess / nvda