Building useful websites
Check a webpage with a keyboard: reach, activate and leave
Reaching a button is only the first check. Follow one real task, activate its controls, then make sure you can continue or leave.
1. Choose one task and put the mouse aside
Choose a page you maintain and one task: open the reading list, change a filter, or reach the contact form. For actions that send messages or change records, use a preview or test version. Write down the result you expect before you start.
Open the page from the address bar, then use the keyboard. Record the browser and operating system. Some browser or system settings change which controls Tab reaches; check those settings if ordinary links seem to be skipped. This is a basic keyboard check, not a complete accessibility assessment.
2. Follow the focus in both directions
Press Tab to move forward and Shift+Tab to move back. Focus is the control that will receive your next keyboard action. At each stop, identify it from the page itself: a clear outline, border or other visible indicator should show where you are. Check that a sticky header or banner does not hide it.
Keep two notes: controls you expected to reach, and controls you actually reached. A heading or ordinary paragraph usually is not a Tab stop. Do not add every piece of text to the Tab sequence just to make the lists longer. Complex widgets may use arrow keys inside them; follow the appropriate widget pattern rather than expecting Tab to visit every option.
The order should make sense for the task. If focus jumps from the page footer back to the first field, record that exact transition. MDN recommends a logical HTML order instead of patching the sequence with positive tabindex values.
3. Activate the control, not just its outline
For a normal link to another page or location, press Enter. For a button that performs an action, try Enter and Space separately, returning to the same starting state each time. A visible focus indicator does not prove that either key works. Space is not the normal activation test for a link.
After activation, look for the promised result. Did the list appear, did the setting change, or did the intended destination open? Record a result you can observe; a color change on the control alone does not establish that the action happened.
- Navigation: “Meeting details” opens another page. Use a real link with an href destination.
- Action: “Show reading list” reveals information in the current page. Use a button and implement its action.
- For a developer: adding tabindex="0" to a clickable span makes it focusable; it does not supply the keyboard behavior of a native button.
4. Repair a fictional reading-list control
Imagine a fictional book club page with “Meeting details”, “Show reading list” and “Contact”. The reading-list control is styled text with a mouse-click handler. Tab jumps from Meeting details straight to Contact, so the list is unreachable on this route.
An incomplete repair adds tabindex="0". Now the control receives focus, but Enter and Space still do nothing because no keyboard activation was implemented. A review that checks only the moving outline misses the failure.
A better repair uses a native button, gives it the visible label “Show reading list”, connects its action, and preserves a visible focus indicator. If it expands and collapses a panel, keep aria-expanded in sync with that state, as the WAI disclosure pattern describes. Retest reaching the button, activating it with both keys, and continuing to Contact. This scenario is invented to explain the check; it is not a report from a real club.
Coru ran this comparison in an original local page on 21 October 2026, using Chrome 155.0.8059.12. Tab skipped a click-only span and reached a span with tabindex="0". Enter and Space produced no clicks on the focusable span; the native button produced one click for each key. Shift+Tab returned from the following link to the button, which had a visible outline. This was a browser experiment, not a test with screen-reader users.
To repeat the comparison, place those three elements in a local test page and attach a separate visible counter to each click handler. Record which elements Tab reaches and each counter after Enter and Space. Keep the browser version with the result; the observation applies to the tested fixture.
5. Check that you can close or leave
Open any dialog used by the task. Focus should move into it. For a modal dialog, Tab and Shift+Tab deliberately stay inside while it is open. Try Escape and its visible Close or Cancel button, then check where focus returns. The usual destination is the control that opened it, unless the completed action makes another location more logical.
That temporary containment is different from a keyboard trap. If you cannot close or leave a component using the keyboard, write down how you entered and the last working key. A less familiar exit method needs instructions. Do not count reaching for the mouse or reloading the page as a successful exit.
6. Copy this test record
Keep the failed step small enough for someone else to reproduce. For example: “From Meeting details, press Tab once. Show reading list has focus. Press Space. Expected: list appears. Observed: nothing changes.” This is an example defect report, not an observed result from a public site.
- Page and task: ___. Date, browser/version, operating system and keyboard settings: ___.
- Forward and backward route: ___. Missing control or surprising transition: ___.
- Control label: ___. Focus visible and unobscured: ___.
- Starting state: ___. Key: ___. Expected result: ___. Observed result: ___.
- Dialog exit and focus after closing: ___. No dialog on this route / checked / not checked: ___.
- Repair: ___. Same steps after reloading the published page: ___. Remaining unchecked states: ___.
What a passing route tells you
A successful pass shows that the tested task worked with those keys in the recorded conditions. It does not certify WCAG conformance, screen-reader announcements, every browser, or every state of the page. Check other important tasks and get feedback from people who use the relevant assistive technologies.
If a step remains confusing, use the feedback form below to share the control label, key pressed and observed result. Omit private addresses and account details. A reproducible failure is more useful than “the keyboard does not work”.