Avoid tooltip and focus traps

Popover is a presentation behavior, not a complete tooltip, menu, combobox, or dialog component. Each of those patterns has different expectations. The safest native interface begins by identifying the actual job.

Essential instructions belong in visible text. Brief supplemental text can be associated with a control through aria-describedby, but hover-only help excludes keyboard, touch, zoom, and speech-input users. An interactive panel belongs behind a button and must be reachable, dismissible, and understandable without hover.

<p id="archive-help">Archived tasks remain available from the filter.</p>
<button type="button" aria-describedby="archive-help"
        popovertarget="archive-options">Archive options</button>
<div id="archive-options" popover>
  <button type="button">Archive this task</button>
</div>

Avoid title as the only explanation. Its presentation is inconsistent and often unavailable to touch and keyboard users. Visible text is easier to discover, translate, select, zoom, and test.

Do not place a text input or multi-step form in a panel that disappears on an innocent outside click unless that loss is expected and harmless. A dialog or inline region may fit better when the user is making substantial changes.

Test at 200% and 400% zoom, with keyboard only, and with reduced viewport height. The panel must not hide its last action off-screen. Escape should dismiss an auto popover, and focus should land somewhere meaningful after the invoker or target is removed.

Audit every transient panel in the board. Write down whether it is optional help, an action group, a form, or a blocking decision. Keep only the action group as a popover, move essential help into the document, and move the blocking decision into a dialog. Test each decision with touch as well as hover, since touch makes accidental hover-only assumptions obvious. If you need extensive key handling to make a fake menu work, return to ordinary buttons and links.