shepherd-pro
Tab navigation skips highlighted tour elements, breaking keyboard accessibility
Description When using keyboard navigation during a Shepherd.js tour, pressing the Tab key cycles through all page buttons but completely skips the elements that are highlighted/targeted by the current tour step. This breaks the expected keyboard navigation flow and creates accessibility barriers for users who rely on keyboard navigation.
Expected Behaviour
Tab key should include highlighted/targeted tour elements in the normal keyboard navigation flow Users should be able to reach and interact with elements that are visually highlighted by the tour Keyboard navigation should provide the same access as mouse/pointer interaction
Actual Behaviour
Tab key cycles through all standard page buttons and interactive elements
Tab navigation completely bypasses any elements that are highlighted by the active tour step Highlighted elements become unreachable via keyboard, despite being visually prominent
This also doesn't work with buttons rather then fields as the highlighted element.
Steps to Reproduce
Create a Shepherd.js tour with steps that highlight interactive elements (buttons, form fields, links) Start the tour Use only keyboard navigation Press Tab to navigate through the page Observe that highlighted elements are skipped in the tab order
Environment
Shepherd.js version: Main Browser: Chrome Version 137.0.7151.56 (Official Build) (64-bit) Operating System: Windows 10
Theory of Why This Expected Behaviour Isn't Occurring
The whole method is scoped to only within the shepherd elements. I think they'd need to scope to the document, and then within that, scope to the shepherd elements AND the attached to element / additional highlight elements.
I think this feature could be interfering with the expected behavior. https://github.com/shipshapecode/shepherd/pull/408 has disabled focus on all elements not within shepherd element.
@beltsofplenty I believe focus and tabbing is supposed to remain within a dialog element and that you cannot access highlighted areas. e.g., https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/#accessibilityfeatures
I'm also not totally clear the complete use case, like is this to highlight the element that is targeted and have that described in screen readers?
Your cited example is correct for traditional modals modal dialog but shepherd tours do more then that. traditional modals don't: ❌Highlight external page elements ❌Point to buttons outside the dialog ❌Expect users to interact with the underlying page
I think the Success Criterion 2.1.1 Keyboard Principle "Everything can be done with a keyboard except freehand movements. ... Ensure pointer actions have a keyboard equivalent." is the overriding consideration here.
Let me clarify my complete use case here.
Primary use case: Multi-step tours where users need to interact with highlighted elements
Example: "Click this button to continue the tour" Current behaviour: Mouse users can click, keyboard users cannot reach the button This creates an accessibility barrier for keyboard-dependent users.
Your point about screen readers is not something I or anyone else on my team had considered and its equally valid use case.
✅ Screen readers need to discover and announce highlighted elements ✅ Users should be able to explore the relationship between tour content and target elements ✅ Context switching between tour overlay and target elements aids comprehension
