June 8, 2021 · reala11y team

A 10-minute keyboard accessibility test for WordPress

Run a quick keyboard-only pass on any WordPress site: tab order, visible focus, skip links, and keyboard traps. Practical steps, no special tools.

Keyboard accessibility is one of the few things you can test on any WordPress site in about ten minutes, with no plugin, no extension, and no screen reader required. All you need is the Tab key and a few minutes of attention.

It also happens to be where a lot of real-world barriers live. People who navigate by keyboard — including many screen-reader users, people with motor disabilities, and plenty of power users — depend on being able to move through your site without a mouse. Automated scanners catch some of this, but tab order and focus behavior are exactly the kind of thing that needs a human pressing keys.

Here is a quick manual pass you can run today.

Before you start

Put the mouse down. Seriously — move your hand off it. The whole point is to experience the site the way a keyboard-only visitor does.

You will mainly use:

• Tab to move forward, Shift + Tab to move back
• Enter and Space to activate links and buttons
• Esc to close menus and modals
• Arrow keys inside menus, sliders, and some custom widgets

Open your homepage in a normal browser tab and start at the very top of the page.

The four checks

1. Tab order (about 3 minutes)

Press Tab repeatedly from the top of the page and watch where focus lands. You are checking that it moves in an order that matches the visual layout — roughly left to right, top to bottom.

Watch for:

• Focus jumping somewhere unexpected, or skipping over a visible link or button entirely
• A logical reading order that the tab order contradicts (this is WCAG 2.4.3, Focus Order)
• Focus getting stuck on things that should not be interactive

A common WordPress cause is a positive tabindex (for example tabindex="3") added by a theme or page builder. Positive values override the natural DOM order and almost always make things worse. The fix is to remove them so focus follows source order.

2. Visible focus (about 2 minutes)

As you tab, can you always see where you are? There should be a clear focus indicator — usually an outline or ring — on every link, button, and field.

If the indicator disappears, that is a real barrier (WCAG 2.4.7, Focus Visible). The usual culprit is a theme or reset stylesheet doing this:

:focus { outline: none; }

That line removes the only signal a keyboard user has. The fix is a visible :focus-visible style, not silence.

3. Skip link (about 1 minute)

Reload the page and press Tab exactly once. Many accessible themes reveal a “Skip to content” link as the first focusable element. It lets keyboard users jump past the header and navigation straight to the main content (WCAG 2.4.1, Bypass Blocks).

If pressing Tab first reveals nothing — and you have to tab through twenty navigation links on every single page to reach the article — that is the gap a skip link fills.

4. Keyboard traps (about 3 minutes)

This is the most important check. Open every interactive component you can find — the mobile menu, a search overlay, a popup, a cookie banner, an embedded video, a slider — and try to tab out of it.

You are looking for a keyboard trap (WCAG 2.1.2): focus goes into a component and cannot get back out by keyboard alone. Also confirm:

• Esc closes modals and overlays
• After closing, focus returns somewhere sensible — not back to the top of the page

A trap can make an entire site unusable for a keyboard visitor, so treat any you find as high priority.

What to do with what you find

Some of these issues are code-level and genuinely fixable at the source. A missing skip link, a suppressed focus outline, a stray positive tabindex, a viewport meta tag that blocks zoom — these are HTML and CSS problems, which is exactly the category reala11y is built to detect and, where it is safe, remediate. That is the difference between fixing the underlying markup and bolting on an overlay widget that leaves the page untouched. You can see how that works on our how it works page, and the relevant success criteria are written up in our WCAG 2.2 guide.

Other findings — like whether the tab order actually matches your content’s meaning — need a person to judge. That is normal. Automated tooling, including ours, typically detects only 30–40% of WCAG issues by criteria; the rest is manual work like the pass you just ran.

Honest takeaway

Ten minutes with the Tab key will not make your site conformant, and no tool can promise that for you. But this pass reliably surfaces the barriers keyboard users hit most, it costs nothing, and you can repeat it after every theme update or builder change. Run it, fix what you can at the code level, and book the harder judgment calls for a manual review. Honest, repeatable checks beat a badge that claims more than it delivers.