fix: preserve keyboard focus in sidebar after navigation on desktop#2679
fix: preserve keyboard focus in sidebar after navigation on desktop#2679danielalanbates wants to merge 1 commit intodocsifyjs:developfrom
Conversation
When a keyboard user clicks a sidebar link on desktop, focus was unconditionally moved to the main content area via #focusContent(). This caused keyboard-dependent users to lose track of their position in the sidebar navigation. Now #focusContent() is only called on navigation when: - The URL contains a heading anchor ID (scrolling to a specific section) - The user is on mobile (where the sidebar closes after navigation) On desktop, the sidebar remains open and focus stays on the clicked link, allowing keyboard users to continue navigating without losing their place. Fixes docsifyjs#2600 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
@danielalanbates is attempting to deploy a commit to the Docsify Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
Pull request overview
Adjusts Docsify’s navigation focus management to prevent keyboard focus from being pulled out of the sidebar after activating sidebar links on desktop (issue #2600), while still focusing content for anchor (?id=...) navigations and (intended) mobile navigations where the sidebar closes.
Changes:
- Update
onNavigate()focus behavior to only call#focusContent()on user-initiated navigations when on mobile, or when an anchor id is present. - Add inline comments documenting the desktop sidebar-focus rationale and linking to #2600.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Clicked anchor link or page load with anchor ID | ||
| if (hasId || isNavigate) { | ||
| // On desktop, preserve sidebar focus when navigating via sidebar links | ||
| // so keyboard users don't lose their place (see #2600) | ||
| if (hasId || (isNavigate && isMobile())) { | ||
| this.#focusContent(); |
There was a problem hiding this comment.
Restricting #focusContent() to isMobile() for user-initiated navigations changes behavior for all internal link clicks on desktop, not just sidebar links. source === 'navigate' is emitted by the router for any internal <a> click (including links inside the main content), and the main content DOM is replaced on navigation; if focus isn't moved, the previously focused content link can be removed from the DOM and focus may fall back to <body> (i.e., focus loss). Consider preserving focus only when the active element is within the sidebar (e.g., document.activeElement is contained by .sidebar/.sidebar-nav), while still calling #focusContent() for other desktop navigations.
|
Happy to help test this fix once a PR build is available. Once rc-4, and then hopefully right after v5, is released we can then proceed to further review a few of these recent PRs 🙂 |
Summary
Fixes #2600 — Keyboard focus is lost after activating sidebar links on desktop.
Root cause:
onNavigate()unconditionally called#focusContent()whenever a user clicked a sidebar link, moving focus from the sidebar to the main content area. This caused keyboard-dependent users to lose their position in the navigation.Fix: Only call
#focusContent()after a user-initiated navigation when on mobile (where the sidebar closes). On desktop, the sidebar stays open and focus remains on the clicked link, so keyboard users can continue navigating without losing their place.Focus is still correctly moved to content when:
?id=...)Changes
src/core/event/index.js: Changed the condition inonNavigate()fromhasId || isNavigatetohasId || (isNavigate && isMobile())to preserve sidebar focus on desktop.Testing
isMobile()was already imported and used in the same method for sidebar close logic, so this change is consistent with the existing pattern.Test plan
This PR was created with the assistance of Claude Opus 4.6 by Anthropic. Happy to make any adjustments!