Did you know that a class website can look finished with a mouse and still be difficult for a visitor who uses a keyboard? A school project is not truly ready merely because the designer can click its buttons. The visitor also needs to find controls, understand where they are, and complete a task without needing precise mouse movements.
Keyboard-only testing means trying to use a web page’s interactive features with keys such as Tab, Shift+Tab, Enter, Space and arrow keys, while leaving the mouse aside. Begin with the address bar or reload the page, navigate every necessary control in a meaningful order, check that keyboard focus remains visible, and complete at least one real visitor task. This is an important first accessibility check, not a full accessibility certification.
Diagnose what ‘the site works’ actually means
Ask a student: ‘Can a new visitor reach your download link and submit your contact form without touching the mouse?’ If the answer is ‘I can click it’, the student has demonstrated only mouse access. If they say ‘the link changes colour when I hover’, remind them that keyboard focus and mouse hover are different states. A learner who can use Tab but cannot identify the focused control has found a visibility problem, not necessarily a broken link.
The W3C Web Accessibility Initiative recommends checking keyboard operation and visible focus when reviewing a page. The goal is practical: people who cannot use a mouse should still be able to access interactive controls. It is also useful for students who use assistive technology or have a temporary injury.
A fictional worked example: the science-fair event page
Imagine a student team publishes a small event website with these six interactive elements in intended reading order: (1) Home, (2) Experiments, (3) View Results, (4) Download Schedule, (5) an email field, and (6) a Subscribe button. This is an illustrative project, not an audit of a real school or website.
A tester loads the page and presses Tab from the start. Focus moves to Home, Experiments, View Results and the email field, then Subscribe. The Download Schedule link is visually present but never receives keyboard focus. That is one missing stop out of six expected interactive controls; the keyboard tester can reach 5 of 6 in this simplified journey, but the important conclusion is not a ‘83%’ accessibility score. One essential download remains unusable to a keyboard-only visitor.
The team finds that Download Schedule was implemented as a picture with a mouse-click handler rather than a real link. Their repair is to use an appropriate HTML link to the schedule, give the link an understandable accessible name, and then retest. After the change, the tester can Tab to it, see a clear focus indicator and press Enter to open the schedule.
Now examine the email form. The field accepts typing, but after the tester tabs to Subscribe and presses Enter, there is no visible confirmation. Perhaps the form has not submitted; perhaps a message appears elsewhere and focus never moves. The test must check the outcome, not just whether the button was reachable. The team adds a clear confirmation message that is also communicated accessibly and repeats the keyboard journey.
A reproducible student testing method
- Define one visitor goal: for example, download a schedule, locate a cited source or submit a feedback form.
- Start in a predictable state: open or refresh the page, put the mouse aside and note the browser and device used.
- Move forward with Tab: describe each focused link, button and field; ask whether the order makes sense.
- Move backward with Shift+Tab: check whether it is possible to return and whether any menu or modal traps focus.
- Activate controls: Enter commonly activates links and buttons; Space commonly activates buttons and checkboxes. Native controls may use arrow keys. Observe the actual result.
- Check visibility: the highlighted control must remain apparent and should not disappear behind a sticky header or popup.
- Record a precise defect: identify the page, control, expected action, actual behaviour and how to repeat it.
Do not judge an entire site by pressing Tab an arbitrary number of times and counting keypresses. A page may include ‘skip to content’ links, dynamic menus and native browser controls. The meaningful question is whether the visitor can accomplish necessary operations and understand their current position.
What is keyboard focus, and why does the order matter?
Keyboard focus is the element that will receive a relevant keyboard action next. It is commonly shown by an outline, underline, border or other visible change. A page may have links that are individually keyboard-operable yet arrange their focus order in a confusing sequence—for example, jumping from the first menu item to a footer link before reaching the second menu item.
The problem is not simply aesthetic. A visitor navigating without a pointer depends on a logical route. Similarly, a floating banner covering the currently focused button can make the site appear stuck. W3C’s WCAG 2.2 guidance addresses keyboard accessibility and focus visibility; the official easy-checks material is a useful starting point for student review.
Progressive practice: teach one skill, then a whole journey
Guided: identify the focused item
Open a simple page with three normal text links and one button. Press Tab and ask the learner to say aloud which control has focus each time. Then press Shift+Tab to return. If the learner cannot tell, diagnose the focus indicator before asking for faster navigation.
Supported: complete an interaction
On a practice page, Tab to a labelled checkbox, use Space to toggle it, and continue to a labelled Submit button. Activate it with the appropriate key and look for a confirmation. Do not treat a change in button colour as proof of successful submission. Compare the student’s predicted outcome with what actually appears.
Independent: conduct a short acceptance test
Give the learner a fresh school-project page and the goal ‘find the downloadable revision guide, open it, then return to the page’. Ask them to write the keys they used, the route that worked and any failure they encountered. They should distinguish a missing keyboard route from a broken download destination.
Troubleshooting without making the page worse
- Invisible focus: keep or improve the browser’s visible focus indicator; avoid removing outlines without an accessible replacement.
- Unreachable image-button: replace a decorative image-click trick with a correctly named native link or button when that matches the task.
- Focus trapped in a popup: check that the popup’s keyboard interaction is appropriately designed, including a clear exit route.
- Unexpected jumping order: review the page’s structure before adding custom focus-order overrides.
- Form looks complete but is not: test a real submission, validation messages and confirmation, not only the initial controls.
Students should not assume a single keyboard convention works identically in every browser or operating system. Some environments require keyboard navigation settings to expose all controls. On complex widgets, arrow-key behaviour may be expected. Use semantic HTML and consult relevant accessibility guidance instead of inventing keyboard shortcuts.
Parent and teacher next steps
A teacher can assign one team to build the page and a different team to test it using only written visitor goals. The testers should not be told which buttons the creators intended to work. Record defects in a short table: goal, steps, expected result, observed result and retest outcome. Avoid scoring the page based only on appearance.
Parents helping a child make a personal portfolio can ask the child to demonstrate a no-mouse journey and explain one repair in plain language. The progress indicator is concrete: the learner can repeat the journey, identify the focus, activate controls and explain a problem without guessing. Recheck after edits because a newly added component can introduce a new keyboard problem.
Important limits and frequently asked questions
Does passing this test prove that a website is fully accessible?
No. Keyboard testing is only one part of accessibility review. Other checks include screen-reader behaviour, text alternatives, reading structure, contrast, zoom, language, form labels and many additional criteria. A site may pass this exercise and still have serious barriers.
Does the tester need to be a programmer?
No. A student can identify failure by trying a real task and documenting what happened. Repairs may require a teacher, developer or platform editor, especially when a theme or embedded widget controls the behaviour.
Should we make every picture focusable?
No. Decorative images are not interactive controls. Make the actual links, buttons and other interactive elements keyboard-operable; provide suitable text alternatives for informative images as a separate accessibility concern.
Verified learning resources
W3C provides a first-review accessibility checklist explaining keyboard access, focus order and keyboard interaction, and a summary of WCAG 2.2 updates. For a related eduKate skill, read how to write a graph description for a reader who cannot see it. Explore the Education Hub and the diagnosis-to-independent-practice teaching model.
The larger lesson
Making something work for yourself is a starting point. Learning to test it from another person’s position—and using a reproducible check to improve it—is a more mature form of education. A keyboard-only journey gives students a concrete way to practise that responsibility.