The bank authentication window cannot be operated

Describe the obstacle at the challenge boundary

Start with the existing checkout route and the buyer's reported step. Distinguish a challenge that never appeared from one that is present but cannot be used. For the latter, record whether its edge is cut off, a merchant banner covers it, scrolling cannot reach a control, or the visible prompt receives no keyboard focus. Those observations point to different parts of the interface.

Keep the browser and version, device, orientation, viewport dimensions if known, and current zoom setting with the observation. Note whether an on-screen keyboard or an open merchant popup was present. Do not assume that a full-page screenshot represents the portion the buyer could see at that moment.

Record only what was observed in the real interaction. If dimensions, the focused control or the component owner are unknown, say so. A report that a button was unreachable can be useful without inventing a screenshot, repeating a paid transaction or asking the buyer to share private challenge content.

Trace keyboard focus as well as visible layout

W3C's explanation of WCAG 2.2 criterion 2.1.1 calls for functionality to be available through a keyboard interface, with its stated exception for movement-dependent input. A challenge that can be clicked with a pointer but cannot be reached from the keyboard needs a keyboard-access investigation. Visibility and keyboard operability are separate observations.

For an already observed interaction, record the control focused immediately before the challenge opened and where focus went next. Where navigation can be observed without entering secrets or confirming another payment, note the sequence reached by Tab and Shift+Tab. State which visible challenge control could not be reached and whether focus instead stayed behind the window, moved to merchant content or became unobservable.

W3C's explanation of criterion 2.4.3 requires sequential focus order to preserve meaning and operability when the sequence affects them. A focus sequence does not need to be a list of every pixel on the page; it needs to let the buyer operate the required step. Do not label all focus remaining inside a challenge as a defect. The relevant observation is whether its necessary controls and available exit action can be operated.

If the only evidence is that focus could not be seen, record that uncertainty. It does not establish which element held focus or which component caused the problem. The implementer can inspect the affected boundary without asking support to guess at a code fix.

Assign the store container without bypassing the issuer

Stripe's authentication documentation states that the issuer determines the authentication flow. The store's surrounding interface is a separate place to investigate: the checkout layout, merchant overlays, scrolling behavior and the component used to present the challenge. A merchant-owned element visibly covering the challenge gives the implementer a concrete starting point; it does not prove that every part of the challenge is merchant-controlled.

Have the implementer identify the component owner for the obstructed area. If the obstruction belongs to the store, the repair can be scoped to that container or overlay. If the inaccessible behavior is inside a provider or issuer component, preserve the same evidence for the appropriate provider inquiry. Keep an unconfirmed ownership boundary explicit rather than assigning every authentication-window fault to the bank.

The purpose of a repair is to make the legitimate verification step operable. Do not remove authentication, treat it as completed, collect the buyer's code in a merchant field or route the order around the requirement. A visible challenge is not permission for support staff to perform identity verification on the buyer's behalf.

Keep payment state and repair evidence separate

Record the provider payment state associated with the reported time. In Stripe's documented flow, requires_action can indicate a required authentication step; authentication and the subsequent payment have their own outcomes. A clipped or closed window does not establish the final result. Compare the actual provider record with the store order before anyone sends another payment request.

Give the implementer a bounded acceptance condition: the same affected viewport exposes the required controls, keyboard navigation can reach and operate them, and merchant content no longer obstructs the step. Keep the confirmation of those observations separate from the provider's authentication and payment results. Do not create a new purchase solely to gather evidence for this worksheet.

Record what was changed, where it was observed afterward and any component that remains unresolved. A layout improvement does not establish WCAG conformance for the whole checkout, and a successful payment does not establish keyboard access.

A Prism checkout consultation can start with the research-only website, checkout route, non-sensitive description of the obstacle and the owner already investigating it. Confirm any accessibility assessment or implementation scope, responsibilities, fees and terms before work. The inquiry does not itself authorize a repair or determine processing eligibility.

Authentication access record

Use one record for the affected real checkout interaction. Record unknown facts as unknown and describe controls without copying secrets or private URLs. The access finding, component ownership and payment result must remain separate.

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.