Last modified: 2011-04-27 22:29:28 UTC
Links should only have a title attribute when the link text is different from the link destination's page title. This affects usability and accessibility. Currently, users ignore the title tool-tips, because every single link has a title attribute, and most of them are duplicating the link text. This effect is probably exacerbated for assistive technologies, many of which read slower than the average. If this wasn't the case, authors could rely more on this feature to convey useful information. The check for differences should be case-insensitive, and consider plural or possessive links, e.g. [[Link]]s or [[link]]'s.
I don't understand why having more title attributes makes anything less useful. If I hover my mouse over a link and no text comes up, this may be because it has no title attribute, or it may be because my browser hasn't picked up that I'm "hovering" (perhaps I'm jittering my mouse about too much...). When every link has a title attribute, I know I can hover my mouse over a link and see where that link points, whether or not that is different from the text of the link.
(In reply to comment #1) > I don't understand why having more title attributes makes anything less useful. People ignore redundant information. If the majority of titles duplicate the link text, no one will read any of them. Then in the few cases where there is useful information in a title, it won't be used. Clarity is improved by *reducing information to the minimum that is necessary.* Redundant and superfluous information obscures. People using assistive technologies (e.g. audible page readers or screen magnifyers for the visually impaired), or even people on alternative platforms (like tiny cellphone screens), may experience web pages very slowly and with difficulty. Redundant information can exacerbate their difficulties. The HTML spec says that the title attribute "... offers advisory information about the element for which it is set." It's meant to be *additional* information. > If I hover my mouse over a link and no text comes up, this may be because it has > no title attribute, or it may be because my browser hasn't picked up that I'm > "hovering" (perhaps I'm jittering my mouse about too much...). Are you suggesting that all links on the Internet should have title attributes added, not to add advisory information to the link, but to provide visual feedback about your mouse movement? If in normal use the titles aren't displayed, I suggest you file a bug report with the people who produce your software, and adjust to the way it works or switch to a browser that works better for you. Incidentally, the browser I'm using right now displays title tool-tips even when I'm twitching my mouse pointer wildly, as long as it stays within the bounds of the linked text on the screen for about a second. > When every link > has a title attribute, I know I can hover my mouse over a link and see where > that link points, whether or not that is different from the text of the link. It's true that when WP authors use piped links poorly, it can obscure the destination of a link: this is an authoring issue. It's addressed by good recommendations in the style guides, and by improving confusing link text when you see it. Using technology to layer redundant information on most links doesn't clarify, it obscures. To cite an oversimplified example, the style guide advises not to link the words "click here". The solution isn't to add title text to "click here" (which the current technology would helpfully render as "click here"). The solution is to write better text.
(In reply to comment #2) > People using assistive technologies (e.g. audible page readers or screen magnifyers for the > visually impaired), or even people on alternative platforms (like tiny cellphone screens), may > experience web pages very slowly and with difficulty. Redundant information can exacerbate > their difficulties. I wasn't aware that the title attribute was intended to be interpretted by screen readers, and I very much doubt it would be displayed by cellphone software. That it might add redundant information to the *source*, in terms of a few more bytes to download, is possible, but that doesn't seem to be what you are claiming here. In fact, here's a quote from the spec [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4.3]: "For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context." By "similar context" I interpret it to mean that it will be read out when whatever kind of pointer mechanism is used is shifted to that location. > The HTML spec says that the title attribute "... offers advisory information about the element > for which it is set." It's meant to be *additional* information. Arguably, "this link is not a piped link" *is* information; personally, I use it this way. The extra tooltips don't seem redundant to me, they just seem consistent: I know that the text of a link doesn't neccessarily reflect its target; if I want to know its target, I look at the tooltip, ignoring the text. And the example in the spec looks to me very redundant by your definition: it varies by two words from the content of the A element, but in a completely arbitrary way. I think consistently using the title attribute to describe the title of the linked article is a perfectly valid and useful application of it. > Are you suggesting that all links on the Internet should have title attributes added, not to add > advisory information to the link, but to provide visual feedback about your mouse movement? No, but nowhere does the spec imply to me that a title attributes should be selective and inconsistent in order to not be redundant w.r.t. the data enclosed by the element they are attached to. Lots of things are often redundant in HTML, because they allow you to distinguish between different uses of what is often the same information: in our case, most of our link texts happen to be the same as the article name they link to, but not necessarily. Our link *titles*, however, consistently contain the name of the target article: extra information. > It's true that when WP authors use piped links poorly, it can obscure the destination of a link: > this is an authoring issue. It's addressed by good recommendations in the style guides, and by > improving confusing link text when you see it. Using technology to layer redundant > information on most links doesn't clarify, it obscures. This isn't about correct/incorrect piped link use, it's about the very existence of piped links. In fact, when copyediting, it can sometimes be useful to go through and see exactly where each link *does* point, to see whether it is the most appropriate. > Incidentally, the browser I'm using right now displays title tool-tips even when I'm > twitching my mouse pointer wildly, as long as it stays within the bounds of the linked text on > the screen for about a second. So, with your proposal, in order to confirm that a link is not piped, you'd have to judge mentally that you had hovered over the link for "about a second", i.e. long enough for the browser to have shown a tooltip if it was going to. Surely far more reliable to wait until the tooltip appears, and then read it? > To cite an oversimplified example, the style guide advises not to link the words "click here". > The solution isn't to add title text to "click here" (which the current technology would helpfully > render as "click here"). Actually, this is a bad example: that would have a title attribute matching the actual destination, with or without your proposed change. Unless, of course, it was a link to the article [[click here]].
(In reply to comment #3) > I wasn't aware that... > ...and I very much doubt... Alt, title and longdesc attributes are accessibility features specifically aimed at non-visual browsers, among others. In fact the Jaws screen reader can read alt, title, longdesc attributes, and onMouseOver function arguments. Opera for cell phones supports title attributes and displays destination URL in a tool-tip. But other similar browsers probably have different feature sets. Don't assume a feature set for a class of browsers, because there will always be one somewhere that works differently, or it will be released next week. This certainly doesn't justify ignoring accessibility features. > Audio user agents may speak the title information in a similar > context." By "similar context" I interpret it to mean that it will be > read out when whatever kind of pointer mechanism is used is shifted > to that location. There's no pointer. Screen readers, braille readers, and to some degree handhelds are "serial devices". They read everything in order, and scanning and skipping are very limited. Redundant information makes this slow process even slower. Interestingly, the designers of Jaws made it ignore title text when it is identical to link text. They decided redundant information is harmful. But don't assume that other browsers do this too. > And the example in the spec looks to me very redundant by your > definition: it varies by two words from the content of the A element, > but in a completely arbitrary way. I'll give the W3 spec the benefit of the doubt, and assume that this was meant only as an example of technique and not of good authoring style. Would anyone write this way? > No, but nowhere does the spec imply to me that a title attributes > should be selective and inconsistent in order to not be redundant The spec neither supports nor refutes anything of the sort. It deals very much with technical detail and very little with web site authoring strategies. Redundant copy is harmful. > w.r.t. the data enclosed by the element they are attached to. Lots of > things are often redundant in HTML, because they allow you to > distinguish between different uses of what is often the same > information: Examples of "lots of things" might help me understand this. > in our case, most of our link texts happen to be the same as the > article name they link to, but not necessarily. Our link *titles*, > however, consistently contain the name of the target article: extra > information. Users don't inherently know this! They just know that the first dozen tool-tips they saw on Wikipedia carried no new information, and so they stopped reading them altogether. Or they know that their screen reader annoyingly read all the links twice, so they turned off title-reading for the site (just because Jaws ignores redundant titles, don't assume that all screen readers do). I did a quick un-scientific test: clicked "Random page" and Wikipedia offered me [[Elizebeth_Friedman]]. I manually counted title tags in the content area of the page. Of 34 links, 30 were identical to the linked text, four were different: Title "October 31" for text "10-31" (twice, in a date: [[1980]]-[[10-31]]) "Greek language" for "Greek" "German language" for "German" 88% of the titles were perfectly redundant, and only the two language links added some information that I found useful -- that's a 1:17 signal-to-noise ratio! After reading this page, do you think a new Wikipedia user will ever pay attention to a title tag on the site? > So, with your proposal, in order to confirm that a link is not piped, > you'd have to judge mentally that you had hovered over the link for > "about a second", i.e. long enough for the browser to have shown a > tooltip if it was going to. In a visual browser, yes, essentially -- what's wrong with that? In MSIE5/Mac tool-tips appeared unreliably, but in Firefox and Safari they work great. Some people use them and some don't, but you can't design a site assuming that they're broken a particular way for everyone. But that's not the how web surfing works. Think of it from an average user's point of view, not as an experienced Wikipedian or computer developer: The average user doesn't have to confirm anything. He reads linked text, then moves his pointer over it, then clicks and goes to the expected destination. But if the task is *interrupted* by a tool-tip popping up, then the user is alerted that the destination is different from what was expected. > Surely far more reliable to wait until the tooltip appears, and then > read it? Stop calling me Shirley. I suppose it might be measurably more reliable in some browsers, or not -- but who does this? It requires stopping the flow at every single link, reading a tool-tip, then comparing it to the link text. This slows the user down and distracts him from what he's reading. After 16 redundant titles in a row, any waiting for tool-tips is [[history]] anyway. I suspect some users never wait for tool-tips, some develop a rhythm that allows them to flow smoothly but catch tool-tips when they appear, and perhaps some will stop the flow over every interesting link or even every link on the page. > Actually, this is a bad example: that would have a title attribute > matching the actual destination, with or without your proposed > change. Unless, of course, it was a link to the article [[click > here]]. True; I chose a bad example. My point still stands: in many well-written piped links the destination will be self-evident from the text and context, and users can just click. The title is fall-back information, flagging piped links and making their destination explicit. Having redundant titles on all other links dilutes this functionality like a can of no-name cola in my scotch.
*** Bug 2147 has been marked as a duplicate of this bug. ***
Created attachment 6404 [details] patch to suppress link titles Removes the title attribute if it matches the link text. Checks $wgCapitalLinks for case handling. Does not "consider plural or possessive links," mostly because I don't see a need for it to.
*** Bug 22294 has been marked as a duplicate of this bug. ***
See r76127
Reverted in r87030 per bug 28182
