[css-nav-1] Consider candidates revealed after one scroll step?

[hugoholgersson]

When finding the candidate set, Chrome's spatnav includes focusables that would become visible after one (document*) scroll step in the navigated direction.

* We don't do this for scrollable divs but I consider that a bug. I believe spatnav should treat both document scrolling and element scrolling in the same way.

This behavior is not spec'ed. Should we?

Downsides:

• Trickier implementation.

Upsides:

• Better UX.

1. One keystroke instead of two: [scroll + focus] instead of [scroll] + [focus].
2. Focused element (and its "focus ring", if enabled) is always visible (it cannot be scrolled out).

[jihyerish]

In the current spec, one arrow key pressing works for scrolling or moving focus.
That description is in Example 1 of Overview section.

I agree that one keystroke works for [scroll] + [focus] may be better UX, but it depends on the situation.
Do you think that this behavior is better for spatial navigation?

[hugoholgersson]

I think [scroll + focus] is better for users, yes :) I also think scrolling should be consistent; element scrolling (such as div scrolls) shouldn't be different from body scrolls. It is now in Chrome.

In current Chrome, when spatnav scrolls body, spatnav can [scroll + focus], but spatnav cannot when it scrolls an element.

[frivoal]

If the focusable element entirely fits within the area that would be revealed by the scrool, then this makes sense to me.

I am less sure when only part of it would be visible, because focusing it would in turn cause a bigger scroll, possibly in some rare cases causing the scroll to be so large that some content that is between the previous focused element and the new one is skipped and unreachable.

[hugoholgersson]

snav-stay-in-overflow-div.html shows that sequential navigation, at least in Chrome and Firefox, also does [scroll + focus], when a focusable is entirely revealed by the scroll step.

I am less sure when only part of it would be visible ...

What does sequential navigation do in this case?

[frivoal]

sequential navigation always just focuses things, which can, as a side effect when the thing is hidden, cause scrolling to make it visible. It never does scrolling only, so the question doesn't really arise.

[hugoholgersson]

If spatnav does element.scrollIntoView(alignToTop=true), we're safe?

[frivoal]

I don't think so. take this case, for example:
http://jsbin.com/xuxesazilu/edit?html,css,output

If you have the first button focused and you're at the top of the scroller, you cannot read the whole text. If you scroll one step down, you reveal the reminder of the text, and the top of the second large button.

If a second step focuses the big button, no problem.

But if the first step immediately focused that big button and brought it into view, then part of the text would be skipped, and never readable to the user.

[hugoholgersson]

But if the first step immediately focused that big button and brought it into view, then part of the text would be skipped, and never readable to the user.

I agree. That's a problem of seqnav...

With spatnav however, can that happen given we do scrolling in line-height:ish big steps?

If it actually can happen... let's make the focus of [scroll + focus] a "non-scrolling focus"?

[frivoal]

With spatnav however, can that happen given we do scrolling in line-height:ish big steps?

It currently cannot, since spatnav will not focus something that was out of the screen before scrolling.

If something was not visible before scrolling, and is fully visible after scrolling, then we could change the spec to focus it, and we would not lose the benefit.

But if we focus partially visible things, then we get that problem.

[hugoholgersson]

But not with partially_visible_element_after_scroll.focus({preventScroll:true}) ... right?