Tutorials
Claude Opus 5.5: Repair Keyboard Navigation in a Product Carousel
Give Claude Opus 5.5 a carousel's DOM, interaction code and an explicit state contract.
Make it with Panelly
Turn inspiration into your next product ad
Bring a product image and an idea. Create a four-panel ad, a coordinated asset set, or a video with Panelly.
Create with Panelly Edit the brief before you generate.
Give Claude Opus 5.5 a carousel's DOM, interaction code and an explicit state contract. Ask it to repair focus and rotation together. Adding a keyboard listener to the arrows will not fix invisible links receiving focus or a carousel that restarts while somebody is reading a slide.
Observe the failure before changing the widget
A 2016 developer question describes a carousel whose arrows work only with a mouse. It documents a concrete old-library problem, not a recommended modern patch. For current behavior, use the W3C carousel pattern: ordinary Tab navigation, native controls where possible, and a rotation control before the rotating content.
| Symptom | Likely repair boundary | Verify |
|---|---|---|
| Tab reaches an unseen purchase link | Inactive slide exposure | Only active content enters the normal Tab sequence |
| Next moves focus into the new slide | Control activation | Focus remains on Next |
| Rotation resumes after keyboard focus leaves | Automatic rotation state | Explicit user action is needed to restart |
| Mouse hover pauses but keyboard focus does not | Pause trigger coverage | Both interactions stop rotation |
Do not hijack every arrow key at the page level. A basic previous/next carousel and a tabbed slide picker have different keyboard contracts. Decide which pattern you actually implement before generating a patch.
Make the pause state persistent
For an illustrative four-slide gallery with two links per slide, simply moving three slides offscreen can leave six invisible links in the Tab sequence. That is a count of this invented layout, not an audit of a live store. Hiding content visually or adding `aria-hidden` alone is not a complete focus solution. Use a rendering or inactive-state strategy that removes inactive controls from keyboard navigation and exposes the active slide correctly.
Define `activeIndex` and whether rotation is running. Focus entering the carousel stops rotation; moving to Next changes the index without relocating focus. Leaving the carousel does not restart it. An explicit Start action can resume rotation according to the control's design; subsequent focus entry stops it again. Handle hover pause as well. For this example, reduced-motion preference disables automatic rotation initially; that is an additional chosen behavior, not a substitute for pause controls.
A complete implementation-review prompt
Review the supplied product carousel DOM, CSS and state handlers. Use a basic previous/next pattern, not a tabbed picker unless the existing design requires one. Preserve slide order, links, product IDs and selected variant.
List all focusable controls in active and inactive slides. In our illustrative 4-slide/2-link case, identify the six inactive links that must not remain in the normal Tab sequence. Do not treat aria-hidden alone as a keyboard fix.
Use native buttons for Previous, Next and Start/Stop rotation. Keep focus on the activated control. Stop rotation on focus entry and hover; do not automatically restart after focus leaves. Require explicit Start to resume. Initially disable automatic rotation for reduced-motion users in this design.
Return the smallest patch, state-transition table and tests. Test forward/reverse Tab, Enter/Space on buttons, repeated Next, first/last wrap behavior, focus pause, explicit restart and reduced-motion startup. Distinguish executed browser checks from proposed tests. Do not claim whole-site accessibility certification.This is a hypothetical Opus task, bounded in the style of the official prompting guide. A small local state fixture can validate the proposed transitions; it cannot prove the real DOM, screen reader or timer implementation works.
Check the delivered component
Start outside the carousel and Tab through it in both directions. Verify visible focus and meaningful button names, then activate Next repeatedly and confirm the focus never disappears. Pause during a long product description and wait beyond the normal rotation interval. Test the explicit restart action separately. Repeat with reduced motion and with the actual small-screen layout. Record the browser and observed sequence, not just a passing screenshot.
**Must every slide use arrow-key navigation?** No. Follow the chosen pattern; native buttons already support normal activation.
**Can all inactive slide links keep `tabindex=0`?** Not if they are offscreen and unavailable. Make visual availability and keyboard exposure agree.
Prepare the slide artwork in Panelly Studio, then test the real carousel separately. Touch-target spacing addresses button geometry; it does not establish keyboard behavior. No Panelly–Opus integration is assumed.
