Last modified: 2011-04-27 22:29:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 542 - Link text shouldn't be duplicated in title attributes
Link text shouldn't be duplicated in title attributes
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Lowest minor with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: accessibility, patch, patch-need-review
: 22294 (view as bug list)
Depends on: 28182
Blocks: 367 27527
  Show dependency treegraph
 
Reported: 2004-09-20 21:18 UTC by Michael Zajac
Modified: 2011-04-27 22:29 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
patch to suppress link titles (619 bytes, patch)
2009-07-30 00:45 UTC, Jonathan Chang
Details

Description Michael Zajac 2004-09-20 21:18:19 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.
Comment 1 Rowan Collins [IMSoP] 2004-10-03 17:55:19 UTC
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.
Comment 2 Michael Zajac 2004-10-03 21:48:34 UTC
(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.
Comment 3 Rowan Collins [IMSoP] 2004-10-03 22:23:43 UTC
(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]]. 
Comment 4 Michael Zajac 2004-10-04 18:07:54 UTC
(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.
Comment 5 Brion Vibber 2005-05-15 05:05:33 UTC
*** Bug 2147 has been marked as a duplicate of this bug. ***
Comment 6 Jonathan Chang 2009-07-30 00:45:58 UTC
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.
Comment 7 Chad H. 2010-01-28 00:31:29 UTC
*** Bug 22294 has been marked as a duplicate of this bug. ***
Comment 8 Mark A. Hershberger 2010-11-05 19:11:15 UTC
See r76127
Comment 9 Platonides 2011-04-27 22:29:28 UTC
Reverted in r87030 per bug 28182

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links