Website Keyboard Accessibility: How to Test and Fix Common Barriers
Updated: 4 days ago
A website is keyboard accessible when someone can reach, understand and operate every necessary control without using a mouse. Test the published site with Tab, Shift+Tab, Enter, Space, arrow keys and Escape. If focus disappears, jumps into hidden content, becomes trapped or cannot complete the main task, the page still has a real accessibility barrier.
Keyboard accessibility pass-or-fail checklist
A practical pass means the visitor can see focus, follow a logical order, operate menus and forms, close temporary layers and finish the conversion path. Check these conditions before debating an automated score:
Every mouse or touch action needed for the journey has a keyboard-equivalent route.
Focus is visible and is not completely covered by sticky or floating content.
Tab order follows the page’s meaning rather than its visual column layout.
Closed drawers, menus, accordions and inactive slides stay out of the tab sequence.
Dialogs contain focus while open, close predictably and return focus to a sensible control.
Form errors are reachable, understandable and do not erase entered information.
When I audit keyboard access, I do not begin with color contrast or an automated score. I begin at the browser address bar, press Tab, and try to complete the site’s most valuable task without touching a mouse. That simple test exposes barriers that affect people using physical keyboards, switch devices, speech input, screen readers, and other keyboard-emulating technology.
What keyboard accessibility actually requires
WCAG 2.2’s Keyboard criterion says functionality should be operable through a keyboard interface, except for interactions whose underlying purpose genuinely depends on a movement path. In practice, links, menus, forms, sliders, dialogs, carousels, account controls, carts, and booking steps need a workable keyboard path.
This is not a demand to remove mouse or touch support. It means the same outcome must remain available when a pointer is not used. It also means that a control being technically focusable is not enough: the visitor needs to see where focus is, understand the order, operate the control, and leave it.
Run the seven-minute keyboard-only test
Use the published site, not only an editor preview. Start with a fresh browser window at the homepage and keep the mouse untouched.
Press Tab once. A skip link or the first meaningful control should receive a visible focus indicator.
Continue with Tab through the header, navigation, main content, forms, and footer. Use Shift+Tab to move backward.
Activate buttons and links with Enter. Test native buttons with Space as well.
Use arrow keys where the component pattern expects them, such as menus, tabs, radio groups, or sliders.
Open every menu, popup, lightbox, cart drawer, cookie panel, chat widget, and modal. Confirm that Escape or another documented key closes it.
Complete the main journey: enquiry, booking, purchase, account sign-in, or subscription.
Repeat at mobile-width layout with a physical keyboard or desktop responsive mode because collapsed navigation often uses different code.
Record the key pressed, the element that should have responded, what actually happened, and the exact URL. A short focus-path recording is more useful to a developer than “the site is not accessible.”
Problem 1: You cannot see where the keyboard is
The browser is moving focus, but CSS removes or hides the outline. The visitor presses Tab and has no idea which link or button is active. This frequently happens after a global outline reset or when the chosen focus color blends into a card, image, or sticky header.
W3C’s Focus Visible guidance explains why a visible keyboard-focus indicator matters. Restore a clear outline or equivalent indicator with sufficient contrast against every background. Use :focus-visible when you want the stronger indicator to appear for keyboard interaction without forcing the same presentation on every pointer click.
Do not use outline: none unless an equally visible replacement is applied.
Test focused controls over white, dark, photographic, gradient, and disabled-looking backgrounds.
Make the indicator surround the interactive element, not a distant parent container.
Check sticky headers and cookie banners that may cover the focused element.
Zoom the page and confirm the indicator is still visible.
Problem 2: Tab order jumps around the page
Visual builders can place elements into attractive columns while the underlying document order stays unrelated. A visitor may move from the header to the footer, back to a form, then into an off-screen menu. Positive tabindex values can make the sequence even harder to predict.
The WCAG focus-order explanation requires an order that preserves meaning and operability. The most durable fix is to make the document order match the intended journey, then use CSS for visual layout. Prefer native order and tabindex="0" only when a custom component genuinely needs to join the sequence; avoid positive tabindex values as a repair shortcut.
Hidden menus, inactive carousel slides, collapsed accordions, and off-canvas panels should not remain in the tab sequence. When they are closed, remove their descendants from keyboard access using the component’s supported inactive-state pattern.
Problem 3: A menu opens with a mouse but not a keyboard
Hover-only navigation is a familiar failure. The top-level item receives focus, but Enter or Space does nothing, the submenu closes as focus enters it, or arrow-key behavior conflicts with the browser.
Use a real button for a menu trigger, expose its expanded state, and connect it to the controlled menu. Keep the interaction predictable: the trigger opens the menu, focus can enter its items, Escape closes it, and focus returns to the trigger. Do not turn a plain container into a pretend button with only a click handler.
Mega menus need extra care. Test every column, promotional card, language switcher, account link, and close control. If the menu covers the page, ensure background controls are not still reachable.
Problem 4: A modal or widget traps focus
A correctly implemented modal intentionally keeps focus inside while it is open, but it must provide an obvious way out. A broken trap cycles through two controls forever, sends focus behind the overlay, or closes visually while leaving focus on a removed element.
W3C’s No Keyboard Trap guidance says users must be able to move focus away using the keyboard; if an unusual exit method is required, it must be explained. For a standard modal, move focus into it when opened, contain focus while open, support Escape where appropriate, and return focus to the control that launched it.
Test cookie banners, newsletter popups, chat launchers, video embeds, calendars, and payment widgets separately.
Open and close the component repeatedly; focus restoration bugs often appear on the second attempt.
Check third-party updates because a vendor can change markup without changing your page design.
Never solve a trap by making the entire widget unreachable if customers still need its function.
Problem 5: Forms are reachable but impossible to complete
Keyboard users need persistent labels, logical field order, reachable help text, operable custom controls, and errors that are both announced and easy to find. A red border alone is not a repair. After submission fails, move focus to an error summary or the first invalid field according to the form’s design, and keep previously entered values.
Use Webcurry’s field-by-field form-abandonment diagnostic to inspect phone, date, upload, CAPTCHA, consent, and validation friction. Then verify the delivery path with the contact-form troubleshooting guide.
Problem 6: Custom controls imitate native HTML badly
A styled div may look like a button, dropdown, checkbox, or tab, but it does not automatically inherit keyboard behavior, focus management, name, role, state, or value. Native HTML controls solve much of this work before custom scripting begins.
If a custom component is necessary, implement the established interaction pattern completely. Adding a role without behavior can make the component sound correct to assistive technology while remaining unusable. Test the actual keystrokes, state changes, and focus movement.
Platform-specific repair paths
Wix
Run the site’s accessibility checks, then perform the manual keyboard test on published pages.
Review the DOM or tab order for elements arranged visually in strips, columns, repeaters, and overlays.
Prefer native Wix buttons, links, inputs, and menus over clickable decorative containers.
Test lightboxes, custom Velo interactions, embedded apps, booking calendars, and chat widgets for focus entry and exit.
Republish and test the live site at desktop and collapsed-menu widths.
WordPress
Test with the active theme and page-builder output before installing another accessibility plugin.
Use a staging copy to isolate the theme, menu script, popup plugin, form plugin, and optimization layer.
Inspect custom widgets for div-based controls, removed outlines, positive tabindex values, and hidden focusable content.
Retest after minification or deferred-script changes because load order can break keyboard handlers.
Update the smallest responsible component and keep a rollback point.
Shopify
Duplicate the theme and compare the failing journey with a known-good theme.
Test navigation drawers, predictive search, variant selectors, cart drawers, localization controls, and app embeds.
Confirm that focus returns to the trigger after a drawer or modal closes.
Remove recent theme code or app blocks one at a time in the duplicate theme.
Check the published storefront across desktop and mobile breakpoints before deploying.
Automated tools help, but they cannot finish this audit
Automated scanners can flag missing semantics, contrast problems, duplicate IDs, and some focus issues. They cannot reliably decide whether the tab sequence makes sense for your business process, whether a custom calendar is understandable, or whether focus returns to the right place after a successful action.
Use automation to find candidates, then manually complete the customer journey. Include at least the homepage, primary service or product template, contact form, search, navigation, account flow, cart or booking path, cookie controls, and any high-value landing page.
Keyboard testing should sit beside mobile and conversion testing, not in a separate forgotten checklist. The mobile call-button diagnostic shows how a control can be visible but ineffective, while the AI-built website launch checklist helps catch generated interfaces that look finished before they have been fully tested.
A practical definition of done
A keyboard-accessibility fix is complete when a visitor can enter the page, locate focus, understand its order, operate every necessary control, escape temporary components, recover from errors, and finish the site’s main task without a pointer. Test forward and backward, at different viewport widths, and after dynamic content appears.
Do not chase a perfect badge while the booking button, menu, or form is still unreachable. Fix the customer journey first, document the component pattern, and add the keyboard walkthrough to every future release.
For a focused review of navigation, forms, dialogs, and conversion-critical paths, contact Webcurry for a website accessibility and usability audit. A short list of failing URLs and the business action each page must support is the best place to begin.
WCAG 2.2 check: focused controls must stay visible
WCAG 2.2 added Focus Not Obscured (Minimum) at Level AA. When a component receives keyboard focus, author-created content must not hide it completely. Sticky headers, cookie banners, chat panels and non-modal overlays are frequent causes.
Test this while moving forward and backward through the page at desktop and mobile-width layouts. If a sticky layer covers the active control, adjust its behaviour, spacing or scroll positioning instead of assuming the browser will reveal the element correctly.
Frequently asked questions
How do I test website keyboard accessibility?
Start at the browser address bar and use Tab, Shift+Tab, Enter, Space, arrow keys and Escape without touching the mouse. Complete the site’s main task and record where focus disappears, jumps, becomes trapped or cannot activate a control.
What should happen when I press the Tab key on a website?
Focus should move through interactive controls in a logical order, and the currently focused element should remain visibly identifiable. Hidden menus, inactive slides and closed panels should not unexpectedly enter the tab sequence.
Why is the keyboard focus outline missing?
A global CSS reset, low-contrast styling or an overlay may be hiding it. Remove rules such as outline: none unless an equally visible replacement exists, and test the indicator over every background and responsive layout.
What is a keyboard trap?
A keyboard trap occurs when focus enters a component but cannot leave using the keyboard. Modals can intentionally contain focus while open, but they must provide a working close action and return focus appropriately after closing.
Should menus open with Enter and Space?
A menu button should normally open with Enter or Space, expose its expanded state and move focus predictably. Once open, its keyboard behaviour should follow the interaction pattern used by that type of menu.
Can sticky headers and cookie banners fail keyboard accessibility?
Yes. WCAG 2.2 requires a focused component not to be completely hidden by author-created content. Test sticky headers, banners, chat launchers and overlays while tabbing through the published page.
Can an automated accessibility scanner find every keyboard problem?
No. Automated tools can flag some semantic and focus issues, but they cannot reliably judge whether the tab order supports the business journey or whether focus moves correctly through every custom component.
What should I ask a web design agency about accessibility?
Ask the agency to demonstrate a keyboard-only walkthrough of the live navigation, forms, dialogs and main conversion path. Request the failing URL, keystroke, expected behaviour, actual result and retest evidence for every issue.
For navigation, form, dialog and conversion-path testing, Webcurry’s web design agency can document the exact keystroke, component and business task affected instead of returning a generic accessibility score.
Comments