Table of contents10
I was watching a usability test recording when I saw it happen. The tester, a woman with a repetitive strain injury who navigates entirely by keyboard, landed on a client’s homepage and pressed Tab. Nothing visible happened. She pressed Tab again. And again. After eleven presses, she sighed and said, “I have no idea where I am.” The site’s theme had removed the focus outline — the visible ring that shows which element is selected — because the designer thought it was ugly. She left the site thirty seconds later. So did the sale.
I’m Carlos Mendez, and I test WordPress sites for keyboard accessibility the way a mechanic test-drives a car: by actually using it the way the people who depend on it do. Millions of people browse without a mouse — people with motor impairments, people with repetitive strain injuries, power users, and anyone whose trackpad just died. For them, your Tab key is the entire website.
This guide teaches you the exact 20-minute keyboard test I run on every site, what each WCAG rule about keyboards actually means in plain language, and how to fix the failures you’ll find — most of which live in your theme’s CSS and menus. If you run a WordPress site and want everyone to be able to use it, this one’s for you. Put your mouse aside. Let’s begin.
The objection I always hear: “Nobody really browses without a mouse, do they?” They do — and here’s the part that should worry you even if you doubt it. Keyboard testing is the fastest, cheapest accessibility test that exists. No tools, no software, no expertise. Twenty minutes with your keyboard finds problems that automated scanners miss completely. Even if you never think about accessibility again, this test makes your site better for everyone, including Google, which navigates a lot like a keyboard user.
Here’s what this guide covers:
- The 20-Minute Keyboard Test: Your New Superpower
- What the WCAG Keyboard Rules Actually Say (in Plain Words)
- Skip Links: The Feature Your Theme Might Be Missing
- Focus Visible: Why That Outline Exists and How to Style It Right
- Focus Order: Making Tab Follow Your Layout
- Dropdown Menus That Work Without a Mouse
- Modals, Sliders, and Traps: Taming Interactive Widgets
- Testing Checklist You Can Run Every Quarter
- Frequently Asked Questions
- Final Thoughts
Ready? Let’s get started.
The 20-Minute Keyboard Test: Your New Superpower
Here’s the deal: you don’t need to understand a single WCAG rule to start finding problems. You need a keyboard, a browser, and twenty honest minutes. This is the exact workflow I use on client sites, and it finds real failures on most WordPress sites I test.
Put your mouse away. Physically move it off the desk. This matters — the moment you reach for the mouse, you’ve stopped testing.
Step 1: Tab from the top. Click in the browser’s address bar, then press Tab. The first interactive element on the page should receive focus — ideally a “skip to content” link, which I’ll explain below. Watch: is the focus indicator clearly visible? Can you tell exactly which element has focus? If you can’t see it, that’s a failure of WCAG 2.4.7, and it’s the most common one I find.
Step 2: Walk the whole page. Keep pressing Tab. Move through the header, the navigation, the main content, the sidebar, the footer. Note everything that surprises you: focus that disappears, an order that jumps around the page instead of flowing down it, elements you can see but never reach.
Step 3: Operate everything. When focus lands on a link, press Enter. On a button, press Enter or Space. On a checkbox, Space toggles it. On a dropdown menu, try opening it with Enter and moving through it with the arrow keys. If something only responds to a mouse click, you’ve found a WCAG 2.1.1 failure — everything operable by mouse must be operable by keyboard.
Step 4: Try to get stuck. Tab into every interactive widget — video players, sliders, date pickers, embedded maps — and then try to tab out. If you can’t leave without reloading the page, that’s a keyboard trap, and it’s one of the most hostile failures a site can have.
Step 5: Test the forms. Tab through your contact form or checkout. Can you reach every field in a sensible order? Can you see which field you’re in? Submit it — with intentional errors first, so you can check whether error messages are reachable and readable by keyboard.
Step 6: Check the escape hatches. Open your mobile menu, any modal or popup, and press Escape. It should close, and focus should return to whatever opened it. If Escape does nothing, keyboard users are stuck.
Twenty minutes. Write down everything odd. Congratulations — you’ve just done a more useful accessibility audit than most automated tools.
What the WCAG Keyboard Rules Actually Say (in Plain Words)
WCAG — the Web Content Accessibility Guidelines, the W3C’s shared rulebook — has several rules about keyboards, each with a number. You don’t need to memorize them, but knowing what each one means helps you argue for fixes with developers and theme authors.
2.1.1 Keyboard (Level A): Everything you can do with a mouse, you can also do with a keyboard. No exceptions, no “almost.” This is the foundation — failing it means some people simply cannot use the feature at all.
2.1.2 No Keyboard Trap (Level A): If you can tab into something, you can tab out of it. A user should never get stuck inside a widget. (Note the sensible exception: a modal dialog is supposed to keep focus inside it while open — but it must let you close it with Escape and return focus afterward.)
2.4.1 Bypass Blocks (Level A): There must be a way to skip past repeated content, like your header navigation. Without it, a keyboard user tabs through your entire menu on every single page before reaching the content. Imagine doing that fifty times a day.
2.4.3 Focus Order (Level A): Focus must move in an order that preserves meaning. If your visual layout reads left to right, top to bottom, your tab order should do the same — not jump from the header to the footer because of how the HTML was assembled.
2.4.7 Focus Visible (Level AA): When you tab through a page, you can see where you are. The focused element must have a visible indicator. The W3C’s own documented failure example is exactly what my client’s theme did: styling outlines away so the indicator disappears.
2.4.11 Focus Not Obscured, Minimum (Level AA, new in WCAG 2.2): The focused element must not be entirely hidden behind something the site author created — like a sticky header or a cookie banner sitting on top of it. You tab to a link, the indicator exists, but a fixed header covers it. Still a failure.
Now you know what each number means when you press Tab. That knowledge is genuinely powerful — it turns “the site feels broken” into “this fails 2.4.7,” which is a sentence developers act on. And if you want the bigger picture — what WCAG is, the conformance levels, and the principles behind all these rules — the WCAG basics guide walks through it step by step.
Skip Links: The Feature Your Theme Might Be Missing
A skip link is a small link — usually invisible until you tab to it — that says “Skip to content.” It lets keyboard users jump past your header and navigation straight to the main content. It’s required in spirit by 2.4.1 (Bypass Blocks), and WordPress core includes them in the admin. But your theme has to include one on the front end, and plenty don’t.
Test yours right now: reload your homepage, press Tab once. Do you see a “Skip to content” link appear, usually at the top-left? If yes, your theme has you covered. If focus jumps straight into the navigation menu with no skip option, it’s missing.
Why does this matter so much? Count the tab stops in your header: logo, menu items, search, social icons, maybe a call-to-action button. On some sites that’s twenty or more stops before the actual content begins — on every page. A skip link collapses that to one keypress. It’s a tiny feature with an enormous quality-of-life impact.
If your theme lacks one, this is a fix worth asking a developer for — it’s a small amount of code: a link at the very top of the page pointing to your main content area, styled to appear on focus. While you’re at it, check that it actually works: activate it and confirm focus lands at the start of your content, not just that the page scrolls.
Bonus Tip: Skip links also help sighted keyboard users and power users who prefer keyboards. When you add one, you’re not just checking a compliance box — you’re making the site genuinely faster to use for a group of people who’ll notice and appreciate it.
Focus Visible: Why That Outline Exists and How to Style It Right
That glowing outline around a focused button — the one designers keep deleting — is the only way a keyboard user knows where they are. Removing it is like removing the cursor from a mouse user’s screen and telling them to guess. WCAG 2.4.7 exists precisely because this kept happening.
The most common cause is a global CSS reset containing something like outline: none applied to links, buttons, and form fields, with nothing put back in its place. Theme developers add it because the default browser outline — often a blue ring — clashes with their design. The intent is understandable. The result is a site that’s unusable by keyboard.
Here’s the thing: the fix isn’t “never touch the outline.” It’s style it intentionally. Modern CSS has the :focus-visible pseudo-class, which shows your custom focus style only for keyboard interaction — mouse users clicking a button won’t see it, but keyboard users tabbing to it will. That’s the best of both worlds: your design stays clean for mouse users, and keyboard users get a clear indicator.
A good focus style is simple: a solid outline, at least 2 pixels thick, in a color that contrasts with the background. If you want a concrete target, WCAG 2.2’s AAA-level guidance suggests a 2px indicator with 3:1 contrast — you don’t need to claim AAA to use those numbers as a design spec. And test it against every background it will appear on, including dark sections and images.
If you’re comfortable adding CSS, the WordPress custom CSS recipes collection shows how to add styles safely without editing theme files directly. A focus style is a perfect first recipe: small, safe, and immediately verifiable — tab through your site before and after.
Note: Never apply outline: none globally without providing a replacement. If you find it in your theme’s CSS or a plugin’s stylesheet, that’s the first thing to fix — it’s a single change that can transform the keyboard experience of your entire site.
Focus Order: Making Tab Follow Your Layout
Focus order is the sequence in which the Tab key moves through your page. It should match the visual layout: top to bottom, left to right (for left-to-right languages). When it doesn’t — when focus jumps from the header to the footer, then back to a sidebar, then into the main content — keyboard users get lost, because the order they’re experiencing has no relationship to what they see.
Why does this happen? Usually because of how the HTML was assembled. A theme might place the sidebar markup before the main content in the code and use CSS to visually reorder them. Sighted mouse users see the intended layout; keyboard users experience the code order. Page builders can create similar mismatches with drag-and-drop layouts.
Testing is easy: tab through the page slowly and ask, “does this follow what I see?” If focus leaps across the page unexpectedly, you’ve found the problem. The fix is structural — the HTML order needs to match the visual order — which usually means theme-level work. But identifying it precisely is valuable: you can now tell a developer “the sidebar is coded before the main content, which breaks 2.4.3,” instead of “tabbing feels weird.”
One more order problem: content that appears visually but is unreachable, or reachable but invisible. Off-canvas mobile menus are the classic case — if the hidden menu’s links are still in the tab order when the menu is closed, keyboard users tab through invisible items. The menu should remove its links from the tab order until it’s opened.
Dropdown Menus That Work Without a Mouse
Navigation menus are the most common keyboard failure point on WordPress sites, because so many themes build dropdowns that only open on mouse hover. A keyboard user tabs to “Services,” presses Enter, and… nothing happens. The dropdown with all the service pages never opens. Half the site is unreachable.
A keyboard-accessible dropdown opens on focus and Enter, not just hover. The user tabs to the parent item, presses Enter or the down arrow, the submenu opens, and they can move through it with arrow keys or Tab. Pressing Escape closes it. This is standard behavior — it’s how operating system menus work — and users expect it. Hover-only menus are one of the classic WordPress theme mistakes that break your site — if your theme shipped one, that’s a strong signal to evaluate the theme itself, not just the menu.
Test every dropdown on your site, desktop and mobile. On mobile, the hamburger menu is its own adventure: opening it should move focus into the menu, tabbing should cycle through the menu items (not wander off into the page behind it), and closing it — via Escape, a close button, or selecting an item — should return focus to the menu button.
Mega menus deserve special attention. They’re impressive visually and often terrible for keyboards: dozens of links, sometimes opening on hover with no keyboard equivalent, sometimes trapping focus. If your theme has a mega menu, test it thoroughly with the 20-minute routine. If it fails, consider whether you actually need it — a simpler menu structure is better for everyone, not just keyboard users.
This connects to a broader principle I come back to in every audit: customizing WordPress without breaking it means checking that every customization — menus included — still works for keyboard users after you change it. Add it to your mental checklist.
Modals, Sliders, and Traps: Taming Interactive Widgets
Popups, modals, sliders, carousels, and tab widgets are where keyboard accessibility goes to die on WordPress sites — usually because they come from plugins whose developers never tested without a mouse.
Modals and popups have a specific correct behavior. When a modal opens, focus should move inside it — to the first interactive element or the modal heading. While it’s open, Tab should cycle within the modal, not escape to the page behind it. (This is the one legitimate “trap” — it’s intentional and expected.) Pressing Escape should close the modal, and focus should return to whatever opened it. Test your newsletter popups, cookie consent dialogs, and any lightbox galleries against this. Most fail at least one step.
Sliders and carousels are notorious. Many auto-advance with no way to pause via keyboard, and their controls are unreachable. At minimum, a slider needs keyboard-reachable previous/next buttons and a pause control. If your slider can’t do that, consider whether the slider is earning its place — a static hero image with a clear call to action often converts better anyway, and it’s accessible by default.
Tab widgets and accordions need arrow-key support: left/right arrows move between tabs, and the tab panel content should be reachable. Many WordPress tab plugins are just clickable divs with no keyboard support at all — clickable divs are invisible to keyboards, because a div isn’t naturally focusable or operable. Real buttons and links are; that’s why semantic HTML matters.
When you find a broken widget, you have three options: find a setting that fixes it (rare), replace the plugin with one that handles keyboards properly, or remove the widget. “Remove it” is underrated. Every interactive widget you delete is a trap you didn’t have to fix.
Testing Checklist You Can Run Every Quarter
Accessibility decays. You fix everything today, then someone installs a new plugin with a popup, the theme updates its menu, a page builder adds a carousel. Quarterly testing catches the rot before it compounds. Here’s my checklist — print it, bookmark it, whatever works:
- Tab through the homepage, contact page, and checkout (if any) with the mouse unplugged. Can you reach everything? See where you are? Complete key tasks?
- Check the skip link: one Tab from the address bar, does “Skip to content” appear and work?
- Open every dropdown menu with keyboard only. Do they open? Can you move through them? Does Escape close them?
- Open the mobile menu at a narrow screen width. Does focus go inside? Does it return when closed?
- Trigger every popup and modal. Does focus move in? Does Tab stay inside? Does Escape close it and return focus?
- Tab into every slider, video, and embedded widget. Can you operate it? Can you tab out?
- Submit every form with errors. Are the errors reachable by keyboard? Can you fix and resubmit without a mouse?
- Zoom to 200% and repeat the Tab walk on one page. Does the order still make sense when the layout reflows?
Bonus Tip: Do this test right after every theme update or new plugin install, not just quarterly. It takes twenty minutes, and catching a keyboard trap the day it appears is infinitely cheaper than discovering it in a complaint — or a lawsuit.
Frequently Asked Questions
Do I really need to care about keyboard navigation if my visitors mostly use phones?
Yes. Many mobile users rely on keyboards — external keyboards, switch devices, and voice control all operate through the same focus system as a physical keyboard. And mobile introduces its own keyboard-equivalent problems: hamburger menus, modals, and carousels that trap touch focus. The 20-minute test at a narrow screen width catches most of these.
What’s the difference between :focus and :focus-visible in CSS?
:focus applies whenever an element has focus, including when a mouse user clicks it — which is why designers dislike styling it; every clicked button gets a ring. :focus-visible is smarter: browsers apply it mainly for keyboard interaction, so mouse users don’t see the ring but keyboard users do. Use :focus-visible for your custom focus styles and you satisfy both designers and keyboard users.
My theme removed the focus outline. Can I just add it back with CSS?
Usually, yes — and it’s one of the highest-impact small fixes you can make. Add a :focus-visible style with a solid 2px outline in a contrasting color, applied to links, buttons, and form fields. Test by tabbing through the site before and after. If the theme’s CSS is aggressive, you may need slightly more specific selectors, but the principle is the same: never leave focus invisible.
Are keyboard traps ever acceptable?
Only one kind: an open modal dialog should keep Tab cycling inside it until it’s dismissed — that’s expected behavior, not a trap, as long as Escape closes it and focus returns to the trigger. Every other trap — sliders you can’t leave, video players that swallow Tab, date pickers with no exit — is a failure. If you can tab in, you must be able to tab out.
How is keyboard testing different from what automated checkers do?
Automated checkers are good at static facts: is there a skip link, does an element have a tabindex problem, is the outline removed in CSS. They’re blind to behavior: whether the tab order makes sense, whether a dropdown actually opens, whether a modal returns focus. That’s why the guides that rank highest all say the same thing — automation catches a fraction of issues, and the keyboard test catches the rest. Do both.
Final Thoughts
I’ll never forget that usability test — the sigh after eleven invisible Tab presses. It stays with me because it was so preventable. Nobody on that team was careless. They just never put the mouse aside and tried.
You now know more than they did. You have the 20-minute test, you understand what 2.1.1 through 2.4.11 actually require, and you know where the bodies are buried: removed outlines, hover-only menus, trapless modals, illogical tab order. Twenty minutes with your keyboard will tell you exactly where your site stands.
Here’s my honest line: your site will fail this test somewhere. Mine did, the first time I ran it on my own site. That’s not a reason to feel bad — it’s the starting point. Fix what you find, one failure at a time, and re-test quarterly. Every fix is a door you just opened for someone.
If you run the test and find something surprising, tell me in the comments. I collect these stories — they’re the best education I know.
