Axismundi · Lab module

Tooltip (v3.4.6)

Hover/focus descriptive tooltip runtime. Lab module only — not promoted to baseline. Different trigger model from popover: does not move focus, uses aria-describedby, not role="menu". See docs/TOOLTIP-AUDIT.md for rationale, Beer CSS intake notes, and a11y risk register.

Theme:

Plain tooltip — hover on icon button

Icon-only buttons get tooltip exposure of their aria-label (Decision B selector). Hover or focus the buttons below; the singleton tooltip appears above the trigger, anchored center, with 8px gap. Inspect the trigger's aria-describedby attribute in DevTools — it should equal lab-tooltip-singleton while visible and disappear on hide.

Plain tooltip — explicit `data-tooltip`

Any element with a data-tooltip attribute is wired, regardless of tag. This is the universal opt-in route. data-tooltip wins over aria-label if both are present.

Keyboard focus path

Tab through the buttons below. The tooltip shows on focusin and hides on focusout — independent of pointer position. Focus stays on the trigger throughout. Escape dismisses the visible tooltip (the trigger keeps focus and the next Tab moves forward as usual).

Forbidden-ancestor bail-out

Triggers placed inside .prose or [contenteditable] must be ignored by the tooltip runtime. Charter §5, §6 — federation content surfaces and WordPress block editor regions cannot surface theme-side tooltips inside user-authored content.

Rich tooltip — visual specimen (not wired at v3.4.6)

The rich variant carries a subhead, supporting text, and action buttons. Its interactive wiring (Tab into actions, Escape with focus restoration, hover into tooltip body without dismissing) is intentionally deferred — see BACKLOG #16. The specimen below is rendered statically with is-open so the visual primitive can be audited against M3 §34.3 without the runtime layer.