Template talk:Tooltip

Test

This is a tooltip which does not wrap correctly?

In FireFox 1,5 the tooltip is just short. In IE6 the tooltip is long.

Well in Safari it wraps beautifully: only to go away before you have time to finish reading it! —Ian Spackman 19:58, 21 May 2007 (UTC)

Seems to work in ie6 for me just fine. My buddy is a mediawiki admin and he would love this thing. Is this supported in all versions? ClintonKu (talk) 21:15, 24 May 2009 (UTC)

Category link

{{editprotected}}

• This protected page has been detected in [[Category:Wikipedia formatting templates]], but that category has been redirected to [[Category:Wikipedia formatting and function templates]]. Please update the category link. --RussBot (talk) 13:19, 27 August 2008 (UTC)

Y Done Harryboyles 17:15, 27 August 2008 (UTC)

Merge with {{abbr}}

This template does the same as {{abbr}}, but without using the HTML tag <abbr> or the class abbr. — Dispenser 14:35, 10 October 2009 (UTC)

Why not make this more like a navigation popup?

Why not make this more like a navigation popup? Then we could put links in it too. Lemmiwinks2 (talk) 03:41, 14 October 2009 (UTC)

See Wikipedia:Tools/Navigation popups. This feature must be installed by the user, and requires that their browser has JavaScript support enabled. – Wbm1058 (talk) 13:36, 12 June 2015 (UTC)

Redirects for deletion.

I have started a redirects for deletion discussion. If someone could replace the page with {{subst:rfd|content=#REDIRECT [[Template:Abbr]] {{R from merge}}}}, that would be appreciated. E to the Pi times i (talk | contribs) 04:08, 31 March 2018 (UTC)

 Done Galobtter (pingó mió) 12:24, 31 March 2018 (UTC)

Template-protected edit request on 1 January 2021

Update TfD template, as I re-listed the discussion to 1 January. –Piranha249 21:40, 1 January 2021 (UTC)

 Not done: I've undone the relist; it's already been relisted twice. Primefac (talk) 21:44, 1 January 2021 (UTC)

Template-protected edit request on 27 January 2021

This template was approved for a merger with Template:Hover title earlier this month, but nothing has come of the effort since then. –Piranha249 (Discuss with me) 18:17, 27 January 2021 (UTC)

This isn't an edit request. Template mergers sometimes take time. Please be patient. Primefac (talk) 18:27, 27 January 2021 (UTC)

Why does our documentation flout the rules?

I'm puzzled that the documentation contains a warning which is viewed as serious enough that it deserves all bold:

Please note: Do not use {{abbr}} or <abbr> to mark up material other than abbreviations (including acronyms). Using it to generate tooltips elsewhere is a misuse of the underlying HTML and causes accessibility problems. For general-purpose tooltips, use {{tooltip}} instead.

Then goes on to give a usage example which is a formula not an abbreviation, and that example uses {{abbr}} rather than {{tooltip}}.

I recognize that this classic formula includes some abbreviations, but I don't think combining abbreviations into a formula makes it an abbreviation. I'm not fully grasping why {{abbr}} creates an accessibility problem while {{tooltip}} does not, but unless I'm missing something, if we strongly urge editors to use tooltips for things other than abbreviations shouldn't we use tooltip in the documentation? Am I missing something?--S Philbrick(Talk) 21:45, 12 May 2021 (UTC)

@Sphilbrick: ... I'm missing something ... I'm not sure what's going on here, but I've highlighted quoted text to make it clear what you are talking about. Feel free to wrap the said warning into a {{notice}} template to make it more readable. On the other side, I think it's legit to avoid using tooltips. It certainly would cause readability issues on different devices. AXONOV (talk) ⚑ 18:55, 13 May 2021 (UTC)

Alexander Davronov, I get that pop-ups might create problems related to accessibility (and I don't know this for certain, it just sounds plausible), but I'm struggling to understand why a popup created by tooltips is problematic but a pop up created by abbr is not a problem. (thanks for the highlighting to clarify what I am talking about.) S Philbrick(Talk) 20:05, 13 May 2021 (UTC)

@Sphilbrick: I agree that it sounds plausable. Probably underlaying html tags and scripts cause issues with accessibility on devices not fully supporting html/js/css but I'm confused too here tbh. Cheers. AXONOV (talk) ⚑ 20:11, 13 May 2021 (UTC)

Dotted not working in new vector

The css class explain used by this template is not supported in new vector and hence tooltips are never dotted in that skin. This can be solved by moving the doting to template styles as I've done at Template:Tooltip/sandbox. I would like to have someone more experienced have a look at it before implementing though. Thanks to Izno for helping out at discord full credits for anything clever I say to them. --Trialpears (talk) 16:47, 7 August 2021 (UTC)

Looks fine. Izno (talk) 17:34, 8 August 2021 (UTC)

Now implemented. --Trialpears (talk) 12:41, 9 August 2021 (UTC)

Discussion at Wikipedia:Village pump (technical) § Italics in a tooltip

 You are invited to join the discussion at Wikipedia:Village pump (technical) § Italics in a tooltip. {{u|Sdkb}} ^talk 22:02, 17 October 2021 (UTC)

Template-protected edit request on 9 July 2023

Update this template to the current sandbox version. The added line {{sronly|Tooltip {{#if:{{{3|}}}|{{{3|}}}|{{{2}}}}}}} will cause the tooltip text to be read aloud as "Tooltip {parameter as written}". A version of this was tried before, but it caused an unspecified error when used outside of the testcases page [1]. This version is slightly less complex and a minor error has been since corrected in the live template. When testing this template on Firefox, Chrome, Edge, IE, NVDA, and Windows 10, I don't notice any issues in or out of the sandbox. An example of the sandbox version: conflict of interest (in the specific sense employed in Wikipedia policy) Feel free to ask any questions or for any specific testing Rjjiii (talk) 21:37, 9 July 2023 (UTC)

 Completed. P.I. Ellsworth , ed. ^{put'er there} 17:09, 11 July 2023 (UTC)

 Reverted. P.I. Ellsworth , ed. ^{put'er there} 17:59, 11 July 2023 (UTC)

Template-protected edit request on 11 July 2023

Revert previous update. In most situations this works fine, but sometimes when used within a link it will either display the Template:sronly text inline, suppress the link, or suppress the tooltip. This may the same issues that SMcCandlish noted as it works fine in the sandbox and in many mainspace contexts. Rjjiii (talk) 17:46, 11 July 2023 (UTC)

More context for future editors. This is a bug in {{sronly}} unrelated to tooltips. When placed within a link, it can cause issues. The most common is that the intended hidden text is printed inline. I'm not sure what causes the stylesheet conflict, but it shouldn't be used in links or templates that are linked until fixed. Rjjiii (talk) 17:56, 11 July 2023 (UTC)

 Reverted. P.I. Ellsworth , ed. ^{put'er there} 18:00, 11 July 2023 (UTC)

Dotted line working in preview mode, but not in saved article mode

It's really weird: [2]. I have tried purging the page and using a different browser but the problem remains. Any ideas? Betty Logan (talk) 11:45, 14 August 2023 (UTC)

Template:efn will work better in that situation. Using a tooltip will make the content unavailable to most readers including everyone on mobile, and not accessible for users using a screen reader or keyboard navigation. Regards, Rjjiii (talk) 16:14, 14 August 2023 (UTC)

Better yet, rewrite the sentence to avoid using film jargon. Something like: "Since Fox, to save costs, had long ago destroyed the negatives of the outtakes and portions of scenes that were cut during editing of the film, traditional outtakes could not be included." – Jonesey95 (talk) 01:59, 15 August 2023 (UTC)

How dare you say something commonsensical!  — SMcCandlish ☏ ¢ 😼  04:54, 15 August 2023 (UTC)

Surely there's a notice board for such things? Rjjiii (talk) 05:49, 15 August 2023 (UTC)

I appreciate the suggestions, but a problem bypassed is not a problem solved. There would still appear to be a glitch in the template. Betty Logan (talk) 08:20, 15 August 2023 (UTC)

It appears to be because the first use of the template in the article (in the infobox) is inside a link, where TemplateStyles doesn't work. In any case this template should never be used in the main namespace (MOS:NOTOOLTIPS). (The infobox use is a double whammy as it also violates MOS:SMALLTEXT.) Nardog (talk) 08:53, 15 August 2023 (UTC)

Thanks! I've removed the first hover box and now we've now got a dotted line. I will sort out the second one with a footnote when I get a chance. Very strange that the first instance was disrupting the second instance, but at least you have satisfied my curiosity. Betty Logan (talk) 09:24, 15 August 2023 (UTC)

TemplateData

This template shares TemplateData with {{abbr}} via the documentation. I think only the first bit (This template defines an abbreviation or acronym, by creating a tooltip that is displayed on mouse-over.) needs to be changed. Should this be made more general so that the TemplateData applies to both {{abbr}} and {{tooltip}}, or should {{tooltip}} use its own TemplateData with a separate explanation? Rjjⁱⁱⁱ (talk) 06:39, 14 January 2024 (UTC)

The description "Meaning" for |2= also does not seem valid for {{Tooltip}}. I think this template should have its own TemplateData, which can probably be transcluded using an #if statement that checks the page name. – Jonesey95 (talk) 07:18, 14 January 2024 (UTC)

Oh, good catch. I've added separate descriptions for {{tooltip}}'s TemplateData. I also made the descriptions shorter, so they would not be cut off in the VisualEditor's template search box, Rjjⁱⁱⁱ (talk) 16:47, 15 January 2024 (UTC)

Prefer the larger dots used for Template:Abbr

The {{tooltip}} dots are so small they are hard to see for the less eagle-eyed among us.

I prefer the dot size in {{abbr}}.

big dots {{abbr|big dots}}

little dots {{tooltip|little dots}}

It is more obvious with big dots that one is not looking at a typical underlined link found elsewhere on the web.

The little dots could be mistaken for a link line since they are so small. In dark mode the dots seem to be gray on black which makes them even harder to distinguish. The big white dots are so much better.

Also, in dark mode in article namespace table cells with background colors have black underlined links. For example, this table (scroll down):

• List of top-division football clubs in UEFA countries#Spain - look at it in dark mode.

{{tooltip}} dots could be mistaken for more links in that table.

That table uses {{abbr}} in the headers. Big dots. No mistaking them for typical underlined links.

For more info see:

• Help:Table#Color contrast of links in dark mode

--Timeshifter (talk) 16:40, 27 July 2025 (UTC)

I see a thin underline just below the letters in the first example (abbr), and a more substantial, dotted underline with some vertical spacing below the letters in the second example (tooltip). The tooltip example is the one that looks better to me. In dark mode, all of the dots are the same color as the text (nearly white). Note: the above is in Firefox, logged in. In Chrome, I see fatter dots under abbr; everything else is the same. – Jonesey95 (talk) 19:16, 27 July 2025 (UTC)

I clarified which is which in my first post.

In Firefox in Windows 10 Pro on a big screen I am seeing the opposite of you. What OS, device, and screen are you using?

I looked in Firefox in an iPad 2020 and things are weirder still. The dot size and spacing is the same for both tooltip and abbr. But there are 2 lines of dots for abbr.

In Chrome on Win 10 Pro the dots are the same as what I see on Firefox on Win 10 Pro: Big more widely spaced dots for abbr, and small tightly spaced dots for tooltip. --Timeshifter (talk) 19:37, 27 July 2025 (UTC)

Would changing the CSS for this template from a dotted bottom border to text-decoration: underline dotted; make them look the same regardless of browser? I think it would but maybe there is some issue that I have overlooked. Either way, I don't have any strong opinions on the appearance. They both look fairly similar on Firefox, Chrome, Gnome Web (Webkit), and Pale Moon running on Linux Mint. On Chrome, I agree with Jonesy above. Maybe a font issue, but the fat dots on Chrome are less distinct from the text (maybe this is why a bottom border was used to begin with?). Rjjⁱⁱⁱ (talk) 00:20, 28 July 2025 (UTC)

An example as people are comparing:

• big dots? {{tooltip|big dots?}}
• big dots {{abbr|big dots}}
• little dots {{tooltip|little dots}}

That uses inline CSS mentioned in my first post. I think it should render the same. No strong opinions on the original concern, Rjjⁱⁱⁱ (talk) 00:25, 28 July 2025 (UTC)

Just tested on other devices. Older version of Safari still in use and Internet Explorer don't support this. That is most likely why it's done as a border. Rjjⁱⁱⁱ (talk) 00:35, 28 July 2025 (UTC)

Template:Tooltip/styles.css uses border-bottom: 1px dotted;

You tried text-decoration: underline dotted; for it:

{{tooltip|big dots?|style=text-decoration: underline dotted; border-bottom: none;}}

big dots?

It makes for bigger dots. I like it. Is that what {{abbr}} uses? I can't tell by looking at its source. And I don't see a CSS file for {{abbr}}. --Timeshifter (talk) 19:58, 28 July 2025 (UTC)

Again, those dots are tiny for me (Firefox for Mac OS, latest build), so tiny that they look like a very thin gray underline. The ones that use border-bottom: 1px dotted; are much better. As for a CSS file for Template:abbr, it looks like it doesn't use one; instead, I suspect, each browser has its own method of marking <abbr>...</abbr> tags, which is why Chrome and Firefox look different from each other while Template:tooltip looks the same on both browsers. I recognize that Firefox is a minority browser at this point, and that Chrome rules the roost, so if you want to make tooltip and abbr match each other, it's OK by me. You might get some pushback from users of non-Chrome browsers, though. – Jonesey95 (talk) 20:17, 28 July 2025 (UTC)

I agree about tooltip and abbr matching each other. Overall, the bigger dots show up for more people when tooltip and abbr match each other by using whatever abbr is using. There are a lot more Firefox users on PCs than Macs. And abbr uses big dots on Firefox and Chrome on PCs. --Timeshifter (talk) 20:58, 28 July 2025 (UTC)

On Firefox and Chrome, <abbr> defaults to "text-decoration-line: underline; text-decoration-style: dotted;" Not on Safari though. I tried breaking it out like that rather than shorthand. An iPhone (new ones even) render {{tooltip}} and {{abbr}} exactly the same currently. Changing tooltip to look more like Chrome's rendering, would make them different. I don't see much benefit since it still doesn't offer consistency. Sorry if I got any hopes up, there, Rjjⁱⁱⁱ (talk) 02:33, 29 July 2025 (UTC)

{{abbr}} looks better on Chrome and Firefox on PCs. So changing {{tooltip}} to whatever abbr is using would mean more people overall would benefit from the big dots. Since most people use Chrome and Firefox on PCs.

How does abbr look on Android phones?

Worldwide: "Android market share (as of the end of 2024) stands at 70.93%, while iPhone market share for the same period is 29.07%."

https://wezom.com/blog/iphone-vs-android-users-key-differences-in-2025

abbr dots {{abbr|abbr dots}}

tooltip dots {{tooltip|tooltip dots}}

--Timeshifter (talk) 15:09, 29 July 2025 (UTC)

@Jroberson108: I think you have an Android phone. What do you see? Especially in dark mode. --Timeshifter (talk) 15:15, 1 August 2025 (UTC)

Better stat's would be Wikipedia's usage of all sites (most used operating systems):[3]

• 31% Android
• 28% iOS (iPhone)
• 27% Windows
• 9.8% macOS

Most used browsers on highest percentile OS:[4]

• 26% Chrome mostly on Windows
• 26% Chrome Mobile mostly on Android
• 19% Mobile Safari mostly on iOS (iPhone)
• 4.1% Firefox mostly on Windows
• 4.0% Edge mostly on Windows

Android using Minerva skin (default) - dark mode inverts the colors (as it should), and {{tooltip}} has consistent styling on both browsers (border-bottom):

• Chrome: {{abbr}} looks bigger and more spaced.
• Firefox: {{tooltip}} more prominent.

You also need to consider when they are linked, which the doc has examples for those. When linked and you hover, a solid line appears as text-decoration. Testing Windows Chrome/Firefox on Vector (2022) skin (default):

• {{abbr}} (text-decoration): link line covers abbr text-decoration, with the larger Chrome dots still visible around the link line.
• {{tooltip}} (border-bottom): link line above border with some spacing (double line).

You could add a style to hide the text-decoration/border-bottom when hovering, which I added to the below CSS for border (this template).

I cannot hover on my Android, which most phones don't have true hover capabilities, so how it looks on those devices is sort of a moot point. Better might be to hide the pre-hover styling when you have no way to hover.

/* Mouse, trackpads, active stylus, touchscreens w/ hover tech. */
@media (any-hover: hover) {
  .tooltip-dotted {
    border-bottom: 1px dotted;
    cursor: help;
  }
  /* Hide when linked and hovered. */
  a:hover .tooltip-dotted {
    border-bottom: none;
  }
}

If there are hover issues because the pointer is coarse, then you can exclude those. Example, touchscreen w/ hover tech: detects finger hover up to ~10mm (typical) from screen, which can obstruct the visibility of hovered text beneath it. Also, difficult and imprecise hover activation on small text (~14px font-size) with a big finger tip.

/* Mouse, trackpads, active stylus. */
@media (any-hover: hover) and (any-pointer: fine) {...}

For {{abbr}} and {{abbrlink}}, they don't have their own styles and use the skin's styling. Jroberson108 (talk) 22:55, 1 August 2025 (UTC)

Scratch the above media queries. Some devices have quirks like my Android where they return true even though I cannot hover and I don't have a fine pointer.

.tooltip-dotted {
  border-bottom: 1px dotted;
  cursor: help;
}
/* Hide when linked and hovered. */
a:hover .tooltip-dotted {
  border-bottom: none;
}

Jroberson108 (talk) 02:26, 2 August 2025 (UTC)

On my iPhone SE 2020 the abbr dots are bigger than the tooltip dots in Chrome. And there are 2 lines of dots with abbr. A line of larger dots and a line of smaller dots. Exactly the same in Firefox, Safari, and Edge. In both light and dark modes.

The 2 dotted lines make it clearer that this is different from an underlined link. Which the tooltip line resembles due to its smaller dots.

So the main browser on both Android and iPhone (Chrome) has bigger dots.

And {{abbr}} looks better on Chrome and Firefox on PCs.

So let's use whatever abbr is using. In both {{abbr}} and {{tooltip}}. --Timeshifter (talk) 21:12, 2 August 2025 (UTC)

@Timeshifter and Rjjiii: Your description of iPhone SE 2020 seems to differ from Rjj's earlier statement: "An iPhone (new ones even) render {{tooltip}} and {{abbr}} exactly the same currently." Timeshifter, are you at normal zoom and font-size? Also, can you activate the tip pop-up on iPhone? Jroberson108 (talk) 21:31, 2 August 2025 (UTC)

1. big dots?
   {{tooltip|style=border:none; text-decoration-line: underline; text-decoration-style: dotted;|big dots?}}
2. big dots
   {{abbr|big dots}}
3. little dots
   {{tooltip|little dots}}

• iPhone 6s, iOS 15.8, Safari 15: 2 & 3 look the same; 1 has the dots high enough that a space is made for the "g"
• Thinkpad t460s, Linux Mint 22.1, Firefox 141: 1 & 2 look the same with a space for the "g"; 3 has the dots smaller and lower
• Thinkpad t460s, Linux Mint 22.1, Chrome 138: 1 & 2 look the same with a space for the "g"; 3 has the dots smaller and lower
• Thinkpad t460s, Linux Mint 22.1, Gnome Web (Safari 60's webkit): 1 has the higher line with a space for the "g"; 2 has both a dotted and a solid line; 3 has the dotted line lower down
• Thinkpad t460s, Linux Mint 22.1, Pale Moon (old Firefox's Gecko): 1 & 2 look the same with the line crossing the "g"; 3 is lower

Rjjⁱⁱⁱ (talk) 22:11, 2 August 2025 (UTC)

For testing in various devices and browsers:

abbr dots {{abbr|abbr dots|pop-up info}}

tooltip dots {{tooltip|tooltip dots|pop-up info}}

My iPhone SE 2020 is using the latest iOS: 18.6.

Rjjiii mentioned an iPhone 6s using iOS 15.8.

Safari version on either iphone is the same as the iOS version.

I do not see the popup info on Safari or Firefox. Not from touching, or long-pressing. --Timeshifter (talk) 15:47, 5 August 2025 (UTC)

Render this as parenthesized text when used in the mainspace

Like this (result if in mainspace).

Benefits seem obvious: screen-reader accessibility, mobile friendliness, ... Sapphaline (talk) 21:20, 29 August 2025 (UTC)

Please put test cases on the Template:Tooltip/testcases subpage, not within the sandbox page. This also facilitates comparing the current result with the result using the sandbox template.

I don't understand the motivation: it's redundnant to display "Refs. (References)". The heading could just be "References"; no template or repetition is necessary. isaacl (talk) 23:05, 29 August 2025 (UTC)

Please put test cases on the Template:Tooltip/testcases subpage - sure.

I don't understand the motivation - well, these are real examples from real articles. Though I understand they're not the "best" ones. Sapphaline (talk) 07:55, 30 August 2025 (UTC)

There are new testcases on the page, please check them out. Sapphaline (talk) 08:11, 30 August 2025 (UTC)

Your proposal seems to be altering this template to no longer do what it was intended to do. If that is the case, then the appropriate approach is to replace its usage, not to display redundant information. It's confusing to have a template called "tooltip" that just adds the text in parentheses. I appreciate the logistical difficulty in replacing the uses, but I don't see a way around it. isaacl (talk) 16:18, 30 August 2025 (UTC)

And what do you think about template:tooltip/testcases#Sandbox3 and template:tooltip/testcases#Sandbox4? Sapphaline (talk) 16:19, 30 August 2025 (UTC)

I'm not uo-to-date on latest accessibility practices regarding tooltips. (The tooltip pattern page in the ARIA Authoring Practices Guide doesn't seem to be progressing very quickly. I don't know if there are any accessibility reasons to prefer separate elements marked up with corresponding WAI-ARIA roles versus using the title attribute.) Nonetheless, my personal recommendation is to follow the principle of using them to provide optional enhancement to the user experience for those able to hover, while still presenting all essential information to everyone. Sometimes that means users have to click through a link to learn more. For tables, legends should be used to provide detailed explanations of headings. For some topics, there are writing conventions that are better explained in other ways than linking every use. isaacl (talk) 16:57, 30 August 2025 (UTC)

This does not seem like a good idea to me. Rather than having the template do something contrary to its name, if it shouldn't be used somewhere then just don't use it, and clean it up if you find it. Anomie⚔ 23:43, 29 August 2025 (UTC)

A little bit disgruntled, that after having seen no edits at all to the sandbox since Feb. 2023, my 37-byte edit of August 27, 2025 (two days ago) created to test a proposed solution to the screen reader accessibility issue, was so quickly wiped out by 16 edits and 10,000 bytes two days later, with no heads-up and no edit summaries. Never mind; I will recover the version from two days ago and carry on testing from another location. In any case, the two versions come at the problem from different directions, and are not mutually exclusive, so there's that. Mathglot (talk) 01:25, 30 August 2025 (UTC)

clean it up if you find it - I can't just clean this up from the mainspace; there are approximately 57 thousand articles using manual tooltips, according to this search query. Sapphaline (talk) 07:55, 30 August 2025 (UTC)

This also means that your proposal would change 57 thousand articles overnight. FaviFake (talk) 08:24, 30 August 2025 (UTC)

Yes, which is why we're having this discussion right now. Sapphaline (talk) 08:43, 30 August 2025 (UTC)

I agree with Anomie.. Also applying a bit of perspective here. 57000 articles with accessibility problems sounds like a big thing, but it’s for very small pieces of mostly very unimportant information. It sounds bad because it was a big number that could be found. But there are likely 100000s of pages that use inline style textcolor to communicate information to users (especially outside of mainspace) that are way harder to find and give a definitive count for. There are millions of pages that cannot be consumed by people with reading disabilities and/or cognitive problems. I always caution people to turn accessibility problems into some sort of binary and absolute problem. It quickly becomes disruptive and has the risk of turning somewhat performative unfortunately. Lets just focus on finding good solutions for everyone (including people who do not want this text in the main text and have THUS moved it i to a tooltip). There is no rush. Wikipedia has had accessibility problems for 25 years and will have them for the next 25 years as well. —TheDJ (talk • contribs) 09:07, 30 August 2025 (UTC)

Lets just focus on finding good solutions for everyone (including people who do not want this text in the main text and have THUS moved it i to a tooltip) - well, it can also accessibly be done like this. Not really a tooltip, however. Sapphaline (talk) 09:49, 30 August 2025 (UTC)

Or like this, so that:

1. There are zero changes for desktop users
2. Mobile users have the tooltip's content parenthesized
3. Screen readers read it out using aria-describedby.

Sapphaline (talk) 10:32, 30 August 2025 (UTC)

Or this can be simplified and just use template:screen reader-only for parenthesized text so that aria-describedby can be deleted, while making it visible for mobile users through templatestyles. Idk, there are so many options to make this more accessible. Sapphaline (talk) 10:39, 30 August 2025 (UTC)

Yes, many of these articles might only have issues for small pieces of information, but the very nature of these tooltips means that screenreader users won't know that in advance. Accessibility is not a binary, and compromises sometimes have to be made for different notions of accessibility, but labeling it as disruptive and performative can easily sound dismissive to people affected by these issues.

Looking at the first search results, it looks like, while the count of 57000 articles doesn't distinguish between uses for the tooltip, these are quite varied and not always ideal:

• Thailand uses it to abbreviate "reign" to r., which is fine.
• Dwayne Johnson shortens "References" to Refs., also fine.
• Ultimate Fighting Championship#Men's pound-for-pound shortens "Previous rank" into M, which is inscrutable for anyone not having access to the full tooltip.
• Shaquille O'Neal also shortens "References".
• The Lord of the Rings (film series) turns "Highest position attained in the chart" to Peak, which is not completely inscrutable but does result in some loss of context.
• Bill Gates shortens "Partial list of founded and chaired companies" into list in the infobox's See list entry. Without the tooltip (the infobox row is simply "Title"), there is a major loss of context.

Chaotic Enby (talk · contribs) 10:34, 30 August 2025 (UTC)

"Partial list of founded and chaired companies" I agree this usage is terrible and should not be applied. Even as a desktop user without a screenreader it is a pretty much useless addition to the infobox. This is common with infoboxes, where people try to jam all kinds of info into it, even though Wikipedia:Manual of Style/Infoboxes says "The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article" Either link to a list somewhere in the article, or just don't have the entry in the infobox. This is a clear example of a bad usage that goes against all the warning labels on the template's documentation page. —TheDJ (talk • contribs) 11:12, 30 August 2025 (UTC)

I've replaced it with an anchor link to the subsection it was presumably referring to. I wouldn't be surprised if a large proportion of the problematic tooltips could have the same treatment. We can't make Wikipedia perfectly accessible suddenly, but small incremental changes like this definitely help. Chaotic Enby (talk · contribs) 11:18, 30 August 2025 (UTC)

Reframing this.. If it is acceptable NOT to show this information to mobile users... then why is it not acceptable to not show this information to users making use of a screenreader ? Are we saying that all information should always be available to all users, regardless of wether or not that information matters at that point?

For instance, a common case is to show a marriage date next to a spouse in the infobox as only a year, but have hover show the full date... Or course the date of marriage is in the full body of the text.. So.... we can either, write the full date in the infobox, have only the year (as you don't really need more), or have the year with the full date as a hover context. Currently we present just the year to most of the audience, and have the fulldate as a hover for desktop users, where we have this additional feature.

For abbreviations, it is often only a longer version of the same word. It CAN be argued that some people might not know the abbreviated version of the word, but I think this is pretty unlikely in practice, and you can probably quickly find the meaning somewhere else in the text.

The biggest problem with a tooltip, is to share information in a tooltip that is not in any other way communicated in text to or derivable by the user (new information). This is also why there are dozens of banners on the template's page, but as we all know no one ever reads the warning labels. These cases should NOT use tooltips.

Now lets look at the case that sparked all this. The Talk header.. It already uses tooltips in the source locations bar: That bar has; Google, this is a name that people mostly know. Then there is JSTOR, this too is a name and the way this system is commonly referrered to. It is most likely derived from "Journal storage".. but no one knows this, and if you read JSTOR, unless you already know the term, you would have no clue what it is. You have to follow the link to figure that out. Worse for TWL and FENS, even if you write those out, people likely still have no idea what that means without reading more about it. So a common way to make the information accessible in a case like this, is simply explain it at the link destination. A similar logic can be applied to explaining how the archiving process works for the Talk header.

And for the rest, it probably means don't use a tooltip, and remove them when they are used because people do not read the warning labels. —TheDJ (talk • contribs) 10:39, 30 August 2025 (UTC)

it is acceptable NOT to show this information to mobile users - no, it's not. It's an issue with this template that needs to be fixed. Sapphaline (talk) 10:41, 30 August 2025 (UTC)

If it is not acceptable, then the template should not be used. But that is not the same as: every information should be presented exactly the same to everyone in all situations. Which is the distinction i'm making. —TheDJ (talk • contribs) 10:48, 30 August 2025 (UTC)

This template is often used within links, and those uses can never be made to work on mobile. Take for example, the curling articles or {{plant classification}}. That may have been a bad idea, but it also means that those pages cannot be fixed by fixing something in this template. And so, yes, we could make a template that does CSS tooltips, and we could make it read aloud, and we could make it popup horizontally-centered with a tap on mobile, and maybe we could figure out a way to handle printing. However, that would be a completely different template than this one. If there is a way to fix just the screen reader aspect using "role" as mentioned below, that sounds fantastic. Rjjⁱⁱⁱ (talk) 17:08, 30 August 2025 (UTC)

those pages cannot be fixed by fixing something in this template - are you sure the sandbox4 version won't fix it for mobile users? Sapphaline (talk) 17:15, 30 August 2025 (UTC)

@Sapphaline, how would it? A tooltip requires a pointing device that can either [a] hover or [b] select. So a mouse, trackball, trackpoint, graphic tablet, and so on can access both. They can move the cursor over the text and select with a separate button. How does a touchscreen allow a reader to hover, though? Rjjⁱⁱⁱ (talk) 17:26, 30 August 2025 (UTC)

Because in sandbox4 version, the tooltip's content is rendered in parentheses for Minerva users. You can check this with en.m.wikipedia.org. Sapphaline (talk) 20:06, 30 August 2025 (UTC)

Accessibility enhancement investigation

The issue of inaccessibility of tooltips to screen readers came up in as a tangential issue in an Rfc about tooltip content at an Rfc now active at Template talk:Talk header, in discussion subsection § Tooltips and accessibility. That subsection was started by Graham87, who wrote:

Extra information shouldn't be in a tooltip, per this part of the accessibility guideline. I don't know that it's there with my screen reader...

This made me think about how we might make tooltip pop-ups accessible to screen readers, and I made a quick change to Template:Tooltip/sandbox (diff) to give it a try.

Approach and preliminary result: one apparently successful test (but is it usable?)

I am encouraged by one preliminary test result from my first attempt at attacking this issue, but I need assistance from two groups to help test and investigate this further, to see if this approach is viable, or might lead to some other solution. The proposed change involves the use of attributes role=comment and aria-label=<copy of tooltip pop-up> added to the <span> tag. My one test appeared to work, that is, unless I got confused in the hurry to complete the test, I heard the tooltip pop-up text read by a screen reader, out of the aria-label attribute, which apparently most screen readers are able to do.

Help needed

I will need support from two user groups to test this properly:

1. testers who are more used to screen readers than I am. (I used them for the first time today. My attempts to use NVDA did not go that well, so I gave up and tried JAWS. That worked, but I had only a 40-minute window with the free license and barely managed one test before it expired.)
2. users more familiar with roles and aria-label than I am. I would have pinged Izno for this, even before I landed at Module talk:Message box#Aria roles by a completely different route, and saw you there, at an unrelated discussion, except for the common feature of using aria-label. So, I am hoping to hear from those more expert in this domain whether there are some pitfalls or other difficulties involved in the approach I took, and if so, whether it might point the way to a more robust solution. One specific question in this domain, is: which role? I chose user input, which seemed the most neutral, and is also kind of what a tooltip is. However, I am unaware of any downstream ill effects that role might have.

Test version and test bed

Further information: Template:Tooltip/sandbox2 and Template:Tooltip/testcases § B. Screen reader test cases against sandbox2

My initial test was with the the 27 August regular sandbox version (permalink), and I got a good result with the screen reader. However, this sandbox version has since been overwritten by another user, apparently also looking for accessibility solutions via a completely different route than I took. I copied that revision into sandbox2, and added custom test cases in Template:Tooltip/testcases#B. Screen reader test cases against sandbox2.

I am unable to test using sandbox2 or the test cases, as I don't have a working screen reader anymore, and I probably wouldn't be a very good tester anyway even if I did, having zero experience with them. Could really use help with the testing, as well as any advice or caveats about the aria-label approach to providing screen reader accessibility to the pop-up part of this template, as implemented currently in sandbox2. Thanks! Mathglot (talk) 03:34, 30 August 2025 (UTC)

Listed: Wikipedia talk:WikiProject Accessibility. Mathglot (talk) 03:50, 30 August 2025 (UTC)

Neither of the tests work for me on either JAWS or NVDA when arrowing around (I hear tooltip popups when tabbing though). When I told my friend @Codeofdusk:, who also uses a screen reader, he pointed me to this page about tooltips on Mozilla's developer site, which says, among other things: "One cannot activate this feature through either keyboard focus or through touch interaction, making this feature inaccessible. If the information is important enough to include as a tooltip or title, consider including it in visible text". Graham87 (talk) 07:02, 30 August 2025 (UTC)

aria-label doesn't work with <span>, even with role="comment" specified. This should either use aria-describedby, with the tooltip's text in a separate element with its id= being hashed value of this text, or just render as parenthesized, like I suggested in the topic above. Sapphaline (talk) 07:43, 30 August 2025 (UTC)

Thanks, but that doesn't work for the goal I have in mind, which is to retain the existing functionality of the template for sighted readers using browsers, namely, display pop-up text upon hover, while also adding the capability for screen readers to be able to access the pop-up text as well, which isn't something they can do now. I have a different approach which may require some iteration to work properly, which does not involve placing the pop-up message into plain text. Mathglot (talk) 21:42, 30 August 2025 (UTC)

If I were to do something along the lines of what is being proposed here for non-abbreviations (abbreviations should use {{abbr}} anyway and which screen readers interact with differently), I would use {{screen reader-only}}.

Much recent discussion seems to regard misuses of this template (as it always has, sigh). Izno (talk) 22:14, 30 August 2025 (UTC)

That's funny, because I came around to the same idea by a different route, and literally just updated it (diff). I wasn't aware of the template; thanks for that; that should save a lot of my twiddling the css I ended up with, which is at Template:Tooltip/styles2.css. Note that that is different than what the s-r template uses at Template:Screen reader-only/styles.css, so maybe I should just switch to that one? Do you see any advantage to using {{screen reader-only}} as opposed to just using the styles.css directly (either copying it locally, or just pointing to it remotely, as apparently other templates already do)? Mathglot (talk) 22:37, 30 August 2025 (UTC)

Doesn't matter to me, but my personal opinion is that it's better to keep TemplateStyles as encapsulated to their primary template as our largest pages can handle. What wouldn't make sense would be to replicate the CSS directly in this template IMO. Izno (talk) 01:22, 31 August 2025 (UTC)

Redesign with new css

Hi, Graham87, and thanks for the help. I guess am going to have to bite the bullet and download NVDA again and and just learn it, but that will slow me way down for a while. Based on your feedback, I have abandoned the last approach, in favor of a completely new design. (If you are curious: this version emits two span tags with identical content for the tooltip, one of them is blocked from visible display only, the other is blocked only from screen readers, so everybody gets access to the content once, and only once. At least, that is the intent; whether it succeeds in this iteration remains to be seen.) The new version is not quite ready yet; I need to adjust the css further, and will let you know when it is testable. It is currently available in sandbox2, and test cases are active here. Thanks, Mathglot (talk) 01:14, 31 August 2025 (UTC)

OK. If it does work, I still don't know if it'll be equal access (or what would be wanted all the time) ... ideally screen reader and mobile users should be able to read tooltips on-demand, just like desktop users can, and shouldn't have the content of the tooltip thrown at them without prompting. I don't think there's really a way to do that. Graham87 (talk) 06:08, 31 August 2025 (UTC)

Hi, Graham87. I had not thought about the on-demand aspect; at the moment, I am trying to make previously inaccessible text accessible to SR's and am not there yet. That said, Saphhaline has various tests going on in sandbox, sandbox3, and sandbox4, and at least one of them is on-demand, I believe, in that you have to click something to view the tooltip part of it, so maybe that is more like the on-demand you are looking for? Check the section above where they discuss it. As for my approach, based on the CSS I have been trying to put together at {{Tooltip/styles2.css}}, I have just learned about template {{Screen reader-only}}, which apparently already implements a working version of that and if it works as advertised, it may well lead to a solution here. On the other track, Sapphaline's approach may work better for you. Maybe we'll get lucky and end up with multiple working versions with different approaches and features, and then we can put it to an Rfc and pick the best one; wouldn't that be nice! Mathglot (talk) 06:46, 31 August 2025 (UTC)

Meh ... I'd just prefer that people not use them to display extra information (that isn't an abbreviation expantion, etc.), per our already-existing guidelines. I've never had access to them (like most of Wikipedia's readers, frankly), so I don't know what I'm missing. Graham87 (talk) 07:27, 31 August 2025 (UTC)

Are my sandbox3 and sandbox4 versions accessible for you? Sapphaline (talk) 07:31, 31 August 2025 (UTC)

I think you're going to have to do what I have to do, which is download JAWS or NVDA or one of the other ones and check it for ourselves. NVDA seems like it has a longer learning curve, but JAWS gives you 40 minutes free and then you are done. Mathglot (talk) 08:08, 31 August 2025 (UTC)

They almost all aren't accessible, except the one with the link in sandbox3 when I tab past it with JAWS (but not NVDA). Graham87 (talk) 09:25, 31 August 2025 (UTC)

Could you test sandbox4 again? It now uses manual screen-reader only text instead of aria-describedby. Sapphaline (talk) 07:39, 1 September 2025 (UTC)

@Graham87:. Sapphaline (talk) 08:54, 3 September 2025 (UTC)

Have you tried downloading one of the screen readers yet? Ultimately, we are going to have to do that. Mathglot (talk) 09:01, 3 September 2025 (UTC)

we are going to have to do that - why? There's a person we can ask. Sapphaline (talk) 09:10, 3 September 2025 (UTC)

Sandbox4 works in both JAWS and NVDA. Graham87 (talk) 10:00, 3 September 2025 (UTC)

Should we sync the main page with it then? @Mathglot: @Izno: what do you think? Sapphaline (talk)

By the way, I think the same should be done to template:abbr. Sapphaline (talk) 10:14, 3 September 2025 (UTC)

The issue with attempting this solution is discussed in #Test case TemplateStyles issue. You will need/want to identify every use of this template inside a link. Izno (talk) 15:49, 3 September 2025 (UTC)

It works fine with links though? See the first testcase. Sapphaline (talk) 15:58, 3 September 2025 (UTC)

Go read the actual task, it will explain why what you're seeing is not sufficient. And "first testcase" is not useful either which way, please ensure you give full context with a half dozen sandboxes now floating around. Izno (talk) 16:01, 3 September 2025 (UTC)

What do you mean by not sufficient? Text after link is hidden from sighted users. What's not sufficient about this?

I can use inline styles if you want to be 100% sure. Sapphaline (talk) 16:48, 3 September 2025 (UTC)

Your "test case" is not a sufficient test case. Izno (talk) 16:50, 3 September 2025 (UTC)

And as for inline styles, I would really rather not. Izno (talk) 16:50, 3 September 2025 (UTC)

Oh, I understand what you mean now.

I would really rather not - well, it's not like we have a choice until this issue is fixed. Sapphaline (talk) 17:14, 3 September 2025 (UTC)

The relevant fix is maybe a year or two out (Parsoid being deployed on English Wikipedia). Consider just waiting. Izno (talk) 17:17, 3 September 2025 (UTC)

Test case TemplateStyles issue

Hi, Rjjiii. Thanks for this edit of yours at test cases, with summary: If the first usage doesn't allow TemplateStyles, I think the CSS is never used, but I didn't understand it. As you perhaps noticed, all of the B-series tests fail in reduplicating the plain text portion, and I haven't looked at them yet, but it is no doubt due to my recent change to Template:Tooltip/styles2.css. (An alternate css to achieve the same goal is at Template:Screen reader-only/styles.css, but I only discovered it thanks to Izno's subsequent comment; it may be that switching to that css will solve the reduplication.) In the meantime, it sounds like you found something with that comment, but I don't know what. Can you explain? Mathglot (talk) 06:20, 31 August 2025 (UTC)

Thanks for the ping; I had intended to post here but got distracted in real life. I don't think it is caused by any change you made. There is some limitation to TemplateStyles where they are ignored inside of piped links (and maybe some other situations?). If the first usage of a template doesn't use the TemplateStyles CSS, then I think that no other usage of that template will. I made a post on sronly's talk page with a couple of examples. In the past, I had tried to just add {{sronly}} to this template, but it didn't work out. TheDJ explained some of the limitations, and pointed to a discussion on Phabricator. Rjjⁱⁱⁱ (talk) 17:12, 31 August 2025 (UTC)