Keyboard enquiry path: identify the first recorded blocker

A keyboard enquiry path needs evidence of operation, not just a visible focus indicator. Use a fictional four-step record to save the first recorded blocker, unobserved stages and an owner handoff without testing a live form or approving a whole website.

Content last updated: 17 October 2026.

What does a keyboard enquiry path review decide?

A service page may offer an obvious quote button without evidence that someone can use it to reach the enquiry form by keyboard. A useful review separates the business action from the appearance of its controls. We will identify the first recorded transition that fails, rather than give an entire website a pass or fail.

Our input is a fixed fictional observation card. It describes a primary call to action, or CTA, and the intended route toward form fields, submission and a result. Focus means the element currently receiving keyboard interaction. A visible focus indicator tells you where interaction is directed; it does not establish that the intended action occurred.

You will not open a live form, send an enquiry or conduct a participant study. Your deliverable is an issue-and-owner handoff: what the supplied record shows, which transition first blocks the declared task, what was never observed, and what the implementation owner needs to reproduce.

The conversion optimization guide already covers choosing an enquiry journey and an observed obstacle. This exercise is narrower than that general advice. It concerns keyboard reachability versus activation and the evidence boundary of later steps, not a conversion experiment, new layout or predicted improvement in sales.

Fix the essential action and the evidence boundary

Write the intended action before reviewing individual controls: reach the enquiry form from this service page's primary button and submit an enquiry. The presence of another contact method would not prove this particular route works. Our teaching input supplies no alternative route, so do not invent one to clear the finding.

Use page version V1 and preserve the given step order. No account creation, payment or document upload is included. Browser and device details are unspecified. That missing environment information belongs in the handoff; it is not permission to claim the same behavior in every browser.

• The owner's declared main action and the page version.
• A stable identifier for each supplied step.
• The attempted keyboard action and its observed result.
• The expected transition and the furthest stage actually reached.
• Missing environment details and the question needed for reproduction.

Separate evidence from diagnosis. A note saying that a button did not open a form does not tell you whether its event handling, markup, an overlay or another condition caused the result. You do not need to guess the code to prepare a useful issue.

The Typeform service-routing guide tests answer branches and endings. Those routing checks happen within a different decision. Here the supplied record may stop before the form even opens, so a sensible branch map cannot substitute for evidence that the essential interaction begins.

Read the four-step fictional observation card

The fictional primary control is a button with the visible wording Request a quote. In K1, the supplied Tab trace reaches it and shows a visible focus indicator. Record that limited success. The enquiry form has not yet opened, and no submission has occurred.

K2 supplies two activation attempts, Enter and Space. Neither opens the form in the teaching record, and no alternative keyboard instruction is supplied. Preserve those facts without claiming every possible shortcut was tried or treating the record as an observed result from a named browser.

K3 and K4 remain visible in the record because they are part of the intended journey. Their presence is not evidence that they were tested. Do not describe an error banner, field label or confirmation screen that the input never supplies.

The Canvas checklist prototype already includes a short Tab, focus and Space check. A generic keyboard tutorial would therefore add little. Our different result is a business-path handoff that preserves where the essential journey stops and why all downstream evidence remains unavailable; no prototype is generated or repaired here.

Why is K2 the first blocker rather than K1?

Compare each observation with its own expected transition. K1 expects focus to reach the button, and the card says it does. K2 expects the supplied activation attempts to open the form, but they do not. The first recorded failure to advance the declared task is consequently K2.

Use a bounded decision: reproduce and address this recorded essential-action block before promoting this route. That is a proposed work priority based on the teaching evidence. It is not a universal advertising rule, an instruction to stop every campaign, or proof that the website fails an entire accessibility standard.

Do not change the conclusion to path ready merely because the focus indicator looks clear. Reaching a control and operating its function are separate observations. Equally, do not label the remaining form broken. The trace never reaches it, so it supports no finding about its actual field behavior.

Leave the cause unresolved. An invented missing click handler or tab-order value can send the implementation owner toward the wrong repair. Provide the attempted actions and expected form opening instead. Ask the owner to establish the environment and reproduce the observation before deciding the cause.

The Google Forms upload walkthrough verifies a dummy document submission and reviewer access. That is not what happened in this fictional record. A successful confirmation in an unrelated intake process cannot fill K4's missing evidence.

Distinguish a recorded block from missing observations

If the input did not say what happened after an activation attempt, you could not infer a failure merely because the next row was blank. The appropriate result would be evidence missing. In this fixed case, the attempt and the non-opening result are explicitly supplied, so there is a concrete recorded block to hand over.

After a repair, repeat the affected activation step and then cover the remaining enquiry journey. A repaired opening button does not automatically establish operable fields, recoverable errors or a clear confirmation. Keep those stages unobserved until separate evidence exists.

• No activation observation: hold the finding and request evidence.
• Supplied essential action does not advance: identify the first recorded block and request reproduction and repair.
• Later stage not reached: preserve unobserved, not passed or failed.
• A complete preliminary trace without a recorded block: consider wider assessment, not blanket approval.

The alt-text context review makes decisions about image alternatives and deliberately avoids certifying a website. This exercise keeps the same honesty boundary but examines a different object: a sequence of interactive transitions. Correct image text cannot prove that a form can be operated, just as a keyboard trace cannot validate every image alternative.

What do the W3C documents support?

W3C's Easy Checks describes keyboard access, visible focus, sequence and forms as preliminary review areas. It explicitly limits quick checks: apparent success can still leave substantial barriers. The source supports separating focused interaction from functioning actions and recording what still needs assessment.

The readable page displays an update of 9 August 2023 and a notice pointing to a newer draft. Some browser and toolbar instructions are legacy material. We do not turn those recipes into claims about current menus or universal keyboard settings. The conceptual distinctions and review limits are the relevant support here.

The retained WCAG 2.2 Recommendation displays 12 December 2024. Its keyboard, focus, input-label and error criteria provide normative context. Both documents come from W3C, not two independent publishers. Reading them does not establish that this fictional card is a complete conformance assessment, a legal opinion or evidence of a disabled participant's experience.

Save a concrete issue-and-owner handoff

On Windows, open Start, search for Notepad and launch it. Create a new blank document headed Enquiry path V1, fictional observation card. Copy the declared task and K1 through K4 before writing the finding. Someone receiving the note should be able to distinguish the original observations from your proposed next action.

Page V1; essential action: open the enquiry form through the primary button.
K1: visible focus reaches the button; activation is not established.
K2: supplied Enter/Space attempts do not open the form; first recorded blocker.
K3/K4: not reached; unobserved.
Cause: unknown. Browser/device: clarification required.
Owner role: website implementation; no real assignment made.
Next: reproduce K2; after repair, repeat and cover the remaining journey.
No real form submitted; no whole-site approval.

Press Ctrl+S, choose Documents, enter enquiry-path-V1.txt and select Save. Close Notepad. Open Documents in File Explorer and double-click enquiry-path-V1.txt. Check that K2 remains the first recorded blocker and K3/K4 remain unobserved. A later source update belongs in a new version with its reason, not a silent rewrite of V1.

A suggested fifteen-minute allowance gives four minutes to the supplied scope, four to locating the first block, four to the handoff and three to saving and reopening. This is a cognitive planning budget, not measured participant speed. There is no browser automation, actual customer enquiry or claimed usability result.

In earlier public writing I described projects delayed by chasing perfection. Applying that principle here means finishing a small, inspectable finding rather than declaring a whole website perfect. It does not claim a personal accessibility implementation or a measured customer outcome.