aria-tooltip-name documentation may need rethinking #4916
Description
Product
axe-core
Description
the aria-tooltip-name is providing technically accurate ways to define a name for a tooltip - but it completely leaves out the best way to name a tooltip, and that is from their name from content.
the current doc only notes that providing an element with role=tooltip a name from aria-label, aria-labelelledby, using aria-label to provide unique content and append the visible text, or using the title attribute - which ... is obviously valid but a title attribute tooltip for your empty tooltip?
in reality (verified testing today), if a tooltip contains text and is given an accessible name, JAWS and NVDA paired with chromium and firefox, and VO on iOS ignore the author provided name, and just announce the contents of the tooltip, when interacting directly with it.
Narrator is the opposite, where it will only expose the author provided name and make it difficult to get to the content of the tooltip.
macOS VO + Safari do a pretty good job with exposing the author provided name and then making it clear when someone enters/exits the tooltip, if it has any content within to read (as they typically do).
If the tooltip is associated with another element with aria-describedby, then the author naming of the tooltip is generally respected - and there are different pros/cons to that since any content within the tooltip won't be part of the description calculation.
Fortunately scanning a page with a tooltip with axe-core doesn't flag a tooltip if it isn't given an explicit name from author. So, imo the scanning is working great, but the documentation is promoting the least robust ways to rectify a tooltip without a name (which, i guess would most likely come up if the tooltip contained an image with no alt text, and then there'd probably be a flag for that s well)