The link
The defining feature of the Web, if it has one, must be the hyperlink. Without the link, each web page would be a solitary unit, and you would have to know the address of each one to access it. With the link, web pages interconnect to form a historically unique information resource.
Problems with links are serious. The most obvious problem is the broken link — a major failure in the functionality of any web site. It happens to everyone sooner or later, especially with external links, but that is no reason to be complacent. Broken links always give the impression of incompetence, whether that’s justified or not. Get into the habit of regularly checking your site’s links — and make sure you don’t make stupid mistakes with URLs.
Aside from that, the basic problems with links tend to be related to the information presented to the user: where does this take me?; have I been there before?; is this a link or isn’t it? The use of images as links has other problems, too, but today we’ll concentrate on text links.
What’s a link and what isn’t?
The defaults of most browsers show links blue when unvisited, purple when visited and usually links are underlined. It is possible to change the colour settings using the attributes of the <body> tag, and to change the colour settings and remove the underlining using CSS. In fact, with CSS you could play other tricks, such as rendering all visited links with a score through them.
The question is, why should you want to?
The Web is built on links and the crucial thing a user wants to know on any web page, regardless of the subject matter or purpose, is what is a link and what isn’t. The combination of colour-coding and underlining gives two clues to the user that the text in question is in fact a link.
If the link in question is in a section of the page clearly devoted to navigation, such as this page’s nav bar, then there is probably no harm in turning off underlining — and that may in fact improve the clarity of the menu.
Links occurring in the body text are a different matter. You can’t rely on colour alone to differentiate a link from the surrounding text — what happens, for example, if the user has a monochrome display? Underlining provides an essential secondary clue to identify the links, which would otherwise then be indistinguishable from the rest of the body text.
Do not, however, make the link colours the same as the colour of the body text and trust to the underlining to identify the link. For one thing, some font faces and sizes make picking out underlined text difficult; for another, some browsers don’t underline link text (or can be configured by the user not to underline it). The colour difference is important in making the link obvious.
The question of colour
There are those — do I really need to say that Jakob Nielsen is prominent among them? — who say that you should never, ever alter the colours of links. The rationale is: people know blue=unvisited link, purple=visited link. If you change these colours, then users won’t know that what they are looking at is a link and they will get confused.
There is certainly a good argument for not changing link colours for no good reason, but Nielsen & Co.’s blanket statement that they should never be changed is a bit much. It’s a bit much because:
- It assumes that users are idiots. If a user goes to a site and sees some text (particularly underlined text) which is a different colour from the surrounding text, the first thought would be that is probably a link.
- It would mean that all web pages would look alike: no using of shades of blue as a background, because that will lose contrast with the unvisited links; no use of shades of purple because you won’t be able to see the visited links; no use of dark colours at all as backgrounds.
Of course, Nielsen has said before that all web sites should look alike (Websites must tone down their individual appearance and distinct design in all ways
), because that way there is no learning curve for users going to a site for the first time. I don’t think users want a Web as boring as that would be; I’m certain designers don’t want it.
Certain uses of colour, though, are confusing. Using red or purple, for example, for unvisited links may lead users to assume erroneously they have visited the link in question.
I understand the argument put forward by some that red means important, therefore it is sensible to use it for an unvisited link. David Siegel, of course, is in this camp:
They needed to decide which colors to use for links. So they said: “Let unvisited (hot) links be blue, and visited (cool) links be purple!” And so it was. And it was good. Or so they thought. In fact, it was not good. It was a mistake. It was not their first mistake, but it was a biggie. Then again, how were they to know 5 million people would soon be straining their eyes to see their link colors?
His use of the adjectives “hot” and “cool” loads the question. (Most people would probably use “hot” in this context as meaning “something which is clickable”; the phrase “cool” link, though, means something quite different to most people on the Web to what Siegel means.) He naturally goes on to say:
So, if you think about it a bit, the right choice is to turn the “hot” unvisited links red and leave the visited links distinguishable, but “cool,” receding into the black text. Red says “Over here! Hit me!” Blue says “Been there, done that.” Blue recedes into the background. I want my visited links to become associated with (but distinct from) the text and leave the active (unvisited) links standing out. Hot red and cool blue links should be standard on all browsers, but they aren’t.
Well, of course, he is right and everyone else is wrong (his attitude to more than just link colours: see the article on alt text and its sidebar), so his sites use red for unvisited and blue for visited. Logic may be on his side but the rest of the Web isn’t, so it is very confusing to visit, say, Creating Killer Web Sites [That original CKWS site has now been moved to this URL.] and see what seems to be a lot of links to pages you have already visited.
Jakob Nielsen accepts that blue is not the best choice of colour but he says:
If we were designing the Web from scratch, I would recommend using a different link color than blue. Since we are designing sites for the Web as it exists, I retain my recommendation to leave the standard link colors alone:
- Blue text means “click here” on the Web, so by keeping unvisited links blue, there is no doubt in users’ minds as to what they can do. The time they save by knowing what to do on a page is probably much bigger than the time they lose by having the few words in the hypertext anchors be a few milliseconds slower to read.
- Even more important, knowing the difference between unvisited (blue) and previously visited (purple) links helps users understand the structure of the website and their own navigation history. On sites that change the colors, we often observe users revisiting the same pages again and again because they do not realize that they have already seen those pages. The added confusion, substantial navigation delays, and reduced probability of ever finding the right page are all very severe usability penalties from changing the default link colors.
Or, as he says, If 90% or more of the big sites do things in a single way, then this is the de-facto standard and you have to comply.
Well, most sites do adhere to blue for unvisited, purple for visited — and more importantly almost all browser vendors do, with one or two preferring red instead of purple. You can’t, then, switch the colours around and expect there to be no problems, not that that will hold back those arrogant enough to stamp their heels and thcweam and thcweam until they are sick that the colours should be the other way round and that’s the way they’re going to do it, so there!
Besides, I am not at all convinced logic is on Siegel’s side (or Nielsen’s when he criticised the usability of blue). For one thing, do you find yourself “straining” your eyes to read the link colours? In fact, the short stretches of blue that are hyperlinks are very easy to read (assuming a sensible background to the text).
Try as an experiment making two copies of a paragraph, one red and one blue: the red text is much less easy to read. Red is also much more obtrusive: reading a body of black text containing some blue links is much smoother than it would be if those links were red. As for the visited state, those few browsers which use red show how irritating that would be; most browsers use a shade of purple which merges easily into the rest of the text while being easily found if you want to look for it.
Siegel’s arguments also depend upon the attention-getting character of the colour red while ignoring the fact that red is very strongly associated with warning. Red lights in most contexts do not mean “Over here!”, they mean Stop! Is it so illogical to use red/purple to mean “Stop! You”ve been there, don’t click this”?
Against all the above, a totally different scheme (i.e. not using either blue or red/purple) can work if it is in fitting with the design of the site and there is sufficient contrast between the visited and unvisited state (and between each and the body text). If using new colours, the unvisited link state should be more prominent than the visited state.
It should be obvious by now that you must avoid making the visited and unvisited states the same colour. The colour change is the only clue users have that they have visited the link. Remember that you may have different links, differently worded, in different contexts leading to the same page. The colour change indicates to the user that they have visited that link, so there is no need to waste time loading it again.
It is also important not to use styles for plain body text which may lead to confusion with links. If a user sees blue text, it will be assumed to be a link. If a user sees underlined text, it will be assumed to be a link. These are facts you simply need to accept, because you can’t change them. If you go ahead and use blue and/or underlining on text which is not a link, users will click on it and get very irritated. Is that really what you want?
One bit of crass stupidity I didn’t consider at the time — because it honestly never occurred to me that anyone would be so stupid (given some of the stuff I had seen, I don’t know why, but…) — was styling links so that they looked exactly like plain body text. So that, in fact, it would look like this link does (assuming a CSS-capable browser). Can you believe I have actually seen two sites which did this? The only way you could ever spot the links (unless your browser can list all the links in a page) would be if you happened to run your mouse over them and saw the cursor change. Do you routinely run your mouse over all the text on a page looking for hidden links?
What I think was going through the mind of the authors of the pages where I saw this, er, technique in use was that they envisioned their documents as being like an online book — and books don’t have blue, underlined phrases in their text, do they? The fundamental folly of trying to make the Web work like print media is always pretty clear, but this really does push that envelope of stupidity a bit further. I have checked the only one of these two sites for which I can recall the URL, and they have fixed this. They still can’t spell Hitler’s first name (seriously), but that’s not really relevant here.
It gets better. Well, not better, no. Some time after I found that site, someone showed up on Usenet (I can’t track the post down, unfortunately) saying that not only did he want to make his links look like the rest of his text, he wanted to prevent the cursor changing when it was moved over the links! Seriously! It’s a bleeding obvious question, but one that clearly hadn’t occurred to him: if the links look exactly like the rest of the text and the cursor doesn’t change on moving the mouse pointer over them, just how are people supposed to find them? (I think that he was dissuaded from implementing this notion… I hope so, anyway. I have sometimes wondered, though, if he went through with it and removed the status bar display of the URL, too. Well, why not go the whole hog?) There is, by the way, just such a link in this paragraph, in case you need convincing of how silly this idea is.
Links need to be visible. If you get nothing else right, you must get this right.
Where will it take me?
A link should give some indication to the user of what will happen when they click on it. There are three sources of information for the user: information in the browser’s status bar, tooltips and the link text itself. Of these, the most important is the link text.
Text enclosed in an anchor element is usually rendered in blue and underlined, so it stands out from the rest of the text; even in Lynx, which does not display any graphics and has only limited text formatting, links are displayed prominently. This screenshot of an early version of this page in MacLynx shows the first link on the page highlighted in reversed text, and the next link in boldface.
The effect of the link text standing out so prominently is that the user can scan the page looking only at the links. If the link text is meaningful, the user can spot quickly a link which he may be interested in following.
On the other hand, if the link text is “Click here” (or something similar) the user is given no information about where the link leads. The only way for her to find out is to read the surrounding text. This makes the process more time-consuming and less enjoyable for the user.
Remember: making link text descriptive of the destination increases the usability of your page enormously.
The status bar
The information in the status bar (where there is a status bar) generally defaults to the URL the link points to. That in itself is a useful piece of information, to those who understand the directory structure even a little. It is possible to use JavaScript to modify the status bar message:
window.status = 'New status bar message';
If you do this, you need to ensure that your message is actually helpful. Again, messages such as “Click here!!” are not any help to the user.
I have used status messages on this site because I know that not everyone finds URLs helpful. Hyperlinks internal to the site are presented like so in the status bar:
::don't lock me out::
::book reviews::the guns of the south::
Hyperlinks to other sites are presented like so:
- useit.com: jakob nielsen's web site -
- blackstar.co.uk -
I am not completely consistent about this and may drop the status bar messages [Yep, I’ve dropped them: the utility of having the URL visible to the user is greater than any information I might provide instead.]; this is because talking to people who have used sites I have designed, I have discovered that almost no one notices status bar messages most of the time.
One occasion when it is definitely best not to interfere with the status bar messages is when the link is a mailto: link. In most systems, clicking such a link will bring up the default e-mail client with an open new message window. Most systems, not all: those users whose setups don’t support this need some way of getting the email address; if it isn’t actually given in the text, having it show up in the status bar is a good fallback.
If you do change the status bar message for a mailto: link, incorporate the e-mail address in the new message.
Tooltips
Tooltips are little pieces of (hopefully) helpful text which are displayed when the cursor is over certain objects. Here’s an example:
![[Image: tooltip appears when cursor over link]](../images/examples/tip.jpeg)
It’s important to remember that not every browser supports tooltypes. Don’t, therefore, make the tooltip your only source of information to the user.
The tooltype is generated from the contents of the title attribute of certain elements. In this case, we are concerned with the anchor element, but other important instances are <img>, <abbr> and <acronym>. The relevant piece of markup (stripped of some of the other attributes for clarity) from the example above is:
<a href="[URL]" title="Buy HTML: The Complete Reference from Amazon"><img src="[URL]" alt="[Image: cover of the book] " /></a>
If the title attribute were not present in the <a> tag, some browsers might display the contents of the <img> tag’s alt attribute as a tooltip. This is a non-standard approach, and not a good one because the purpose of the alt attribute is quite different from the title attribute.
The alt attribute has the specific purpose of taking the place of a graphic when the graphic is not rendered — if, for example, the browser doesn’t support graphics or the user has disabled image loading. The title attribute is there to provide a tooltip, when the browser supports that, which provides additional information to the user beyond the plain text or the graphic used as the link.
Tooltips should be used with great care. Some people find them an irritant all the time; most people find them irritating some of the time. I have encountered sites which were unusable because persistent tooltips obscured several links (these sites used JavaScript-generate tooltips, which are less responsive than the standard HTML tooltips and should be avoided). It is best to restrict them to instances when a little extra information could benefit the user.
But remember: the most important source of information is the link text itself. Status messages are JavaScript-dependant, and won’t be displayed if JavaScript is disabled. Even if they are displayed, a remarkable number of users are completely unaware of their presence. Tooltips are not displayed by every browser. The only source of information you can guarantee your user will see is the link text.
Summary
- Broken links are critical failures of a web site: check links regularly. (The W3C provides a link checker.)
- Don’t change link colours for no good reason, and don’t make them indistinguishable from plain text!
- If you do change the link colours, don’t muddle the established colours (e.g. using purple for unvisited, blue for visited).
- If you change the colours, the unvisited links should always be more prominent than the visited.
- Don’t turn off underlining for links surrounded by plain text.
- Don’t use underlining for non-link text: use
emandstrongfor emphasis, there’s no need to confuse users by underlining plain text. - Similarly, don’t make plain body text blue (or any other colour you may be using for links).
- Use informative text for your links; avoid unhelpful link text such as “click here”.
- Don’t make status bar messages or tooltips the only source of information to the user.
- Always make sure that
mailto:links provide the e-mail address in the status bar if nowhere else. - To generate tooltips, use the
titleattribute; don’t misuse thealtattributes of<img>elements used as links.
Further reading:
- W3C/WAI Techniques for Web Content Accessibility Guidelines:
http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text - Alertbox: Fighting Linkrot
http://www.useit.com/alertbox/980614.html - Alertbox: When Bad Design Elements Become the Standard
http://www.useit.com/alertbox/991114.html
© DC 2000, 2001, 2005. All rights reserved.


