[@mantine/core] Tooltip: Rename interactive prop to hoverable and fix interactive-content guidance - #9110
Open
andrewborstein wants to merge 2 commits into
Open
Conversation
…active content The docs, demo, and prop JSDoc added alongside the `interactive` prop (mantinedev#9072) encouraged placing interactive content inside a tooltip — the docs used "for example a link", and the demo rendered an `<Anchor href>` inside the tooltip. Interactive/focusable content in a tooltip is inaccessible: the tooltip is exposed to assistive technology only as an `aria-describedby` description, is not in the focus order, and is dismissed on `Escape`, so its content cannot be reliably reached by keyboard or screen reader users. Reframe the `interactive` prop around what it is actually for: satisfying the *hoverable* condition of WCAG 1.4.13 so the pointer can reach the tooltip body without dismissing it (e.g. to read or select its content). The previous wording also misstated WCAG 1.4.13 as applying only when the tooltip contains interactive content; the criterion applies to any content shown on hover. Interactive content must be reachable by keyboard and touch, not hover alone, so it does not belong in any hover-triggered element (Tooltip or HoverCard) — it should be a Popover, the accessible non-modal dialog. - tooltip.mdx: rewrite the "Interactive tooltip" guidance and direct interactive content to Popover. - Tooltip.demo.interactive: replace the link with non-interactive hoverable text. - Tooltip.tsx: correct the `interactive` prop JSDoc. Guidance references: - WCAG 2.1 SC 1.4.13 Content on Hover or Focus: https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html - WAI-ARIA APG Tooltip pattern ("A hover that contains focusable elements can be made using a non-modal dialog"): https://www.w3.org/WAI/ARIA/apg/patterns/tooltip - Inclusive Components, Tooltips & Toggletips ("Don't put interactive content ... in tooltips or toggletips"): https://inclusive-components.design/tooltips-toggletips/ - Sarah Higley, "Tooltips in the time of WCAG 2.1" ("No interactive content"): https://sarahmhigley.com/writing/tooltips-in-wcag-21/ - CSS-Tricks, Tooltip best practices ("Tooltips must not contain interactive content"): https://css-tricks.com/tooltip-best-practices
BREAKING CHANGE: the `interactive` prop introduced in 9.5.1 is renamed to `hoverable` (default still `false`). The prop keeps the tooltip open while the pointer moves onto it — it satisfies the *hoverable* condition of WCAG 1.4.13. It has nothing to do with the tooltip containing interactive content; in fact interactive content must not go in a tooltip (see the preceding guidance commit). The name `interactive` promised the opposite of what the accessibility guidance recommends, so the docs for it had to warn against interactive content — a permanent contradiction. Renaming to `hoverable` names the actual behavior and removes that contradiction. Renaming now, while adoption is minimal (shipped 8 days ago), keeps the breaking change as cheap as it will ever be. - Rename the prop, the `data-interactive` mod to `data-hoverable`, and the internal `interactiveMod` variable across Tooltip.tsx and use-tooltip.ts. - Update tests, story, the demo (file/export renamed to `hoverable`), and the Tooltip docs page (section, prose, anchor, examples). - Update the 9.5.0 changelog demo reference to the renamed export; its prose is left as the historical record of the 9.5.0 release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #9072 / the
interactiveprop shipped in 9.5.1.@rtivital I'm sorry if there was confusion or I could have been more clear in my original issue description, but the goal of #9072 was only to make the tooltip hoverable — so the pointer can travel from the target onto the tooltip without it closing (WCAG 2.1 SC 1.4.13, Hoverable). And at the very most, allow users to select/copy the contents of the tooltip, not to enable users to put interactive content in there. We obviously can't stop them but we shouldn't encourage them either.
1. The docs encourage putting interactive content in a tooltip
The updated docs say
and the demo renders an
<Anchor href>inside the tooltip.However that wasn't the intent of the original fix because interactive/focusable content in a tooltip isn't accessible: a tooltip is exposed to assistive technology only as an
aria-describedbydescription, isn't in the focus order, and is dismissed onEscape, so keyboard and screen-reader users can't reliably reach it.Example guidance against interactive tooltip content:
This PR updates the docs to make that more clear, suggesting that interactive content be put in a
Popoverinstead (an accessible non-modal dialog reachable by mouse, keyboard, and touch — which is what the WAI-ARIA APG recommends). It also updates the demo and also corrects a wording bug: 1.4.13 was described as applying only when the tooltip contains interactive content, but it applies to any content shown on hover (and a tooltip should never contain interactive content).2. The prop name
interactivecontradicts that guidanceNaming the prop
interactiveis slightly misleading because it sounds like it's recommending the thing the accessibility guidance says not to do — the docs forinteractivehave to warn against interactive content, which feels odd. This PR renames the prop tohoverable, which names the actual behavior (and matches the WCAG 1.4.13 hoverable condition it satisfies). Default staysfalsefor smallest impact on users, even though I think you could make a case it should default totrue. Renaming the prop now, about a week after it shipped, keeps the breaking change as small as possible.Commits (intentionally separable)
interactiveprop tohoverable— breaking rename on top, so it can begit reverted independently if you'd prefer to keep only the guidance fix, or take the guidance now and rename later.The 9.5.0 changelog prose is left as the historical record of that release; only its live
<Demo>reference was updated to the renamed export.Happy to adjust the name, split differently, or drop the rename commit — whatever you prefer.