Choose one visitor task. Put the mouse aside and follow that task with the keyboard. Record where you can move, what you can activate and where you lose your place.
You should finish with a route another person can repeat, a precise issue record and a recheck plan. A page that looks finished can still leave a visitor unable to reach its next step.
For a ClickFunnels AI project, this gives your builder specific behavior to inspect. It does not establish how a generated page works. The tool-care enquiry page below is fictional; its observations illustrate a review record, not tests performed on a real funnel.
Pick the task and the stopping point
Use a sentence such as: Read the service details, choose a service, correct a missing answer and reach the enquiry result. List the exact page version and the controls needed for that route.
Before activating a form, establish where a permitted check can run and what submission may trigger. A preview label alone does not prove that messages, records or other actions are disabled. If the effects are unknown, stop before submitting. You can still document navigation observations and leave submission recovery untested.
Write down the operating system, browser version and keyboard-navigation settings. Confirm that your setup allows keyboard navigation to page controls. Settings vary; use the current instructions for your environment rather than treating a skipped link as proof of a page defect.
W3C's keyboard guidance explains why functionality needs a keyboard route. The practical question here is whether the visitor can complete this particular task without reaching for the mouse.
Walk the route and keep your place
Start at the page address. Use Tab to advance between controls and Shift+Tab to move back. Watch for a visible indication of the current focus. Use the normal keys for the control: links commonly activate with Enter; buttons commonly support Enter and Space; choices may use arrow keys. A custom widget can have a different interaction pattern, so record what you tried.
Do not expect Tab to stop at every paragraph. You are inspecting the interactive path. Note a control you cannot reach or operate, an unexpected jump, or a point where focus becomes hard to locate. If you use the mouse to recover, mark that point instead of silently continuing as though the keyboard route succeeded.
W3C's focus-order explanation centers on preserving meaning and operation. There can be more than one sensible order. Report the confusion it creates instead of assuming every difference from the visual layout is a failure.
Make the fictional route explicit
Imagine a Garden Tool Care Enquiry page, version A. A visitor can read service details in a modal dialog, then request a review of a hand tool. The example's form has a service choice, a short description and a reply address.
These invented notes show how to record five checkpoints. They do not establish any saved request or delivered reply.
Scroll horizontally to compare all columns.
| Checkpoint | Proposed keyboard action | Fictional note from version A |
|---|---|---|
| K01 — Service details | Reach and open “What can be serviced?” | Trigger is reachable; dialog opens |
| K02 — Return to the page | Close the dialog and continue | Focus returns to the trigger; next Tab reaches the service choice |
| K03 — Service choice | Select “Hand-tool sharpening” | Choice changes; the page does not submit or navigate |
| K04 — Missing description | In the permitted test setup, attempt the form with the required description empty | Error appears, but focus is no longer visible; reviewer uses the mouse to find the field |
| K05 — Correct and continue | Add the description and activate the enquiry action | Not run in the keyboard pass because K04 interrupted the route |
K05 is not run, not failed. The hypothetical interruption at K04 gives the page owner a specific problem to reproduce. A mouse-assisted submission afterward would be a separate observation.
Check what happens when an overlay opens
If the route uses a modal dialog, inspect entry, movement inside it and the way back. The W3C modal-dialog pattern describes focus moving inside on open, Tab staying within the active dialog, Escape closing it and focus normally returning to its trigger. It also describes cases where a different return point serves the next task.
An ordinary expanded section is not automatically a modal dialog. Identify the component before applying that expectation. For the fictional service-details dialog, returning to its trigger makes sense because the visitor continues to the enquiry form.
Record the exact trigger label, closing action and next focused element. “Popup is awkward” does not tell a builder where to start. If you cannot leave an active component with the keyboard, capture the route to that state and stop that case.
Follow a correction through to the next action
In a permitted test environment, try the chosen missing-answer case. Can you locate the explanation, reach the affected field, correct it and continue? Note whether unrelated entered values remain available.
W3C's form-notification guidance calls for clear feedback that helps people understand and resolve an error. The page's correction path needs observation as well as readable wording.
Keep this result narrow. Reaching a confirmation with the keyboard establishes the visible interaction you observed. It does not prove that the right record was stored, a message arrived or a booking was made. Those need separate evidence from the relevant destination.
Turn a problem into a useful handoff
For K04, a fictional issue record could read:
Version A, enquiry form, K04. Starting at the reply-address field, leave Description empty and activate “Send enquiry” using Enter. The description error appears. No focus indicator is visible. Repeated Tab presses do not make the correction path clear to the reviewer. Mouse recovery was used; the keyboard case stopped. Expected: a visible, understandable route to correct Description and continue.
This describes the observed symptom without inventing its technical cause. Add the actual environment, starting values, evidence location and responsible person when you run your own check. Keep test details and any recordings free of unrelated personal information.
The builder may need to inspect focus handling, markup or styles. A proposed fix is still a proposal. After it changes, repeat K04 from the same starting state on the new version, then continue through K05. Recheck the earlier dialog return too if the changed component is shared.
Keep the result as small as the evidence
Use not run, blocked, observed as expected or issue observed for each checkpoint. Add the reason and version. A blocked submission check should not erase a useful navigation observation, and one working route should not stand in for every page.
W3C's Easy Checks explicitly describes a preliminary review with limited coverage. This keyboard exercise is not a complete accessibility evaluation or certification. Screen-reader use, zoom, contrast, media and other tasks need appropriate additional evaluation. A screenshot alone cannot verify keyboard behavior.
Use the keyboard-path worksheet to prepare the route and retain the issue/recheck record. Bring that record into your ClickFunnels AI project instructions alongside the agent guide, subject to its access and workflow requirements. Give the builder one reproducible obstacle and the observation that will show whether it has been resolved.