Most sites fail keyboard navigation not because the developers didn’t care, but because nobody ever tested with a keyboard. The tab key is tedious to use in QA, but it is the primary input device for a significant portion of users. Getting this right is a design problem as much as a development one.
Why Focus Order Is a Design Decision
Focus order follows DOM order by default. That sounds safe until you discover your DOM was written in the wrong sequence for mobile-first layout, or that CSS grid reordered things visually without touching the source. A user tabbing through the page suddenly skips the navigation, lands mid-form, then backtracks into a footer link.
The visual reading order and the keyboard focus order have to match. When they diverge, the interface becomes disorienting for anyone relying on a keyboard. This includes users with motor disabilities, power users who prefer to keep their hands off the mouse, and anyone navigating from an external keyboard on a tablet.
Keyboard navigation is not a feature you add after design. It is a constraint that shapes the design from the start.
DOM Order Over tabindex
The instinct when fixing focus order is to reach for tabindex. Setting tabindex="2", tabindex="3", and so on feels like a direct fix. It usually makes things worse.
Positive tabindex values create a secondary focus sequence that runs before the natural DOM order. Any element with tabindex="1" gets focus before every element with tabindex="0", regardless of where it sits in the document. The result is a sequence that is nearly impossible to reason about as the page grows.
The better approach: reorganise the DOM. If the visual order is wrong, the layout order is wrong. Fix it in markup, or use the CSS order property inside a flex or grid context to reconcile the two. Reserve tabindex="0" for making non-interactive elements focusable when genuinely needed, and tabindex="-1" for elements that should receive programmatic focus via JavaScript without entering the natural tab sequence.
Focus Indicators: Visible Means Visible
The default browser focus ring gets removed early in many projects, usually because it clashes with a design. This is a genuine usability regression, not a styling preference.
WCAG 2.2 requires that focus indicators achieve a contrast ratio of at least 3:1 against adjacent colours. The Level AA criterion for Focus Appearance goes further: the indicator must be at least 2px thick and enclose the component’s bounding box. Removing the outline entirely fails both requirements.
Custom focus styles are fine. A coloured box-shadow, a thick border, a background shift: all acceptable. The standard is that the focused element must be unmistakably distinguishable. If someone looking at a screenshot cannot immediately spot which element is focused, the indicator is not working.
One specific mistake worth avoiding: styling :focus instead of :focus-visible. The :focus pseudo-class applies to every input method, including mouse clicks, which makes buttons and links look unexpectedly highlighted after a click. :focus-visible applies only when the browser determines that a visible indicator is appropriate, which is the behaviour you almost always want.
What Belongs in the Tab Sequence
Not every interactive element should be reachable via tab. The tab sequence is for actionable items: links, buttons, form fields, and interactive widgets. Decorative elements, static text, and non-actionable containers should be excluded.
This matters most for complex components. A dropdown, a date picker, a data table: each should behave as a single stop in the tab order, then allow arrow keys to move within it. This is the ARIA authoring practices model for composite widgets. The benefit is that keyboard users do not have to tab through forty calendar days to move past a date input.
Custom interactive components need explicit roles and states. A <div> styled as a button has no keyboard accessibility without role="button", tabindex="0", and key event handlers for Enter and Space. The native <button> element provides all of this without any additional work. Use native HTML before reaching for ARIA.
Skip Links and Landmark Regions
Every page with a navigation block before the main content should have a skip link. This is a link, typically the first element in the document, that moves focus directly to the main content. Without one, keyboard users must tab through the entire navigation on every page load.
The standard implementation hides the skip link visually until it receives focus, using position: absolute with a transform or negative offset, then revealing it on :focus. Hiding it with display: none or visibility: hidden removes it from the focus order entirely and defeats the purpose.
Landmark regions work at a structural level. The <header>, <nav>, <main>, and <footer> elements, or their ARIA landmark equivalents, give screen reader users a way to jump between sections without listening to the whole page. Correct landmark use is low effort and carries meaningful benefit for assistive technology users.
Modal Dialogs and Focus Trapping
Modals are where keyboard navigation most often breaks in practice. When a dialog opens, focus must move into it. While the dialog is open, focus must stay inside it. When it closes, focus must return to the element that triggered it.
Failing any one of these makes the modal inaccessible. A user who tabs past the close button and out of the dialog has lost their position. A user whose focus returns to the page top rather than the trigger has to navigate from the start.
The focus trap is not about restricting users. It is about maintaining orientation. The inert attribute, now broadly supported across browsers, is the cleanest approach: set inert on everything outside the open modal, and the browser handles the rest.
Testing With a Keyboard
The only reliable way to verify keyboard navigation is to test with a keyboard. Automated tools catch some categories of issue, including missing focus indicators and interactive elements unreachable by tab. They do not catch focus order problems, trap failures, or confusing sequences.
The manual test is straightforward: disconnect the mouse, tab through the page, and note every point where you lose your place or cannot complete a task. Web accessibility testing goes deeper into this, covering where automated scans and manual methods overlap and where they diverge.
For touchscreen contexts, the parallel concern is target size and spacing. Touch target design deals with the same principle applied to a different input method: both are constraints the design needs to resolve before build, not after.
How Strynal Approaches Keyboard Navigation
At Strynal, keyboard navigation is part of the UI/UX design process from the outset. Focus order is specified during the design handoff, not identified as a defect during QA. Custom interactive components get their keyboard behaviour defined alongside their visual states, so there are no surprises at the build stage.
This connects to a position we hold more broadly on accessibility as a design practice: most accessibility failures are design failures, and the lowest-cost time to address them is before anything is built.
If your product has keyboard navigation gaps, the fixes are usually precise and achievable once they are mapped. Get in touch and we can help identify where the problems are and how to close them.