The terms control becomes unreachable after opening a policy

Identify the agreement behavior that exists before the link opens

First establish whether the buyer could reach the agreement step before reading the policy. If the control was already inaccessible, opening the policy is not yet established as the trigger. Keep the before and after observations together, using the same checkout, browser and viewport.

WooCommerce documents different terms presentations: its classic shortcode checkout has expandable terms and an acceptance checkbox, while its Checkout block presents an agreement message with links. Confirm the assigned checkout type and any customization. A block checkout without a checkbox is not, on that fact alone, a missing-control defect. Trace the agreement presentation and next relevant control that your installation actually uses.

Follow the opening, reading and return as one path

On the real checkout, stop before placing an order or submitting payment. Reach the policy link using the keyboard and note the control that had focus immediately before it. Record whether activation expands content, opens an overlay, navigates the same tab or opens another tab. These are observations to make, not assumptions about the platform default.

Read the policy and use the return action the interface offers. Note whether that action itself can be reached and operated with the keyboard. After returning, record which page or tab is active, where focus appears and which controls the next Tab and Shift+Tab steps reach. If the focus location cannot be determined, record it as unknown; do not infer that the agreement control was removed. Record any pointer intervention separately so it does not conceal a broken keyboard path.

Use the trace to distinguish the failure

If navigation remains within policy content and never reaches a usable return action, the first unresolved step is leaving that content. If checkout returns but the agreement step is skipped, record the controls reached immediately before and after the skip. If the agreement control receives focus but cannot be operated, the issue is activation rather than reachability. If a pointer can operate it but the keyboard cannot, retain both observations. Each finding gives the implementer a narrower behavior to investigate.

W3C's Keyboard guidance requires keyboard access to functionality, subject to its freehand-movement exception. Its Focus Order guidance requires a sequence that preserves meaning and operability when sequence affects them. Those principles support reviewing the complete policy-return journey. They do not identify the faulty script or require one universal return location for every policy design. A jump is relevant when it prevents or confuses the next operation; a screenshot of the open policy alone does not establish that.

Specify the repaired journey without weakening agreement

Give the component owner the opening action, return action, failing key sequence and affected environment. Define the requested outcome: the buyer can open and read the policy, return using the keyboard, reach and operate the existing agreement step, and continue to the next checkout control. Removing the requirement or automatically accepting it does not demonstrate that navigation was repaired. Preserve the policy link and the intended agreement behavior when scoping the change.

After the repair, check that same journey on the affected browser and viewport without submitting an order. Record where it now works and any remaining limitation. For a Prism checkout-review consultation, describe the observed journey and the assistance requested; implementation responsibilities, scope, fees and terms need confirmation. Keep customer details and payment information out of the public inquiry.

Policy-return focus trace

Complete this for one actual policy-opening journey. Keep before and after observations in the same environment. The first step with no usable keyboard continuation identifies the repair target; an unknown focus location remains unknown until inspected.

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.

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.