Tutorials
Claude Opus 5.5 dialog focus repair for product pages
Use Claude Opus 5.5 to review a product dialog as a sequence of keyboard states: open, navigate, close and return.
Use Claude Opus 5.5 to review a product dialog as a sequence of keyboard states: open, navigate, close and return. A dialog that looks centered can still strand a shopper behind the overlay or send focus to the top of the page. Give the model the component and a recorded focus trace so its proposed fix can be tested.
Define what each action must do
| Action | Expected result | Evidence to collect |
|---|---|---|
| Open product specifications | Focus enters useful dialog content | Active element immediately after opening |
| Tab and Shift+Tab | Focus stays within the modal | First and last reachable controls |
| Press Escape or visible Close | Dialog closes | Visibility and active element afterward |
| Close after trigger disappears | Focus reaches a logical next target | Replacement target and reason |
The W3C modal-dialog pattern describes contained keyboard navigation and returning focus, usually to the invoking element. If that element no longer exists, choose a logical workflow destination. This is a behavior contract, not a reason to add `aria-modal` to an otherwise nonmodal overlay.
A focus trace for a product sheet
Consider a hypothetical mug page with a “Specifications” button, a long specification dialog and an “Add to cart” button outside it. On opening, focusing a static heading with `tabindex="-1"` may be more useful than jumping far down to the first link. The heading is a programmatic focus target, not an extra stop in the normal Tab order. For a short confirmation, a relevant control may be the better initial target.
Write the trace as: Specifications → dialog heading → Close → care-guide link → Close when Tab cycles → Specifications after Escape. The exact control order depends on the document. If a product change removes the original trigger, record a replacement such as the new product's heading or next relevant control. Do not fall back to an arbitrary page button just to make an assertion pass. This is a fictional test scenario, not a recorded Opus execution.
Keep a visible close control. Clicking the backdrop is not a discoverable substitute for keyboard and explicit dismissal. For a new implementation, inspect the native dialog element and `showModal()`. For an existing dialog library, preserve its lifecycle and focus APIs before adding custom focus-trap code that may compete with them.
A complete repair prompt
Review this product dialog's keyboard lifecycle. I will provide the component, dialog-library version if used, trigger code, relevant CSS and a focus trace for opening, forward Tab, backward Tab, Escape and visible Close. Mark missing runtime evidence as unknown.
Build an action/expected-focus/observed-focus table. Separate initial focus, containment, dismissal and return-focus failures. Explain whether the initial target suits long static content or a short action dialog. Preserve the existing accessible name, visible close control and component API. Do not assume aria-modal alone makes the background inert.
Propose the smallest change using the current library or native dialog behavior. Handle the case where the invoking element is removed, with an explicit logical fallback. Return a patch and keyboard checks for both ordinary close and trigger-removal cases. Do not claim assistive-technology testing unless a real test log is supplied, and do not replace the whole interface without evidence that it is necessary.The official Opus guidance is the model reference for supplying context and explicit requirements. The workflow here is a proposed review method, not a claim that the model has passed these checks.
Test the return path, not just the open state
Run the trace using the keyboard in the actual application. Include repeated open/close, reverse Tab, the longest content, and a state update that removes the trigger. Check focus visibility at each step. A DOM assertion that the dialog exists does not prove that background controls are inaccessible or that focus returned correctly. Record browser and assistive-technology versions for any checks actually performed.
Common questions
**Should focus always go to the first button?** No. Long structured content may need a static starting point; destructive confirmations may favor the least destructive action.
**Is backdrop dismissal enough?** No. Keep an explicit close control and a tested keyboard dismissal path appropriate to the dialog.
**Can an automated focus trace certify accessibility?** It can catch specific regressions. It does not replace checking names, reading order and real assistive-technology behavior.
Keep campaign decisions outside the interaction fix
After the product page works, use the approved product image and message to build campaign variations in Panelly Studio. For failed submissions rather than dialog navigation, use the separate form error recovery workflow. Panelly is a creative workspace in this handoff, not an asserted Opus integration.
