Implement correctly
Build Tooltip without breaking its behavior
# Implement Tooltip in your agent ## Objective Implement Tooltip for this verified behavior: A short, noninteractive hint that appears when a control receives pointer hover or keyboard focus. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Tooltip matches the need before writing code. ## Required behavior - Pointer hover or keyboard focus reveals the information after a short delay. - Escape closes the tooltip without moving focus away from its trigger. ## States to cover - Tooltip hidden - Tooltip visible ## Accessibility - ARIA role: tooltip - The primary control or named region for Tooltip has a stable accessible name from visible text or an explicit programmatic label. - Focus remains on the trigger; the tooltip itself never enters the tab order. - It closes on Escape and after both focus and pointer leave the trigger and surface. - The trigger references the tooltip description so assistive technology can read it without moving focus. - Tab focuses the trigger - Escape dismisses the visible tooltip ## When not to use - The information is essential to completing the task - The content needs links, buttons, or form controls ## Acceptance criteria - The same hint is available on hover and keyboard focus - The tooltip contains no interactive control - Escape closes it without moving focus - Touch users are not denied essential information ## 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-tooltip
- 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 Tooltip on a real journey
# Verify Tooltip after implementation ## Objective Audit the Tooltip 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:2e81d1acb696f4cb278197b5ae3be6f3efcc66b97288e6b4e3be68a4856f80cc