Page MenuHomePhabricator

Link text shouldn't be duplicated in title attributes
Closed, DeclinedPublic

Description

Author: michael

Description:
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.


Version: unspecified
Severity: minor

Details

Reference
bz542

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 6:57 PM
bzimport set Reference to bz542.
bzimport added a subscriber: Unknown Object (MLST).

rowan.collins wrote:

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.

michael wrote:

(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.

rowan.collins wrote:

(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]].

michael wrote:

(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. ***

jchang641+bugzilla wrote:

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.

Attached:

  • Bug 22294 has been marked as a duplicate of this bug. ***

Reverted in r87030 per bug 28182