After scrolling to the beginning of the document, the sequential focus navigation starting point should be unset.

[simevidas]

Spec link: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier

After step 2, sub-step 2, there should be sub-step 3 that says “Unset the sequential focus navigation starting point”.

This is needed because after scrolling to the top of the document, pressing Tab should focus the first element in the document.

Test page: https://output.jsbin.com/qayocuz/quiet

Related Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1794478

[domenic]

This isn't what I am seeing, testing in Firefox on Linux. There, if I press tab after clicking the link, "Last focusable element on the page" gets focused.

[simevidas]

Yes, that’s what browsers are currently doing. Sorry if I wasn’t clear.

The current behavior is not good because the “scroll to top” link is a bad experience for keyboard users. They activate the link, and the page scrolls to the top, but if they then press Tab, the page scrolls back to the element after the link at the bottom of the page.

If the page scrolls to the top, then the sequential focus navigation starting point should also move to the top, which, if I understand correctly, can be achieved by unsetting it, so it starts from the top again.

So I’m suggesting that the spec changes to improve the experience for keyboard users, and then browsers can implement this change.

[domenic]

I see. I think user research would be needed to see if the majority of keyboard users agree with your assessment. For example, myself as a keyboard user, prefer that the sequential focus navigation point not be moved in this scenario, so that I don't lose my place in the document.

[zcorpan]

@domenic do you expect that also when navigating to URL fragment that's not # (or #top)? Isn't your place in the document where you navigated to?

cc @whatwg/a11y

[patrickhlauke]

I think (unless I misunderstand the meaning of step 1 https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier) that both for step 1 and step 2 it would make sense to say that the sequential navigation starting point should be unset, so that you're effectively bounced back to the start of the document both visually, and in terms of focus sequence. This would make the keyboard experience much more controlled and consistent (compared to the current experience, where yes visually you're bounced to the top, but a subsequent Tab jumps you all the way back to where you originally were).

[zcorpan]

I don't think it should be unset for step 1. Pages might use fragments for client side navigation or storage.

[patrickhlauke]

I don't think it should be unset for step 1. Pages might use fragments for client side navigation or storage.

then they should also preventDefault / cancel the event though to suppress both a visual scrolling behaviour and then the resetting of the sequential navigation starting point, no? (i.e. if they're using it in a non-standard way / hooking into it for other JS-based functionality)

[zcorpan]

No, the point is to update the URL, but since there's no matching element there is no scrolling anywhere, and similarly we shouldn't change the sequential navigation starting point.

[patrickhlauke]

@zcorpan aha, thanks for clarifying ... so indeed

unless I misunderstand the meaning of step 1

from my comment applies :)

In which case yes, for clarity, I agree that for step 2 (but not for step 1 like I originally said)

would make sense to say that the sequential navigation starting point should be unset, so that you're effectively bounced back to the start of the document both visually, and in terms of focus sequence. This would make the keyboard experience much more controlled and consistent (compared to the current experience, where yes visually you're bounced to the top, but a subsequent Tab jumps you all the way back to where you originally were).

[estelle]

If a user clicks on any other document fragment, the document scrolls to that identifier and runs the focusing steps for the target (with the document as the fallback target). Not updating the focus to the top of the document in this one case seems like an exception.

As a developer, my understanding is that it is as if there is an imaginary id in the <body> of "top", case insensitive. I would expect it to behave as if the HTML read <body id="TOp"> and I had clicked on a link reading <a href="#TOp">Top</a>