How to Test WordPress Blocks With a Keyboard

Start from the browser address bar, put the mouse away, and complete every important task.

Use Tab, Shift+Tab, Enter, Space, arrow keys, and Escape where expected.

Record unreachable controls, invisible focus, confusing order, traps, and unexpected actions.

Test the frontend, not the editor

This workflow tests public WordPress blocks. It does not test block-editor keyboard shortcuts. The longer version is in the practical block accessibility checklist.

The theme and plugins change public markup, styling, and interaction. Test their combined output.

Use anonymous public pages. Administrative bars can add unrelated focus stops.

Understand what the test proves

A keyboard test finds barriers affecting keyboard and keyboard-compatible input.

It can reveal missing access, traps, focus problems, and illogical sequences.

It cannot prove screen-reader support, contrast compliance, or complete conformance.

Use an appropriate browser setup

Some operating systems limit Tab navigation by default. Enable full keyboard access first.

Confirm Tab reaches ordinary links and controls on a known accessible page. More on that in how to build accessible sliders in WordPress.

Document browser, operating system, viewport, and zoom. Test evidence needs context.

Choose representative pages

Select templates containing every active interactive block. Include uncommon states and long content.

Test homepage, navigation, search, forms, products, support, and conversion journeys.

One simple post cannot represent the site. Build a maintained sample set.

Start from a clean state

Open a private window and load the complete public URL. Clear previous modal state.

Begin at the address bar. This makes the page-entry sequence repeatable.

Do not click the page first. A click can place focus artificially.

Put the pointing device away

Do not rescue failed interactions with a mouse or trackpad. Record the failure.

A quick click hides the real barrier. Continue only through available keyboard routes.

Restart the scenario after any accidental pointer use. Keep evidence trustworthy.

Know the baseline keys

1. Tab moves forward between controls.
2. Shift+Tab moves backward.
3. Enter usually activates links and buttons.
4. Space usually activates buttons and toggles.
5. Arrow keys operate certain composite widgets.
6. Escape commonly dismisses temporary interfaces.

Exact keys depend on the component pattern. Follow established behaviour for that widget.

Find the first focus target

Press Tab from the address bar. The first page target should make sense.

A skip link often appears first. Cookie controls may precede it when active.

Invisible or empty first targets need investigation. Inspect their accessible purpose.

Test the skip link

Activate the skip link using Enter. It should bypass repeated navigation.

The target should reach main content meaningfully. Sticky headers must not cover it.

Continue tabbing afterwards. Focus should proceed inside or near main content.

Track every focus stop

Move forward through the whole page. Note each visible focus indicator and control.

Do not expect static text to receive focus. Focus belongs mainly on interactive components.

Empty stops, repeated nested stops, and unreachable controls deserve defects.

Check focus visibility

You should always identify the focused control. A clear outline commonly provides evidence.

Test links, buttons, inputs, menus, cards, dots, and icon controls.

The W3C Easy Checks includes keyboard access and visual-focus guidance.

Check focus against every background

One outline can disappear over dark sections or images. Test all visual contexts.

Hover styling cannot substitute for keyboard focus. Verify each state independently.

Theme palette changes can break indicators globally. Retest after design updates.

Check focus obstruction

Sticky headers, banners, popups, and chat widgets can cover the focused component.

Continue through the page with every overlay active. Observe partial and complete obstruction.

Closing an overlay should reveal and restore focus sensibly. Record lost context.

Check logical focus order

Focus order should preserve meaning and operability. It need not mirror pixels perfectly.

The W3C focus-order guidance explains the required logical sequence.

Watch for jumps into footers, hidden regions, or unrelated columns.

Compare focus and visual order

Columns and flex layouts can rearrange content visually. DOM order may remain different.

A sighted keyboard user should not chase focus unpredictably across the viewport.

Test desktop and mobile stacking. Responsive CSS can create new mismatches.

Test reverse navigation

Use Shift+Tab through important components. Reverse movement should remain predictable.

Dialogs, menus, and embeds can behave differently backwards. Test entry and exit.

Reverse navigation also reveals disappearing focus styles. Record every inconsistency.

Test all links

Every actionable link should receive focus and activate using Enter.

Image links need visible focus and an understandable accessible name. Empty cards often fail.

New windows should not break expected navigation. Confirm returning focus remains understandable.

Test all buttons

Buttons should receive focus and activate with expected keyboard keys.

Test icon buttons, close controls, toggles, filters, and pagination.

Activation should not unexpectedly submit forms or navigate. Semantics determine expected behaviour.

Test navigation menus

Reach the menu toggle, open it, traverse items, and close it.

Test nested items according to the implemented pattern. Arrow keys may be expected.

Closing mobile navigation should restore focus toward its toggle. Background controls should remain controlled.

Test disclosure blocks

Tab toward each summary or accordion control. Activate it using Enter and Space.

Expanded content should enter the normal sequence when interactive controls appear.

Collapsed content should not expose hidden controls. Focus must not disappear during closure.

Test tabs and tabbed content

Tabbed interfaces commonly use arrow keys between tabs. Tab then enters active panel content.

Check selected state, visible focus, panel association, and disabled tabs.

Do not demand mouse clicks between panels. Every view needs keyboard access.

Test forms from beginning to end

Reach every field, instruction, choice, submit control, and error message.

Complete the form without pointer input. Preserve entered data after validation errors.

Test successful confirmation and failure recovery. A reachable submit button is insufficient.

Test text inputs

Tab into the field, type, edit, select, and leave it normally.

Focus indicators should remain visible around filled and invalid states.

Date pickers and autocomplete suggestions need their own keyboard checks.

Test checkboxes and radio groups

Space should toggle checkboxes. Arrow keys normally move within radio groups.

Check visible labels and focus. Custom styling must not hide native states.

Required choices need usable error recovery. Do not move users unpredictably.

Test select controls

Reach the control, inspect options, change selection, and leave without accidental submission.

Custom comboboxes require more keys and states. Follow their documented interaction pattern.

Typing letters may move among options. Verify predictable behaviour and retained selection.

Test dialogs and popups

Activate the opener and confirm focus enters the dialog appropriately.

Tab through every dialog control. Focus should not escape into inert background content.

Close with its button and expected Escape behaviour. Focus should return sensibly.

Test carousels and sliders

Reach previous, next, rotation, and slide-picker controls. Activate each repeatedly.

Focus should remain stable while slides change. Autoplay should stop when focus enters.

Hidden slides must not expose focusable links. Post 093 covers complete slider construction.

Test media players

Reach play, pause, volume, captions, timeline, fullscreen, and related controls.

Confirm focus never becomes trapped inside the player. Embedded providers require separate checks.

Keyboard shortcuts should not conflict unexpectedly. Users need a dependable exit.

Test maps and embedded applications

Embedded interfaces can consume Tab, arrows, or Escape. Test entry, operation, and exit.

If unusual exit keys are required, clear instructions must appear beforehand.

Provide equivalent essential information outside complex embeds. The embed cannot become a dead end.

Test hover-only content

Tooltips, menus, and controls revealed by hover need keyboard equivalents.

Tab toward the trigger and confirm content appears through focus or activation.

Temporary content should remain dismissible and hoverable where relevant. Do not block targets.

Test drag-only functions

Dragging cannot be the only way to change order, position, or value.

Look for buttons, direct inputs, or keyboard controls providing equivalent outcomes.

Test slide scrubbers, comparisons, maps, and sorters. Record missing alternatives.

Test dynamically inserted content

Filters, carts, validation, and live search can add controls after activation.

Continue tabbing through the new state. Confirm focus does not reset unexpectedly.

Removing content should not strand focus. Test empty and error states too.

Test infinite loading

Loading more content can push following controls away indefinitely. Footer access may disappear.

A keyboard-operable Load More button provides clear control and progress.

Check focus after activation. It should support continued navigation without losing context.

Look for keyboard traps

Every entered component needs a keyboard exit. This includes third-party embeds.

The W3C keyboard-trap guidance permits unusual exits only with user instructions.

A trap can block the entire remaining page. Treat it as severe.

Look for positive tabindex

Positive `tabindex` values impose manual order. They become fragile as content changes.

Focus may jump toward high-priority elements before earlier content. Inspect suspicious sequences.

Prefer natural DOM order. Repair structure instead of numbering every stop.

Look for inactive hidden controls

Closed menus, hidden slides, and collapsed panels should not expose internal controls.

Focus disappearing offscreen signals incorrect hiding. Inspect the responsible component.

Opening the component should restore reachable controls in a logical position.

Repeat at responsive widths

Mobile navigation and stacked blocks often use different markup or scripts.

Test narrow widths without touching the screen. Complete the same journeys.

Rotate where relevant. Focus should remain visible after layout changes.

Repeat with zoom

Zoom reduces visible context and can trigger responsive layouts. Focus jumps become harder.

Complete critical keyboard journeys while zoomed. Watch fixed overlays and clipped controls.

Do not use horizontal scrolling to hide focus failures. Record the rendered condition.

Record failures consistently

1. Record the public URL.
2. Name the affected block.
3. List exact reproduction keys.
4. Describe expected behaviour.
5. Describe actual behaviour.
6. Capture browser and viewport.
7. State the user impact.
8. Assign an accountable owner.

A screenshot can support evidence. A short recording often explains focus movement better.

Prioritise by blocked outcome

An unreachable purchase, login, consent, or support action deserves urgent correction.

Keyboard traps and invisible focus can block complete journeys. Cosmetic inconsistency ranks lower.

Severity should reflect user impact and frequency. Do not rank only by implementation effort.

Retest the exact scenario

After correction, repeat the original keys from the same starting state.

Then test neighbouring controls and reverse navigation. Fixes can move the failure.

Keep evidence of passing behaviour. Close the defect only after production verification.

Build a regression route

Maintain short keyboard routes covering every shared component and critical journey.

Run them after WordPress, theme, and plugin updates. Also run after design changes.

Add new components before launch. A growing site needs a growing test map.

Repeat across supported browsers

Native controls can behave differently across browsers and operating systems. Test supported combinations.

Custom scripts may depend on browser events. One passing environment provides limited evidence.

Record combination-specific failures accurately. Avoid assuming every browser shares the defect.

Verify production delivery

Minification, deferred scripts, and caching can change interaction timing after deployment.

Run short keyboard routes on production after cache purges. Use anonymous sessions.

Do not expose private test data. Choose safe public scenarios for final verification.

Know what a pass cannot prove

Keyboard reachability does not prove accessible names, roles, states, or announcements.

A screen-reader user can encounter barriers after every keyboard action succeeds.

This is the honest weak case. Pair keyboard evidence with broader accessibility evaluation.

Use the keyboard test checklist

1. Enable complete keyboard navigation.
2. Choose representative public pages.
3. Start from the address bar.
4. Put the pointer away.
5. Activate the skip link.
6. Track every focus stop.
7. Check visibility and obstruction.
8. Check logical forward order.
9. Check reverse order.
10. Operate every component.
11. Complete every critical form.
12. Find traps and hidden controls.
13. Repeat responsively and zoomed.
14. Record exact reproduction keys.
15. Retest fixes in production.

Frequently asked questions

The verdict

Core blocks often use dependable native controls. Test every plugin block before adoption. Then compare the $299 lifetime suite when several Pro blocks pass your keyboard routes.