Your Website Looks Fine, but Keyboard Users Cannot Use It—How to Fix It
A website can look polished, pass a visual review, and still become unusable the moment someone puts down the mouse. The navigation will not open, focus disappears, a popup traps the visitor, or the submit button cannot be reached. None of these problems are obvious in a screenshot.
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.
Comments