Keyboard navigation on a landing page: visible focus, tab order, and traps to avoid

The mouse disappears the moment you test a landing page by tabbing through it: each press of Tab moves focus from one interactive element to the next, in the order they appear in the DOM, with nothing else telling you where you are. This mode of navigation isn't a niche accessibility concern — it covers people with motor impairments who can't use a mouse, screen reader users who move through pages almost entirely by keyboard, and a fair share of power users who fill out a form faster by tabbing than by clicking. On a page built to convert in a few seconds, invisible focus or an inconsistent tab order quietly loses part of that audience before they ever reach the form.

What the research says about keyboard navigation

Shari Trewin and Helen Pain, in "Keyboard and mouse errors due to motor disabilities," published in 1999 in the International Journal of Human-Computer Studies (available on Google Scholar), document the typing and targeting errors users with motor impairments encounter when an interface assumes precise mouse control — a finding that directly justifies why the keyboard needs to remain a fully functional path through a page, not a bare-minimum fallback. Jonathan Lazar, Aaron Allen, Jason Kleinman, and Chris Malarkey, in "What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users," published in 2007 in the International Journal of Human-Computer Interaction (available on Google Scholar), show that poorly labeled forms and unpredictable focus behavior rank among the top sources of frustration reported by the study's 100 blind participants — and since a screen reader is piloted almost entirely by keyboard, that finding connects directly to how focus behaves on a page.

Visible focus: the non-negotiable baseline

WCAG success criterion 2.4.7 (Focus Visible) requires that at any given moment, whichever element holds keyboard focus be visually identifiable, with a contrast ratio of at least 3:1 against its surroundings. In practice, the most common — and most damaging — habit is a blanket outline: none; applied to "clean up" the look of buttons and fields, with nothing put in its place: focus still moves normally, but becomes invisible to anyone who can't rely on a mouse. The :focus-visible pseudo-class solves this without any visual trade-off, since it only shows the indicator when navigation is actually happening by keyboard:

button:focus-visible,
a:focus-visible,
input:focus-visible {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

In Tailwind, the same result takes one utility class — focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-blue-600 — applied to every interactive button, link, and field in the template. A mouse click never triggers this state; only tabbing does, which removes the usual objection that it "looks off" on click.

Tab order: the DOM, not the CSS

Focus follows the order of elements in the DOM, not their visual position on screen. CSS positioning (grid-column, order, absolute positioning) that visually rearranges a section without touching the underlying markup produces a tab sequence that jumps around the page in an order nothing on screen explains. On a landing page, this mismatch shows up most often in two-column layouts (visual on the left, form on the right on desktop, stacked on mobile): if the DOM places the form before the visual for mobile layout reasons, a keyboard user on desktop reaches the form before ever seeing the copy that visually precedes it. The most reliable rule is to make DOM order match the expected visual reading order, and to reserve tabindex for two specific uses: tabindex="0" to make a non-native element focusable (a clickable card built as a <div>, for instance, something a native <button> or <a> already handles), and tabindex="-1" for programmatic focus (moving focus to an error message after a form submission). A positive value (tabindex="1", "2"…) short-circuits the document's natural order and quickly becomes unmaintainable as the page evolves.

The focus trap inside a modal

Signup popups, confirmation modals, and email-capture overlays are common on landing pages — and this is exactly where keyboard navigation fails most often. An accessible modal needs three behaviors: on open, focus moves inside the modal (typically to its first interactive element or its heading); while it's open, tabbing stays trapped inside it — Tab from the last element wraps to the first, Shift+Tab from the first wraps to the last — never reaching the content hidden behind the overlay; on close (via a button, the Escape key, or a click outside the modal), focus returns precisely to the element that opened it, not to the top of the page. Without that trap, tabbing simply keeps moving through the elements hidden behind the overlay — a keyboard user can end up filling out an invisible field with no visual feedback, or worse, believe the modal has closed when it's still covering the screen.

Implementing the focus trap in React

Rather than hand-rolling this behavior, the native HTML <dialog> element handles focus trapping and closing on Escape natively in modern browsers, and is the simplest base for an email-capture modal. For a richer component (multiple steps, validation), a component library dedicated to accessibility — Radix UI or React Aria, for example — already implements this behavior tested across major screen readers, avoiding a home-grown focus trap that tends to regress with every layout change.

Common mistakes to fix first

• outline: none; with no replacement — removes visible focus for everyone rather than styling it; :focus-visible lets you customize the indicator without ever removing it entirely.
• A modal with no focus trap — tabbing keeps moving behind the overlay, making the page unusable by keyboard while the popup is open.
• Focus that doesn't return after closing — closing a modal without moving focus back to the trigger element forces the user to retab from the top of the page to find their place again.
• A sticky mobile banner or CTA inserted out of order — a fixed element added late in the DOM can end up outside the logical tab order relative to the content it visually overlaps.
• A focusable honeypot field — an invisible field meant to catch bots needs to be pulled out of the tab order (tabindex="-1" and aria-hidden="true"), otherwise a keyboard user lands on it with no idea what it is.

The fastest test remains manual: open the landing page, stop touching the mouse, and move through the entire page with Tab and Shift+Tab, watching where focus lands at each press. Across the ten LanderKit React/Next.js templates, this test takes under two minutes and immediately surfaces the three most common issues — especially useful on templates that open a capture popup, like SaaS Waitlist or Webinar & Masterclass. This topic builds on our broader article about landing page accessibility (RGAA/WCAG), and connects to the contrast questions already covered for CTA buttons and color blindness: visible focus also depends on sufficient contrast, not just on being present.