How to Fix Keyboard Navigation Issues: Making Every Page Element Focusable and Operable

Keyboard navigation isn't a niche concern. Approximately 7 million Americans with motor disabilities rely on keyboards, switch devices, or other assistive technologies instead of a mouse. When your website breaks for these users, you're not just losing customers — you're exposed to legal liability. ADA-related web accessibility lawsuits exceeded 4,000 cases in 2023, and keyboard accessibility failures consistently appear in the top five violations cited. If you're wondering how to fix keyboard navigation accessibility on your site, this guide gives you the exact techniques to do it.

Why Keyboard Navigation Breaks (And Where to Look First)

Most keyboard issues fall into four categories:

1. Focus traps — users get stuck inside a component and can't escape
2. Missing focus indicators — users can't see where they are on the page
3. Non-focusable interactive elements — buttons or links built with <div> or <span> instead of semantic HTML
4. Illogical tab order — focus jumps around the page randomly

Before writing a single line of code, open your site and press Tab. Can you reach every link, button, form field, and interactive element? Can you activate them with Enter or Space? If not, you have work to do.

Fix 1: Replace Non-Semantic Elements with Native HTML

The fastest way to break keyboard access is using <div> or <span> for clickable things. These elements aren't focusable by default and have no keyboard behavior. Developers add onclick handlers and forget everything else.

The problem:

<div onclick="submitForm()" class="btn-primary">Submit</div>

This element is invisible to keyboard users and screen readers.

The fix:

<button type="submit" class="btn-primary">Submit</button>

Native <button> elements receive focus automatically, respond to Enter and Space, and communicate their role to assistive technology. Same logic applies to links — use <a href="..."> instead of <div onclick="...">.

If you're inheriting legacy code and can't refactor immediately, the emergency patch is adding tabindex="0" and a keydown handler:

<div 
  role="button" 
  tabindex="0" 
  onclick="submitForm()"
  onkeydown="if(event.key==='Enter'||event.key===' ')submitForm()"
  class="btn-primary">
  Submit
</div>

This works but creates technical debt. Prioritize replacing these with real elements.

Fix 2: Make Focus Indicators Visible

WCAG 2.1 requires that keyboard focus be visible (Success Criterion 2.4.7). Most accessibility lawsuits involving keyboard navigation cite this. Many developers suppress focus outlines with a single CSS rule that breaks everything:

/* This is the problem */
* { outline: none; }
/* Or this */
:focus { outline: 0; }

Delete those rules. Then design a focus indicator that actually works:

:focus-visible {
  outline: 3px solid #005FCC;
  outline-offset: 2px;
  border-radius: 2px;
}

Using :focus-visible instead of :focus ensures the outline shows for keyboard users but not when someone clicks with a mouse — a common aesthetic objection from designers. The color (#005FCC here) must have a 3:1 contrast ratio against the adjacent background color per WCAG 2.2.

Fix 3: Manage Tab Order with tabindex

The natural tab order follows DOM order. If your visual layout differs from your HTML order (common with CSS Grid and Flexbox), users may experience a confusing focus sequence.

Rules for tabindex:
- tabindex="0" — adds element to natural tab order
- tabindex="-1" — removes element from tab order but allows programmatic focus (useful for modals)
- tabindex="1" or higher — forces order, almost always a mistake, avoid it

For a modal dialog that should receive focus when opened:

const modal = document.getElementById('modal');
modal.setAttribute('tabindex', '-1');

function openModal() {
  modal.style.display = 'block';
  modal.focus(); // sends focus programmatically
}

Fix 4: Resolve Focus Traps in Modals and Menus

A focus trap inside a modal is correct behavior — users shouldn't be able to tab outside an open dialog. But focus must also escape when the user presses Escape or activates a close button. A focus trap on the main page is always a bug.

Here's the essential pattern for trapping focus inside a modal correctly:

function trapFocus(element) {
  const focusable = element.querySelectorAll(
    'a[href], button:not([disabled]), textarea, input, select, [tabindex="0"]'
  );
  const first = focusable[0];
  const last = focusable[focusable.length - 1];

  element.addEventListener('keydown', function(e) {
    if (e.key !== 'Tab') return;

    if (e.shiftKey) {
      if (document.activeElement === first) {
        last.focus();
        e.preventDefault();
      }
    } else {
      if (document.activeElement === last) {
        first.focus();
        e.preventDefault();
      }
    }
  });
}

Call trapFocus(modalElement) when the modal opens. When it closes, return focus to the element that triggered it:

const trigger = document.activeElement;
openModal();
// ... on close:
trigger.focus();

Fix 5: Skip Navigation Links

If a user has to tab through your entire header and navigation menu every time they land on a new page, your site is unusable. WCAG 2.4.1 requires a mechanism to skip repeated blocks. A skip link is the standard solution.

Add this as the first element in your <body>:

<a href="#main-content" class="skip-link">Skip to main content</a>

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #005FCC;
  color: white;
  padding: 8px 16px;
  z-index: 9999;
  text-decoration: none;
}

.skip-link:focus {
  top: 0;
}

The link is hidden offscreen until focused, then appears visibly. Your main content area needs a matching id:

<main id="main-content">

How to Test What You've Fixed

After implementing these changes, test with both automated tools and manual keyboard navigation:

Automated Testing

• axe DevTools (browser extension) — catches most missing focus indicators and tabindex issues
• WAVE — good for visualizing focus order
• Lighthouse in Chrome DevTools — gives an accessibility score with specific violations

Manual Testing

Press Tab through every page. Verify:
- You can see focus at all times
- Every interactive element is reachable
- Modals trap and release focus correctly
- Skip links appear and work
- Forms can be submitted with keyboard only

Screen Reader Testing

Use NVDA (free, Windows) or VoiceOver (built into Mac and iOS). If an element sounds wrong or behaves unexpectedly, it's a keyboard issue even if it looked fine visually.

The Legal and Business Case for Getting This Right

Understanding how to fix keyboard navigation accessibility isn't just a technical exercise. Domino's, Winn-Dixie, and hundreds of smaller businesses have faced lawsuits over exactly these failures. Courts have consistently held that the ADA applies to websites. The average settlement for a web accessibility lawsuit is between $25,000 and $100,000 — before attorney fees.

Beyond legal risk, 26% of American adults live with some form of disability. Keyboard-accessible sites also convert better for power users, work properly in unusual browser environments, and earn stronger SEO signals from Google.

Knowing how to fix keyboard navigation accessibility gives you a foundation, but manual audits miss things and take time you may not have. The fastest path to compliance is knowing exactly what's broken on your specific site.

Scan your site for free at wcagrepair.com and get a remediation guide with exact code fixes for $8.99. You'll see every keyboard navigation failure, focus indicator issue, and tabindex problem — with the specific lines of code to fix them.