Keyboard Navigation in WordPress: Menus, Focus and Common Failures

Keyboard navigation is one of the fastest ways to assess accessibility in WordPress.
If a site can’t be used without a mouse, it’s not accessible — no matter how good it looks.

This is also where many WordPress themes quietly fail: menus that only work on hover, invisible focus states, and missing skip links.

Let’s break down the most common issues and how to fix them.

Keyboard Navigation in WordPress: Menus, Focus and Common Failures

A “Skip to content” link allows keyboard and screen reader users to bypass repetitive navigation and jump straight to the main content.

Why it matters

Without it, users must tab through every menu item on every page

Screen reader users rely on it to reach <main> quickly

How it should work

It’s the first focusable element on the page

It becomes visible on focus

It links to the <main> element

Example:

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

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

If your theme doesn’t include it, accessibility starts already compromised.

Golden rule:
Skip links must be visually hidden, not accessibility-hidden.
If screen readers can’t reach them, they’re useless.

In FSE themes you have to put the skip-link in header pattern, in standard themes you’ll have to edit the template header.php.
Then, to make the skip-link accessible only to those who need it, you can use the following CSS:

.skip-link {
  position: absolute;
  top: -9999px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 12px;
  z-index: 1000;
}

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

.skip-link {
  position: absolute;
  top: -9999px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 12px;
  z-index: 1000;
}

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

If you apply this tecnique, you’ll get a false positive while testing your website with automated tools like Lighthouse.
For example, Lighthouse reports that in this page (and in the whole website) the skip link is not focusable. But try to navigate using TAB and you’ll see by yourself that the skip link is focusable and usable through the keyboard.

Golden rule:

Automated tools can flag real accessibility issues — but they can also miss context.
Manual testing always wins.

`:focus` vs `:focus-visible` (And Why It Matters)

Removing focus outlines is one of the most common accessibility mistakes in WordPress themes.

The problem

Designers often add:

:focus {
  outline: none;
}

:focus {
  outline: none;
}

Result:

Keyboard users lose orientation

Navigation becomes guesswork

The modern solution

Use :focus-visible to style focus only when needed.

Example:

:focus-visible {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

:focus-visible {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

This keeps the UI clean for mouse users and usable for keyboard users.

WordPress menus often break keyboard navigation when dropdowns rely solely on hover.

Common failures

Submenus that don’t open on Enter

Focus trapped inside hidden elements

No way to close the menu with Esc

Accessible behavior

These issues are often invisible until you:

Menus open with Enter or Space

Submenus are reachable with Tab

aria-expanded reflects open/closed state

Focus returns logically when the menu closes

If your menu works only on hover, it’s not accessible.

Important note

In the WordPress Navigation block, hover is bound to the menu item, but keyboard activation is bound to a separate button.
This creates an interaction mismatch that developers should actively fix. The trick is simple. Just add this small script to the footer of your website (using WP Code or any other plugin that allow you to add custom code to WordPress):

document.addEventListener('keydown', function (e) {
  if (e.key !== 'Enter' && e.key !== ' ') return;

  const link = e.target.closest(
    '.wp-block-navigation-item.has-child > .wp-block-navigation-item__content'
  );

  if (!link) return;

  const toggleButton = link.parentElement.querySelector(
    '.wp-block-navigation-submenu__toggle'
  );

  if (!toggleButton) return;

  e.preventDefault();
  toggleButton.click();
});

document.addEventListener('keydown', function (e) {
  if (e.key !== 'Enter' && e.key !== ' ') return;

  const link = e.target.closest(
    '.wp-block-navigation-item.has-child > .wp-block-navigation-item__content'
  );

  if (!link) return;

  const toggleButton = link.parentElement.querySelector(
    '.wp-block-navigation-submenu__toggle'
  );

  if (!toggleButton) return;

  e.preventDefault();
  toggleButton.click();
});

How to Run a Quick Keyboard Navigation Test

You don’t need tools to catch most keyboard issues.

Simple test

Open your site
Put the mouse aside
Use only:
- Tab
- Shift + Tab
- Enter
- Esc

What to check

Can you reach all interactive elements?

Is focus always visible?

Does focus follow a logical order?

Can you activate and close menus?

Can you reach the main content quickly?

If you get lost, stuck, or confused, the site fails the test.

Why Keyboard Navigation Improves Everything

Fixing keyboard navigation:

improves accessibility

reduces usability friction

reveals structural HTML issues

often improves overall UX for everyone

In WordPress, keyboard accessibility is not an edge case — it’s a baseline.

🔗 This article is part of a broader guide on the most critical accessibility areas in WordPress: 6 Expert Techniques to Enhance Accessibility in WordPress

Keyboard Navigation in WordPress: Menus, Focus and Common Failures