Implement correctly
Build Lightbox without breaking its behavior
# Implement Lightbox in your agent ## Objective Implement Lightbox for this verified behavior: A modal viewer that enlarges one media item and may let the user move through a related collection. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Lightbox matches the need before writing code. ## Required behavior - While modal, keyboard focus stays inside the surface until it closes. - Previous and next controls move through the collection without leaving the viewer. - Escape closes the temporary surface and returns focus to a sensible control. ## States to cover - Gallery view - Media expanded ## Accessibility - ARIA role: dialog[aria-modal=true] - The primary control or named region for Lightbox has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Opening moves focus to the viewer or close control, contains it, and closing returns it to the originating thumbnail. - The named close control and Escape always dismiss; outside press is optional and never the only path. - The viewer title, current item position, caption, image alternative text, and loading failures are available to assistive technology. - Tab reaches viewer controls - Left and Right move between media when documented - Escape closes the viewer ## When not to use - The media must be compared side by side - The content is a form or consequential decision ## Acceptance criteria - The selected media and its caption are clearly identified - Keyboard users can reach navigation and close controls - Focus returns to the originating thumbnail - Loading and media errors have a textual fallback ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- @radix-ui/react-dialog
- Requires · Access to the repository, design system, and tests
Why it works
- The need is tied to canonical behavior before any technical choice.
- States, accessibility, and non-goals prevent a merely visual implementation.
- Acceptance criteria and the output format make verification observable.
Try next
Verify Lightbox on a real journey
# Verify Lightbox after implementation ## Objective Audit the Lightbox implementation against its behavior, states, and accessibility requirements without changing it automatically. ## Checks - Replay the smallest representative journey. - Check keyboard behavior, focus, accessible name, and announcements. - Tie each gap to a specific acceptance criterion. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:8583d38014118d215f3c5852f3f571b5bcf9963a54ee358e460c82c1be214657