How to Test Your Website’s Keyboard Accessibility

Can Someone Use Your Website Without a Mouse?

To check your website’s basic keyboard accessibility, use Tab and Shift + Tab to move between controls, Enter to follow links, and Enter or Space to activate buttons. Try completing a real task, such as opening your menu and sending an inquiry, without touching your mouse.

You should be able to tell where you are, operate the controls, and finish the task.

That matters because some visitors rely on keyboards or other input tools instead of a mouse. W3C’s keyboard guidance explains that keyboard access supports people with visual and mobility disabilities, including people using tools that emulate keyboard input. W3C: Keyboard accessibility. W3C

You don’t need to become an accessibility specialist to spot an obvious roadblock. Start with the same thing you want a customer to accomplish.

1. Pick one useful journey

Choose a short path through your website:

• Homepage → service page → inquiry form.
• Collection → product → size selection → add to cart.
• Events page → event details → registration.

For your first pass, pick one journey and follow it all the way through. A working homepage menu doesn’t tell you whether someone can complete the form three pages later.

You’ll need a desktop or laptop, a keyboard, and a browser. Keep a separate note open for problems. Use a staging site or test mode for anything involving purchases, bookings, or payments.

If you’re using Safari on a Mac, check Safari → Settings → Advanced → “Press Tab to highlight each item on a webpage.” Browser and system settings can affect what Tab reaches, so check those before deciding a skipped link is broken. Apple’s Safari keyboard guide. Apple Support

2. Follow the focus indicator

Open your starting page and press Tab.

Look for an outline, border, or another visible change around a link or control. That’s the focus indicator. It tells you which item will respond to your next action.

Continue with Tab, then reverse direction with Shift + Tab.

Ask yourself:

• Can I see the focused item every time?
• Does the movement follow an understandable order?
• Does a sticky header cover the item I’ve reached?
• Do I seem to land on something invisible?

Regular paragraphs usually won’t receive focus during ordinary Tab navigation. That’s expected. You’re checking interactive elements, rather than every piece of text.

A visible focus indicator is part of WCAG’s Focus Visible requirement. If the indicator disappears, a sighted keyboard user can lose their place even though the control technically still works. W3C: Focus Visible. W3C

Write down the exact location of any problem. “The focus outline disappears on the blue Request a Quote button” gives a developer something concrete to investigate.

3. Open the navigation

Reach your navigation using Tab and try following a link with Enter.

If there’s a button that expands a submenu, try both Enter and Space. For a standard disclosure control, both keys should toggle the content. Then check whether you can reach the revealed links and continue into the page. W3C: Disclosure pattern. W3C

Repeat this with the browser window narrowed enough to show the mobile menu.

Watch for a menu that opens visually while Tab continues through the page behind it. Also check whether hidden menu links remain reachable after you close it.

Those observations help identify a mismatch between what’s on screen and what the keyboard can reach.

4. Complete the form

Move through your contact or inquiry form without clicking.

Can you reach every field? Can you select the options, use checkboxes, and reach the submit button?

Check the field labels, too. “Email address” should remain understandable after you start typing. Placeholder text that disappears shouldn’t be the only explanation of what belongs in a field. W3C’s forms guidance recommends labels that identify controls and are properly associated with them. W3C: Labeling form controls. W3C

On a test form, leave a required field blank and submit. Note whether you can find the error and return to the field that needs attention.

Then complete a valid test submission. Check the confirmation and verify receipt separately. Being able to operate a form and successfully receiving its submission are two different checks.

5. Check popups and dialogs

Open any newsletter popup, booking dialog, or product quick view that appears in your chosen journey.

For a modal dialog, focus should move inside when it opens. Tab and Shift + Tab should stay within it while it’s active. You should have a keyboard-accessible way to close it, and Escape should close a standard modal following W3C’s pattern.

After closing, focus should normally return to the control that opened it. W3C: Modal dialog pattern. W3C

Keeping focus inside an open modal is intentional. Being unable to close it or continue afterward is the problem.

6. If focus is invisible, check the CSS

For developers, search the theme and component styles for rules that remove outlines, such as outline: none.

Removing a browser’s default indicator without a visible replacement can make navigation difficult. The :focus-visible selector lets you style focus when the browser determines an indicator should appear. MDN: :focus-visible. MDN

Here’s a starting point:

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
}

Add this to the stylesheet you maintain for the site, such as your WordPress child theme’s stylesheet. Check that the file loads after any conflicting styles.

The blue is an example. Choose a color that stays visible against your actual backgrounds, and check whether containers clip the outline.

This snippet hasn’t been tested against your theme. It adds a visual indicator; it won’t repair an unreachable button, broken menu behavior, or incorrect focus order.

Turn the findings into a useful fix list

Record each problem with its page, steps, expected behavior, and actual behavior.

For example: “On the Contact page, Tab reaches Submit, but no indicator appears. Expected a visible outline.”

Prioritize anything that prevents someone from completing the task. After a fix, repeat the same journey forward and backward.

This is a first review. W3C explicitly notes that quick checks cover only some accessibility issues, and a page can pass them while still having significant barriers. A broader assessment needs additional checks, including assistive technology testing. W3C: Easy Checks. W3C

Start with your main customer journey today. If you find a point where someone gets stuck, save the steps and get in touch through my website. Having a specific example makes it easier to figure out what needs attention.