Run a first keyboard check on your website.

1. Choose a task and record the setup

Pick a small journey with a clear finish: open a category, filter the results, and read an item; or complete a contact form using test data. Note the starting page, browser, device, and display size. Use a keyboard setup that supports navigation to the page’s controls.

W3C’s keyboard guidance explains why keyboard operation matters for people who cannot use a mouse and for people using alternative input devices. A successful pointer interaction does not answer whether the same function works through a keyboard interface. Review the actual task rather than only the page’s appearance.

Sources: [1]

2. Follow the focus through the page

Start near the beginning and use Tab to move forward and Shift+Tab to move backward. Look for the visible indicator showing which link or control will receive your next action. Follow the sequence through navigation, page tools, content links, and the footer without using the mouse to rescue a difficult step.

W3C’s Focus Visible explanation emphasizes that users need to know which element has keyboard focus. Record places where the indicator disappears or is hard to locate. Also note an order that makes the task difficult to understand, especially when the page changes layout at a narrower width.

Sources: [2] [3]

3. Operate controls instead of only reaching them

Try activating links and buttons using their expected keyboard controls. Enter commonly activates links; buttons and selection controls may use Enter, Space, or arrow keys depending on the control. W3C’s Easy Checks includes reaching controls, moving away from them, and checking that functionality is available without a mouse.

Use a test environment for actions that would otherwise send a message or make a real purchase.

Sources: [3]

4. Write an issue someone can reproduce

Record the page, starting state, keys pressed, expected outcome, and actual result. For example: “After opening the filter menu and selecting a category, the next Tab moves somewhere I cannot see.” Add the browser and screen size so the builder can repeat the same conditions.

Separate a confirmed failure from uncertainty about a particular control’s expected behavior. If you become stuck, document where it happened before restarting. Screenshots can show a missing or obscured indicator, while a short sequence of steps is usually better for explaining a focus-order problem.

5. Recheck the task after a fix

Repeat the same steps after the change, then continue through the rest of the journey. Check backward movement too, so a repair does not merely move the difficulty to an earlier control. Include a narrow layout if menus or filters behave differently there.

Keep the result labeled with its scope: a named task, on a named setup, on a particular date. Keyboard testing is one part of a broader accessibility review, which may also examine names, structure, contrast, zoom, media alternatives, and assistive-technology behavior. Do not turn one completed checklist into a site-wide accessibility badge.