Motta Industries Blog

Put the mouse aside for one important website task. Can you reach the controls, tell where you are, use them, and leave without getting stuck? A short keyboard accessibility test can reveal a concrete barrier that a visual review misses.

Ten minutes is a practical timebox, not an accessibility certificate. You will examine one route under recorded conditions, not every page, browser, assistive technology, or requirement. Finding no problem in that route does not establish that the website is fully accessible. Finding a reproducible problem gives the team something useful to investigate.

Choose a modest task before starting: find a service, open an information panel, or work through an approved test form. Avoid real purchases, customer records, or actions that change live business data. Keep a notebook ready and record what you actually observe rather than what you expect the site to do.

Minute zero: set up a meaningful check

Record the page, browser, operating environment, and viewport. Keyboard navigation settings differ between environments, so establish that the browser is configured to navigate the relevant controls. If the setup is uncertain, document that limitation instead of treating every missing stop as a website defect.

Choose the starting point and expected destination. Close unrelated panels and make sure you know how to return to the beginning without changing live information. The exercise should follow the same route after a repair so the developer can compare like with like.

Motta Industries’ user-experience design services provide a useful context for discussing that route. The important question is what someone must accomplish, not whether the page looks modern. A defined task keeps a quick check focused enough to produce actionable observations.

Keep the task small enough to observe carefully. Opening every menu in ten minutes will usually produce weaker notes than following one defined route. If the first barrier blocks further progress, documenting that barrier is a valid result. The remaining route stays untested; it does not become a failure or a pass by inference.

Minutes one and two: enter and locate yourself

Use Tab to move into the page and note the first meaningful keyboard stops. Look for a visible indication of which control has focus. Continue far enough to understand whether you can identify the current control without guessing from the last place you remember seeing it.

The fixed October 2023 WCAG 2.2 Recommendation contains criteria for keyboard operation, focus visibility, focus order, and avoiding keyboard traps. These are separate concerns. A control receiving focus is not necessarily usable, clearly indicated, or positioned in a meaningful sequence.

If the indicator disappears, record the control or last known stop and the steps that led there. Do not quietly switch to the mouse and count the route as successful. A workaround can help you continue investigating later, but it is not evidence that the original keyboard route worked.

Minute three: follow the sequence both ways

Move through the relevant controls with Tab, then use Shift and Tab together to move backward. Ask whether the order preserves the meaning and operation of the task. The sequence does not have to imitate every visual arrangement, but it should not leave the user unsure how related actions connect.

Note unexpected jumps, repeated navigation, or a control reached only after a long detour. A skip link may provide a helpful route past repeated material. Test what it actually does rather than assuming its presence alone resolves navigation concerns.

Record the sequence in ordinary language: navigation, search, product option, enquiry link. You do not need to diagnose the code during the ten-minute check. A clear account of where the route becomes confusing is more useful than an unsupported claim that the entire keyboard order is wrong.

Minutes four and five: activate ordinary controls

Try the controls needed for your selected task. Ordinary links typically activate with Enter, while standard buttons commonly support Enter or Space. Other widgets may use documented arrow-key patterns. Do not assume every interactive item must behave identically or appear as a separate Tab stop inside a composite widget.

The fixed February 2015 H91 technique for HTML controls and links explains how standard elements support keyboard behavior and assistive-technology interoperability. It is an informative technique, not an additional requirement or the only conforming implementation. Custom behavior still needs appropriate verification.

Observe the result. Did the expected panel open, option change, or destination appear? Can you identify the new state and continue? A control that looks active but does nothing with the appropriate keyboard input deserves a specific record, including the relevant state and the key used.

Watch the difference between navigation and activation. Reaching a control with Tab should not be confused with choosing it. If merely arriving changes the task unexpectedly, write down that behavior separately from the control’s response to an activation key. It may require a different explanation and remedy.

Minute six: open a menu or dialog

If the route includes a menu, disclosure, or dialog, open it and follow its intended keyboard interaction. Check whether the new content can be understood and operated, and whether you can close it using the supported pattern or an accessible control.

An open dialog may intentionally keep focus inside while it is active. That is not automatically a keyboard trap. The question is whether an appropriate keyboard exit exists and the interaction allows the user to continue meaningfully afterward. Do not assume Escape is the required exit for every possible component.

Record what happens after closing. Focus should return or move in a way that supports the task rather than disappearing into an unexplained location. If you are unfamiliar with the widget’s intended pattern, mark the uncertainty for qualified review instead of declaring a failure solely because it differs from an ordinary link.

Minute seven: check for a real trap

The fixed February 2015 G21 keyboard-trap technique addresses entering content and being able to leave it through the keyboard. The underlying WCAG criterion also addresses guidance when an exit needs more than standard methods. A mouse-only escape is not the same as a usable keyboard route.

If movement repeatedly cycles without an accessible way to continue or close the component, record the steps and stop that part of the exercise. Do not spend the remaining time improvising increasingly unusual keys and then report success because you eventually escaped by accident.

Distinguish an observed trap from a component whose documented interaction you have not yet checked. The quick test should create a reliable issue or a clearly stated question, not turn incomplete knowledge into a confident diagnosis. Developers need both the reproduction route and the limits of your observation.

Embedded content deserves the same attention as the surrounding page. A third-party calendar or media panel may create the interruption even when the main navigation works. Record the embedded feature and entry route without assuming which supplier or layer caused the defect. Responsibility for investigating it still needs a named owner.

Minute eight: examine an approved form state

On a test form or another authorized nontransactional route, move through labels, inputs, choices, and the relevant action. Check whether the instructions explain what is needed and whether the controls can be operated without the mouse. Keep private information out of the test and its screenshots.

Where an approved test permits validation, observe an error state. Can you find the problem and the field that needs attention? Do not submit a live customer request merely to trigger an error. Record when validation was not tested rather than pretending that reaching the submit button established the whole form’s behavior.

A keyboard check does not replace testing with assistive technologies. Labels, names, error relationships, announcements, and other requirements need appropriate evaluation. The narrow question here is whether the observed route can be followed and operated under the stated conditions.

Keep test results distinct from customer impact evidence. You can describe a blocked enquiry route without inventing a conversion loss or claiming how many people encountered it. If the business later gathers relevant evidence, attach that separately and protect personal information. A reproducible barrier is worth investigating without speculative statistics.

Minute nine: inspect the active control while scrolling

Look for persistent headers, banners, and panels that may cover the focused component as the page scrolls. Also check that the focus indicator remains useful on the backgrounds encountered in the selected route. Being somewhere on the page is not the same as being visibly locatable.

If the task depends on a narrow layout, repeat the relevant portion at a recorded narrow viewport when practical, or schedule it as a separate check. Do not claim that the original desktop run established mobile behavior. Keyboard input can be relevant on mobile devices too.

Discuss responsive design when a layout change causes the barrier. Keep the finding specific: which control, which state, and what obscures it. A screenshot of the whole page is less helpful than a reproduction showing the active control and the content hiding it.

Minute ten: turn notes into a repair request

Separate three outcomes: observed problem, unresolved question, and behavior that worked within the limited check. Include the task, environment, starting point, steps, expected behavior, observed result, and relevant evidence. Remove private information and identify any part of the route you did not test.

For example, a useful hypothetical note would identify the enquiry panel, the recorded browser setup, the steps used to open it, and the point where no keyboard exit could be found. Add whether you checked the documented interaction or left that unresolved. That note is not a finding about any actual Motta Industries page.

Keep one issue per record when problems have different reproduction paths. Combining an unclear indicator, an inaccessible menu, and an unrelated form error into one vague complaint makes verification harder. Group related evidence, but preserve enough separation for a maintainer to retest each behavior after a change.

The request does not need a proposed code fix. It needs enough detail for someone else to reproduce the issue and determine the appropriate remedy. After a repair, repeat the original steps and check nearby behavior so that a local change does not introduce another obstacle.

Agree what will count as resolution before closing the issue. The original route should work under the recorded conditions, and any newly discovered limitation should be documented rather than hidden by a changed test. Broader accessibility evaluation remains separate. A successful retest answers the observation; it does not turn the rest of the website into an evaluated surface or establish compliance with every criterion.

Use Motta Industries’ contact page to describe the route and findings when you need help. Ten minutes should leave you with a more precise question or a verifiable issue, not an unsupported accessibility score. Keep the limits visible and use the result to guide the next appropriate evaluation.