By Scott Sumner | AI Findability | Published October 13, 2026

A business owner uses a keyboard to operate a website while the mouse rests in an open drawer. Text: Put the mouse aside. Can customers still finish the task?

A website can look finished while leaving some customers unable to use it. Keyboard accessibility testing helps you find barriers that a design review or an AI screenshot critique can miss.

Answer: Test keyboard accessibility by completing a real website task without a mouse. Check that you can reach and operate controls, see where focus is, and leave menus or dialogs. This is an initial check, not a complete accessibility evaluation.

The useful question is not whether the page looks accessible. It is whether someone can do what they came to do. Start with one important journey, such as choosing a service and requesting a consultation.

Jump ahead

Why a mouse-only review misses customers

During a typical website review, someone shares a screen, clicks through the navigation and opens the contact form. Everything responds. The team approves the page.

That review shows one way of using the site. It does not establish that someone using a keyboard can complete the same task.

W3C’s explanation of WCAG 2.1.1, Keyboard describes why this matters. People who are blind, some people with mobility impairments and people using input devices that emulate keyboards may depend on a keyboard interface. This is about access to the service, not a preference for shortcuts.

The criterion requires functionality to be operable through a keyboard interface, with a limited exception for functions that depend on the path of movement, such as freehand drawing. An ordinary consultation request is not that kind of exception.

Imagine a booking panel where the next step appears only when someone moves a mouse over a card. A customer may read the offer and decide to proceed, yet have no usable way to select it. That is a hypothetical example, not a finding from a client audit.

My view: the website review should include how people operate the page, not just how it looks. Faster AI-assisted builds make that review more important, not less.

Try one journey without the mouse

Choose a task with a clear finish. For example: find the relevant service, open its inquiry form, complete the required fields with test details and reach the confirmation. Arrange any actual submission with your team first, so nobody mistakes it for a customer lead.

Use a desktop browser with keyboard navigation enabled. Browser and operating-system settings matter. If controls appear to be skipped, check those settings before concluding that the website is broken. W3C’s Easy Checks provides browser-specific guidance and explains the limits of a first review.

  1. Move through the page. Use Tab to move forward and Shift+Tab to move back. Can you follow where you are? Does the route through the controls make sense?
  2. Operate the interface. Use Enter for links and the appropriate keys for controls. Buttons commonly respond to Enter or Space; menus and other widgets may use arrow keys. Do not assume every component should work with Tab alone.
  3. Open and leave the interruptions. Try the navigation menu, cookie choices and any dialog along the journey. Can you make a choice and return to the page without reaching for the mouse?
  4. Finish the task. Check the booking or inquiry interface, not just the header. Include any third-party tool a customer must use.

Watch the visible focus indicator: the outline or other cue showing which control will respond to your next keypress. If you cannot see where you are, record that. Keyboard operation, visible focus and avoiding keyboard traps are related but separate things to assess.

Do not rescue the test with a quick click and then call it passed. That click is the moment worth investigating.

Turn a stuck moment into a useful repair request

“The form is inaccessible” may be true, but it gives the person fixing it little to reproduce. A short sequence is more useful.

Here is an example report format, not an actual test result:

On the consultation page, using Chrome on Windows with keyboard navigation, Tab reaches the date field. Pressing Enter opens the calendar. I cannot find a keyboard route to choose a date or close the panel. I expected to select a date and continue to the next field without a mouse.

Add the exact URL, browser and operating system, keys pressed, expected behavior and observed behavior. A short recording can help, provided it contains no customer details.

Have the implementer reproduce the issue before changing code. A hidden focus indicator needs a different repair from a control that never receives focus. A booking vendor’s widget may need a vendor fix or a different integration rather than another style rule on your page.

After the repair, repeat the same sequence. Also test the surrounding controls. Moving focus into a dialog is not enough if closing it leaves the customer lost at the top of the page.

Where AI helps, and where it cannot sign off

AI can turn rough notes into a reproducible issue report, explain unfamiliar interface code and suggest a repair for a developer to review. That is useful work.

A screenshot alone does not contain the interaction. It cannot show whether Tab reaches the booking control, whether a dialog traps focus or what happens after an error. A confident visual critique should not stand in for operating the page.

Give the assistant observations, not a request to invent a verdict. A practical prompt is:

Turn these keyboard-test notes into an issue report. Preserve the exact URL, browser, keys pressed and observed result. Separate observations from possible causes. List any missing information as unknown. Do not claim the page passes WCAG or recommend a code change as verified.

An AI coding tool can propose a fix, but run that fix in the actual interface. W3C’s evaluation-tool guidance is clear that tools cannot check every accessibility aspect automatically. Human judgment is required, and tool results can be misleading.

This fits the broader problem with judging AI-built websites by appearance alone. The tool that generated the interface does not change what customers need from it.

What this check does not prove

Completing one task with a keyboard does not certify a website as accessible. It does not replace screen-reader testing, checking content and contrast, assessing other input methods or involving people with disabilities in evaluation.

Nor is this a legal compliance assessment. It is a practical starting point for finding barriers and giving the team something concrete to fix. W3C explicitly describes Easy Checks as preliminary, not a comprehensive evaluation.

There is also no ranking promise here. Keyboard accessibility matters because people need to use the site. I would not sell it as a secret AI-search trick.

For a business owner, the first step is small: put the mouse aside and follow one important customer journey. Record the first place you need it back. Ask your web team to reproduce that moment.

If you need help prioritizing the website work around discovery and customer action, contact Sumner Digital through Sumner.ai with the page and the task. A website findability audit can frame the broader review; specialist accessibility evaluation is a separate scope, not something a quick scan certifies.

Sources

Primary guidance checked October 13, 2026. This is evergreen analysis, not a new WCAG announcement.