Follow-up from the PR #118 review.
Background
components/site/Chrome.tsx handleNavClick intercepts same-page /#section clicks and does history.replaceState + el.scrollIntoView(). Unlike a real anchor navigation, this does not move keyboard / screen-reader focus to (or near) the target section — so after a nav click, tab order and the SR reading position stay at the nav.
This is a pre-existing weakness (the native pre-fix <Link> behavior was already weak here under output: "export"), not a regression introduced by #118. Tracked separately so #118 stays scoped to the hash-accumulation fix.
Suggested change
In the same-page branch of handleNavClick, after the scroll:
el.setAttribute("tabindex", "-1");
el.focus({ preventScroll: true });(preventScroll so it doesn't fight the smooth scrollIntoView.) Apply the same to MobileMenu's anchor path for parity if it has the same gap. Verify with keyboard-only + VoiceOver that focus lands in the target section.
Follow-up from the PR #118 review.
Background
components/site/Chrome.tsxhandleNavClickintercepts same-page/#sectionclicks and doeshistory.replaceState+el.scrollIntoView(). Unlike a real anchor navigation, this does not move keyboard / screen-reader focus to (or near) the target section — so after a nav click, tab order and the SR reading position stay at the nav.This is a pre-existing weakness (the native pre-fix
<Link>behavior was already weak here underoutput: "export"), not a regression introduced by #118. Tracked separately so #118 stays scoped to the hash-accumulation fix.Suggested change
In the same-page branch of
handleNavClick, after the scroll:(
preventScrollso it doesn't fight the smoothscrollIntoView.) Apply the same toMobileMenu's anchor path for parity if it has the same gap. Verify with keyboard-only + VoiceOver that focus lands in the target section.