Find the first checkout function the keyboard cannot operate
Trace the same checkout path using only the keyboard and record the first required function you cannot reach or operate. Include payment choice, required agreements and the submission control. A button receiving focus does not prove it works, and a disabled button may reflect an unmet prerequisite rather than a keyboard defect. Preserve the page state, keys used, last working control and observed result so the repair owner can reproduce the actual obstacle. Mark everything beyond an unpassed step as unverified.
For: Research-only store owners and the people maintaining a checkout where a buyer reports needing a mouse to continue.
Record the checkout URL without private tokens, browser and operating system, date, checkout type and payment method shown. Note whether the report concerns guest checkout or an account, and which required fields or agreements were already completed. Those facts define the route being investigated; a successful path through a different payment method does not resolve the reported one.
W3C’s Understanding Keyboard guidance for WCAG 2.2 criterion 2.1.1 explains that functionality needs a keyboard equivalent, subject to its exception for input that depends on the path of movement. Selecting a payment method, accepting a required agreement and invoking submission are actions to include in the trace. The exception is not a general reason to leave checkout buttons dependent on a mouse.
Use the real checkout state you are authorized to inspect. Do not invent customer data or create a purchase simply to fill the worksheet. You can inspect navigation before committing an order. If actual submission is not exercised during a genuine authorized purchase, record it as unverified rather than claiming the checkout can be completed.
Record what each key actually does
Begin before the reported obstacle and write the sequence of controls reached. Use Tab and Shift+Tab to observe sequential navigation, and the appropriate control keys or any instructions the interface provides for activation and selection. Some choices use arrow keys within a group; failure to encounter every choice as a separate Tab stop is not enough to diagnose a missing keyboard function. Record the keys and outcomes instead of assuming one key operates every widget.
For payment selection, capture whether the choice can be reached, changed and retained when the corresponding fields appear. For an agreement, capture whether the buyer can reach the actual control and change its value. Opening the linked policy is not the same action as accepting an agreement. A static agreement message is also different from a required checkbox; trace the controls the installed checkout really presents.
Do not use a mouse to bridge a failing step and then label the whole path completed by keyboard. Preserve the first failure. If a separate pointer comparison is needed to describe the difference, label it separately so it cannot hide the keyboard barrier.
Distinguish reachability, activation and readiness
An unreachable control, a focused control that does nothing and a correctly disabled control are different observations. Note which required information is missing, what message the page shows and whether the control becomes available after the prerequisite is legitimately met. Do not remove an agreement or payment requirement merely to make the button active.
If you cannot tell where focus is, record that uncertainty. Do not conclude the control is absent from keyboard navigation solely because no indicator is visible. A focus-visibility investigation may be needed to identify the actual target. Similarly, if focus jumps away after a selection, preserve the action and resulting location; that is more precise than saying the payment button is broken.
The first unavailable function is the repair target even when it prevents observing later steps. If a payment choice cannot be selected, the submission result remains unknown. If submission is reachable but not activated because it would place an order, that is a deliberate observation boundary, not evidence of either success or failure.
Give the component owner a reproducible handoff
Connect the obstacle to the component that presents it: the store’s checkout, a theme or extension control, or an embedded provider field. Record the component and installed version when known. If ownership is uncertain, assign someone to identify it; do not assume the store theme controls every payment field. Include the last working action and the first failing one in the handoff, without capturing payment details.
Ask the responsible maintainer to restore a keyboard path to the same required function. After a change, verify that affected path in its actual checkout context and retain the observed result. Reaching the control is insufficient if selection or activation still fails. A completed trace answers this particular report; it does not establish conformance of every checkout state or satisfaction of an accessibility law.
For a Prism checkout-review consultation, describe the blocked function, checkout type and evidence already available. Confirm the scope of any requested assessment or implementation, along with responsibilities, fees and terms, before work begins. Technical operation and processing eligibility remain separate decisions.
Keyboard completion trace
Record the keys, focused control and actual result for the reported checkout path. Stop the claimed keyboard completion at the first barrier. Mark later steps not reached, and mark submission unverified if no genuine authorized submission was observed. Keep values entered into payment fields out of the record.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Keyboard completion trace. The last column is for temporary notes.
Checkout step
Expected action to trace
Evidence and interpretation
Your observed sequence and owner
Starting state
Expected action to traceEnter the same guest or account checkout path described in the report.
Evidence and interpretationRecord browser, checkout type, visible method and completed prerequisites; omit private URL tokens and customer values.
Payment choice
Expected action to traceReach the available choices and select the intended approved method using its keyboard controls.
Evidence and interpretationRecord keys, focused control, selected option and whether the associated fields appear. A selected default does not prove the choice can be changed.
Required agreement
Expected action to traceReach and operate any required agreement control the checkout actually has.
Evidence and interpretationRecord label, keys and changed state. Distinguish a policy link or static message from an acceptance control.
Required payment fields
Expected action to traceReach the fields belonging to the selected payment component.
Evidence and interpretationRecord entry and exit of the component and the unavailable function; never record payment data or authentication codes.
Submission control
Expected action to traceReach the final action and establish whether it is ready and keyboard-operable.
Evidence and interpretationRecord focused control and readiness separately from activation. Mark actual submission unverified unless observed in a genuine authorized purchase.
First unreachable or inoperable function
Expected action to traceIdentify the earliest required action the keyboard trace could not complete.
Evidence and interpretationPreserve last working control, keys pressed, expected action and actual result. Do not count a mouse-assisted continuation as keyboard completion.
Repair owner and observed result
Expected action to traceAssign the component owner and describe the function the repair must restore.
Evidence and interpretationRecord the actual result after the affected path is checked; leave unobserved later steps open.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
This is a record of one checkout path, not a complete WCAG assessment, certification or determination of applicable law.
Do not create an order or payment solely to complete this worksheet. An unobserved submission remains unverified.
Do not include card numbers, security codes, authentication codes, payment-link tokens or customer records in screenshots, the worksheet or the public consultation form.
WCAG 2.2 understanding, keyboard — checked 2026-09-21. Understanding criterion 2.1.1 explains keyboard availability of functionality and a keyboard equivalent for pointer actions, subject to the specified movement-path exception. It does not establish the behavior or conformance of this merchant’s checkout.