In a world of social participation, AJAX and rich user experience, the humble hypertext link can seem so web 1.0. However, this often-neglected tag is the fundamental building block of every web application and is in the front line for usability. This article seeks to re-evaluate its role and suggest some best practice for its use.
Let’s be honest, the hypertext link isn’t very sexy. Familiarity breeds contempt the saying goes and this is certainly true for the ‘a’ tag. Every day we code it many times over without giving it a second thought. Unfortunately, as web designers we can often become sloppy when working with links and start to take liberties with the way we implement them. Not only is it incredibly common, it is also very simple: after all, its just a link. And at the other end of the scale you can find all manner of creatively styled solutions.
So in order to redress the balance I will endeavour to lay out some good practice here.
Make it descriptive
The content of a link should always clearly describe where the link goes. Simple stuff I know, however its amazing how often this most basic of principles is ignored. How many times do we see links with labels such as click here and more?
The enlightened will know that links like this create accessibility problems when read out of context by assertive technologies. In fact there is a W3C accessibility guideline that specifically addresses this issue (checkpoint 13.1):
Clearly identify the target of each link
However, instead of addressing the problem properly, some people simply add an additional title attribute to the existing links in the belief that this satisfies the guideline. In fact the W3C recommendations go on to say:
In addition to clear link text, content developers may further clarify the target of a link with an informative link title
In other words, the title attribute is a useful addition to a clearly labelled link, but not a replacement.
The problem isnt merely an accessibility issue. There are also significant usability concerns. We all know that users dont read websites, they scan them. When users are scanning a page they look for things like headings, lists and more often than not, links. Because the reader is scanning the page they often do not read the text surrounding a link and so (once again) the link needs to make sense out of context. The user is not going to hover over each link to see what the title attribute says!
Of course, as with everything, we need to be pragmatic about how we implement this. Sometimes it would be necessary to turn several sentences into a link in order to make it truly descriptive. In such cases I would encourage some common sense and good use of the title attribute instead. However the general principle stands; wherever possible make your links descriptive.
Keep users informed
Not only should a link describe its destination, it should also inform the user about any unusual behaviour. Probably the most obvious example is that it is important to inform the user when spawning a new window. This ensures you conform to checkpoint 10.1:
Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.
However, there are other occasions where the user requires additional information. For example, if a link goes to a file that is not a standards HTML page (such as a PDF, MP3 etc) then it is important to inform the user of this. Additional information such as the type of file, its size and what information it contains helps the user make a decision on whether they should follow the link or not.
How this information is displayed needs to be decided on a site-by-site basis. However, a typical approach might consist of adding the information as a title attribute or including it after the main link text within brackets.
Leave the underline alone!
Links can seem so boring. Blue by default, purple when visited, always underlined. Where’s the fun in that? As a result, we can be tempted to look for ways to make them more interesting. I am constantly amazed at the different ways we have found to mess with the underlining of links. Let’s look at a few of them and see why they can be such a bad idea.
Replacing the underline with a border-bottom
I have noticed a growing trend among designers to replace the standard underlining of a link with a bottom border defined in CSS. The argument is that this improves legibility because the default underline clips the descenders of certain characters. Although this is true and a border is often much more attractive, I have concerns about the accessibility of this approach.
The problem is that some user agents have less than perfect CSS support and fail to render the bottom border. This makes it significantly harder to identify links, especially if you have some form of visual impairment.
I have seen the problem occur with Internet Explorer 5 (which one could argue is becoming less of an issue) but also on a number of mobile devices, which is a much more significant problem.
Generally speaking it is unwise to override the browsers default behaviour and so although I wouldnt rule this approach out entirely, I would suggest some degree of caution.
Replacing the underline with a dotted line
An even more worrying trend is the replacement of the traditional solid underline with a dotted border instead. This is most commonly used to distinguish between visited and unvisited links where visited links have the less prominent dotted underline.
Not only does this suffer from the same accessibility problem mentioned above, it also causes confusion among users as it doesnt conform to their expectations of what a link should look like. Because it is unfamiliar, users doubt whether it is still actually a link. This doubt is reinforced by the fact that a dotted underline is the default browser rendering (within some browsers) for acronyms and abbreviations.
Striking through visited links
Another popular approach these days is to put a line through visited links in much the same way you would cross out an item on a to-do list. Of course this is a fundamentally flawed analogy because unlike a to-do list a user could well wish to revisit a page they have previous viewed. By striking through a visited link designers are making it considerably harder to read and therefore more difficult to find, previously visited pages.
The idea of striking through a link is not without its merits however. After all, you could argue that simply indicating visited links by colour does in fact break accessibility checkpoint 2.1:
Ensure that all information conveyed with colour is also available without colour, for example from context or markup.
Although this point is debatable, the principle of providing a non-colour based visual indicator of visited links is a good one. However, striking through the link is not the answer. Instead, consider adding an icon such as a tick immediately before or after the link. This approach does not obscure the text of the link but still communicates the concept that this page has been visited.
Removing the underline entirely
Although the abuses of the underline that I have outlined above are bad, they do at least give an indication to the user that “this is a link”. However, a growing number of sites are choosing to remove the underline entirely so leaving the user to guess as to what text is actually a link. Relying on the user to identify links by colour alone is not an advisable approach. At the very minimum they need some other visual cue that something is a link and the underline is the standard convention for this.
Ensure legibility
We have already discussed the problems associated with ’striking through’ a link. Another common practice is to ‘fade out’ visited links in order to make them less prominent. The problem with this approach is that it assumes users are not going to be seeking ways to return to previously visited pages. Users still need to be able to clearly read visited links and so they need to have sufficient contrast with background colours.
Indeed, all links (both visited and unvisited) need sufficient contrast in order to conform to accessibility checkpoint 2.2:
Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits or when viewed on a black and white screen.
Use clean semantic markup
The majority of this article has focused on the content of your link or how it is visually displayed. However, it is just as important to ensure that your link is properly marked up.
Although we all know how to create an ‘a’ tag it is still remarkably common to find this simple piece of code being abused. The most common culprits are the addition of style or behaviour elements into our code.
Let me give you an example of what I mean. Setting aside the ‘ethical’ debates about whether this is a good idea, it is not uncommon for links to external sites to open in a new window. I have encountered many sites that include code like this:
<a href="javascript:window.open(http://www.boagworld.com)" style="background: url(external.gif) no-repeat right;" >Boagworld</a>
When in actual fact the HTML could be as simple as this:
<a href="http://www.boagworld.com">Boagworld</a>
The rest could be managed using external style sheets and Javascript includes. A Javascript function could easily scan through all of the links on a page identifying those that link to an external domain. It could then override the default behaviour and open that link in a new window while at the same time applying the visual styling to the link.
This approach is the principle of Unobtrusive Javascript and provides many benefits most of which are beyond the scope of this article. However, it is worth noting that not only is your code cleaner, but this approach also allows you to change the default behaviour of your links without having to edit every link on the site.
Finally, this article would not be complete without briefly mentioning the application of Microformats to link elements. Like Unobtrusive Javascript, Microformats are far too broad a discussion to cover here (but read John Alsopps article for a comprehensive overview).
However, it is worth noting that it is possible to add a vast amount of semantic meanings to links simply by marking them up as Microformats. Through Microformats you can specify whether a link relates to creative common licenses, or whether it contains contact or event information. You can review links, tag links or even explain your relationship with the website owner being linked to. Although Microformats are still in relative infancy, the potential for building applications that leverage all of this hidden meaning is immense. Best of all, this is achievable by simply adding some extra attributes to the humble ‘a’ tag.
A fundamental tool
Hopefully this article has given you a renewed respect for the humble hypertext link and helped you recognised the fundamental role it plays.
I know that throughout much of it, I have sounded like a killjoy, intent on crushing any creativity in your design. But I think it is important to remember that our job is to improve usability not produce a piece of modern art. The majority of people using the web lack confidence. To them every time they go to a different site they are faced with a new and strange user interface. We have no right to undermine one of the few consistencies they have between sites… the humble hypertext link.
Like this article? Digg it!
Do we need to use that unobtrusive function? Whats wrong with old target=”_blank”?
saski –
nothing is technically wrong with that attribute; however as far as the W3C is concerned, you should make your users aware that the link will open a new window (commonly done via an inline icon added via CSS).
@saski, the target attribute is not valid under XHTML so i guess it depends on what you are using.
Nice article, Paul. I would agree with most of your points. The one area that is somewhat gray for me is the ‘more’ text for a link. For instance, on www.barbourbooks.com I use a ‘More’ link because it would be ridiculously redundant to spell out the entire title again, and it wouldn’t make any sense if I randomly placed it within the brief description. I have seen in our analytics that more people actually click on the ‘More’ link because it is placed in context. The title attribute states ‘View {book title}’ - but I don’t want to be redundant with the title already presented above.
I believe that in some instances it is OK to use that (even though I don’t advocate it for everything). For my instance, this seemed to be the best approach to work with without being wordy. Also, each book is its separate contained list item - so everything is grouped together accordingly.
What are your thoughts related to something like this?
So. We have an article on the abuse of links on a site which uses Snap (I’m not the only one)! Cut the Snap crap, please.
Also, “the few consistencies they have between sites” is somewhat contradicted by the gist of the rest of the article. Perhaps you mean something more like “the few consistencies that exist across browser rendering engines”
Snap is great. Lets me see a site before committing to following the link. The benefits of that greatly outweigh any problem snap might create.
I also see a lot of links on this site that do not have underlines. Such as author name and web site, email to a friend. I think it probably would be best to include what you feel are ‘acceptable’ exceptions. Although I don’t think there are any for hypertext.
I agree with Mike… the snap stuff is annoying. Keeps me from moving my mouse around so that I can read the content.
Great article Mr.Boag. Thanks for pointing out all those interisting points. Gongrats also for your great podcasts.
target (not that I like the attribute) is perfectly valid unde XHTML 1.0 with frameset DTD: http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-frameset.dtd_link
As for link underlining and accessibility, well… maybe there will be a time when you find out what it is and what it isn’t.
RE: Rimantas
Its valid with a frameset, yes, but then if you are using frames (to point to external links/internal frames) you have a whole other world of issues. We are talking strict HTML/XHTML - which it is not valid.
Also, everyone needs to remember that Mr. Boag doesn’t work for Think Vitamin, he simply submitted the article. I think it’s somewhat petty to nitpick at the site when he had nothing to do with it.
And snap can go right into the garbage.
The target attribute is not valid in strict mode, whether that be HTML or XHTML, transitional and frameset will validate.
About the target discussion: target is a separate module that can be bolted easily and perfectly valid on the XHTML 1.1 DTD. Alas only a handful people seem to know about that, so the “myth of the deprecated target attribute” is commonly repeated. The target attribute is just not part of the basic set of XHTML module, that’s all.
Yes, but there is a reason that the target is not part of the XHTML module. Taking target out of hypertext links separates behavior from markup, and Javascript should be used to support a pages behavior.
Just use DOM Scripting to add the attribute to the tag, and if the user doesn’t have Javascript turned on, then they won’t be popped up with a new window.
Just because XHTML is eXtensible, doesn’t mean that target wasn’t deprecated for a reason.
Good article, but I don’t agree that it’s sufficient to identify links to PDFs, .doc, .xls etc only with the title attribute..
It is much better for sighted users to indicate the format and file size in brackets immediately after a link so that they don’t have to bother hovering over a link to see where it goes (many will do this by looking at the status bar rather than reading the link title).
And links to PDFs and those other formats should open in a new window. Both these practices — indicating formats and sizes in brackets and opening in new windows — are convention on most sites I review. So it would help tremendously if these decision were not made on a site-by-site basis.
@Nate
Thanks for the reminder. I guess I should have said something along the lines of….
“I wish the Vitamin site better represented many of the articles that it presents”. And please do not misunderstand… I do love this site for the content and thus visit whenever a new article is posted.
I do wish those who claim to be experts would actually practice what they preach. I browsed this page through a non-visual browser and there’s plenty of non-semantic markup.
So stop telling me how I should or should not format my hyperlinks. As long as they are accessible and consistently styled, logical and consistently styled then I’ve done a good job.
My previous comment has been swallowed by Akismet, so again without links to the specs and drafts: the
targetattribute has never been deprecated.Some consider it “de facto” deprecated because it’s not in HTML 4.0 Strict or XHTML 1.0 Strict. Others argue that was just a mistake because in fact it’s not marked deprecated in HTML 4.0, it’s a module in XHTML 1.1 (optional because of its relationship to the optional
frameandiframemodules), it’s in XHTML 1.1 Basic, and in XHTML 2.0. Perhaps we can call it a draw then.Jared, I do understand your argument that
targetis more of a behavior and therefore belongs into JavaScript. And personally from an accessibility and usability standpoint I’m against using the attribute at all. But simulating that browser behavior in JavaScript seems also like a programmatic overkill, therefore I’m not happy with it either…Using target on a link is in my opinion no better than using onclick=”somefunction()”…
as the author says, all these behaviors should be added with javascript. Can’t see how it’s overkill either, you write a function once that finds all links that points to external sites and then just include that function in your common.js page init function and be done with it. adding target=”_blank” to every link sounds a lot like overkill to me…
Regarding snap, using FF with NoScript easily allows you to forbid any javascript from running.
I’m a little confused, I surf loads of websites and come across loads of link styles.
All the various styles of formating a link don’t confuse me about whether or not they are links and I’m not entirely sure it would confuse a normal user, if you can click it and it is labeled with something you want you click it.
I don’t think average users get to see so many ‘correctly’ formated links for them to get used to how links should be so I’m not sure that guidelines to formatting links help so much.
Maybe in an ideal world all links would be the same, then it would make sense to keep them the same to avoid confusion but as it is I don’t think there is too much confusion about what are links on a site however they are formated.
I do agree that links should be descriptive and keep users fully informed but as for formating I tend to think that as long as an average user can identify that it is a link then it is valid.
@Nate: Re multiple ‘more’ links, a sighted user can see the context of the link, and make the connection between the link and the preceding content. Screenreader users can’t make that connection, and rely on the link text to explicitly indicate its destination.
One solution is to use CSS to place the part of the link you don’t want to be visible off-screen - example @ Blether
@Crake: “I tend to think that as long as an average user can identify that it is a link then it is valid.”
Well, doesn’t that just suck for anyone who isn’t “average”, and maybe can’t see, or who has to use a device other than a mouse to navigate, or who is colour-blind?
The basics are very simple - underline links, make link text uniquely descriptive across a page, and ideally style for keyboard users too, with the :focus and :active pseudo-classes.
[…] Don’t be the weakest link Paul Boag discusses some of the accessibility and usability issues around the way we style up the humble hypertext link […]
[…] Don’t be the weakest link […]
@Dan
Maybe the word “average was the wrong word for me to use, maybe I should have said majority, but that probably isn’t right either.
If everyone can identify the link with any device then is it valid? Using the given rules can achieve this, but is it wrong to look for a different way, or choose link styles on a per design basis.
[…] satzansatz — CSS: background images lost on multi line inline links in IE6 Bezüglich "unterpunkteten" Links stimme ich völlig mit Paul Boag überein, ganz besonders bei Zielgruppen, die wenig Web-Erfahrung mitbringen. […]
A good article but it could do with some copy editing! As well as numerous missing apostrophes we have:
uh, yeah, semantic markup is best generally,
but let’s also remember, nothing can be designed for all users and user agents. It is your job to design for the intended audience.
If I write a page for a site in Japan, it damn well better be in Japanese.
as for target and resulting action of a link, it largely depends on the user agent.
many user agents offer little control over the resulting action of a clicked link yet attempt to follow a list of mime types.
xhtml offers little to no control over this as well.
perhaps you do not wish for a non-xhtml/xml file to load into a browser window…
the old force download is impossible without lying about the mime type or having an overly complex server side action to send each user agent a differently packaged file…
make your links how you like them, how they work for you and your target audience.
Good article, Paul. I am curious as to what happens when we put all of the suggested practices into place? What would a visited link to an external PDF document look like?
[…] Don’t be the weakest link […]
[…] et surtout ça modifie le comportement standard de l’élément de base du world wide web : le lien hypertexte. […]
XHTML 1.1 Second Edition With Target Attribute…
When I switched from HTML 4 to XHTML 1.1 in 2004 I soon found the target attribute was missing. I have never been in love with the target attribute anyway, but some clients insisted that their links should open in a new window. So I did some …
The enlightened will know that links like this create accessibility problems when read out of context by assertive technologies.
Amen. This is one of my pet peeves, but unfortunately also one of the hardest to implement when others have control of screen real estate.
Just using a link title as Nate suggests is not sufficient. Not all screen readers read titles (because they have no equivalent to a “hover” behavior) — and most of the ones that do, have that feature turned off by default.
Oh, and Paul, where can I get my hands on some of these assertive technologies? Mine are all so darn passive. ;)
I personally am a big fan of the non-underlined link. Like John said, these may be good guidelines but you should always design for your target audience. If a non-underlined link is perfectly understandable to be a link via context and color, there’s no problem with leaving the underline off.
Javascript should never be used as the sole activator of links. Javascript links can fail or be unavailable for many reasons, but a regular hypertext link works for everyone.
Non-underlined in-text links are only okay to use when links are always a reserved color that is not used for other words, and when all the users can see that color (or perceive that difference in color). Never forget that a large proportion of men are color blind to one degree or another. They tend to rely on contrasts.
People don’t want to scrub the screen to find the hidden links. Underlines work best so far for in-text links. People who hate them can turn them off with their browser settings.
It’s probably not necessary to underline lists of links, headings, URLs and email addresses in most cases, because they are assumed to be links, but again, a dedicated link color is important to help these interactive spots stand out so people can find them quickly and overlook them less. And it’s often good to expose key email addresses and URLs on the page in case it is printed.
I saw a few people ripping into Snap. Recently they added the option of an icon immediately after the link so the “annoying” window doesnt pop up unexpectedly, but only if you deliberately mouse over it. Snap works quite nicley and blends into our site’s style quite nicely - but then we aren’t a serious bunch like some places.
I think most users are quite quick to work out a basic link however it is styled, but all users? unlikely to please all the people all the time.
Good article again, Mr Boag
@boag
“replacing the underline with a border-bottom”
Can you not stick to a padding-bottom value and combine with the underline
Nice article, Paul!
I found it comforting to see some of my own thoughts brought to words by the hands of a recognized specialist.
Just one suggestion: pay more attention to what you write. There’s quite a few typos in the text ;)
[…] Don’t be the weakest link […]
I think some of this is a little unnecessary, and horses for courses and all that, but you are right to draw attention to the building blocks. Good food for thought!
Thank you for all these advises. But one question. What about all the sites what are not written in HTML-Strikt. They are bad in ranking? What are the consequenses if our sites can not pass the W3C-Test?
[…] Vitamin Featuresin julkaisema, Paul Boagin kirjoittama artikkeli Don’t Be The Weakest Link käy läpi perusasioita, jotka saattavat monesti unohtua. Englanninkielisiä termejä viljelläkseni: monta hyperlinkkeihin liittyvää best practicea kiteytettynä lyhyeen tilaan sekä yksi tärkeä reality check: I think it is important to remember that our job is to improve usability not produce a piece of modern art. […]
bikini g string…
ka-ka-sh-ka 4770985 bikini g string info…
Good article, Paul.
but you sad ..
{ ..When in actual fact the HTML could be as simple as this:
Boagworld … )
for serp and seo .. we have to use title or alt tags for link . i think :( ..
when i use your txtlink style technique .. like this .
Boagworld
where i should to use title or alt tags ??
thnks again ..
Good article! your site let me learn more. Thanks! And please keep up to date.
[…] Don’t be the weakest link Paul Boag discusses some of the accessibility and usability issues around the way we style up the humble hypertext link […]
very usefull and great article i just wanna say thank you man.
[…] - Paul Boag @ Vitamin […]
[…] Don’t be the weakest link provides an overview of both styling and using links. For example, using informative link text, possibly adding titles (tooltips) and using semantic html markup. […]