Tagged “links”

Adrian recommends that we underline links in body copy and provides a host of evidence and rationale to back that up.

WCAG guidelines tell us to make sure we do not rely on color alone to distinguish links and even explicitly suggest underlines.

Usability researchers and practitioners generally suggest that underlines are the most clear way to indicate a link that lives within content.

Academic researchers confirm that … when you have them you can reduce additional cognitive load by making them apparent. Underlines performed well.

There are other sites on the web which have set expectations, but many of them likely do not correspond directly to your own circumstance. Additionally, some of them are already violating WCAG, which removes them from consideration as appropriate analogues.

Other styling options can work, but they are not necessarily universal, sometimes requiring users to learn them. They may also conflict with other styles on your site, increasing the effort (cost) for you to come up with usable, novel and progressive indicators.

Given all these factors, I recommend you underline links in your body content.

Heather suggests that in developers’ excitement to do cool new stuff and use cool new tools and techniques “we stopped letting people do very normal web things”. Things like:

• the ability to copy text so you can then paste it
• ensuring elements which navigate also behave like normal links by offering standard right-click and keyboard shortcut options etc. Which is to say – please use the anchor element and leave it alone to do its thing
• letting people go back using the back button
• letting people scroll with native scrollbars. Relatedly, letting people get to the links at the bottom of the page rather than having infinite scrolling results which mean that the footer is always just beyond reach!
• letting the user’s browser autocomplete form fields rather than making them type it

You have a “card” component which includes a heading, some text, an image, and a link to the full article, and it’s working great. Then along comes a UX requirement that the full card (not just the button or link) should be clickable. This is where things get complicated.

TL;DR

I was recently faced with this challenge while building a component at work and opted to implement a tailored version of Heydon Pickering’s Redundant Click Trick. This felt like the best approach, or perhaps more accurately “the lesser of three evils”. I’ll be monitoring how that performs, but in light of the knowledge and experience gained carrying out this task I’m also starting to think that – like Chris Coyier recently suggested – maybe full-card clickable regions are a bad idea.

Setting the Scene

Let’s say our starting HTML is this:

<div class="card">
  <h2>Card Title</h2>
  <img src="/path/to/img.jpg" />
  <p>This is the body copy for the card. It it is comprised of a few sentences.</p>
  <a href="/">Read more</a>
</div>

And the requirement we’ve been given is to make the whole card clickable rather than just the “Read more” link.

Option 1: Stuff everything inside an anchor

Here’s the thing – since the dawn of HTML5 we’ve been able to wrap the inline anchor (<a>) element around block-level content such as headings, paragraphs, and <div>s… so isn’t the answer just to do that?

<a href="/">
  <div class="card">
    <h2>Card Title</h2>
    <img src="/path/to/img.jpg" />
    <p>This is the body copy for the card. It it is comprised of a few sentences.</p>
  </div>
</a>

Well, as with many HTML challenges, just because you can do something doesn’t mean you should. I always had a nagging doubt about stuffing all that disparate content inside a single anchor, and Adrian Roselli has recently confirmed that for screen reader users this approach is harmful.

Perhaps the worst thing you can do for a block link is to wrap everything in the <a href>… for a screen reader user the entire string is read when tabbing through controls… taking about 25 seconds to read before announcing it as a link.

Furthermore, images nested in this way are not clearly announced as they normally would be.

So if you care about the user experience for those people, this feels like a no-no.

Option 2: Stretch a standard anchor using pseudo-content

An alternate approach that’s gained traction over the last couple of years involves leaving the anchor or button in its initial position within the card (thereby avoiding the above mentioned accessibility problem) and using pseudo-content to stretch it to cover the entire card. This CSS-only trick involves setting the card to position:relative then giving the anchor (or button) :after pseudo-content and absolutely positioning that to the card’s four corners. This makes the whole card clickable like a button.

The problem with this approach is that any text in the card is no longer selectable.

Some might say that this is OK. Personally I feel that it is a fundamental usability requirement that text on a web page be selectable. Not being able to do so calls to mind the bad old days before web fonts where we used images for headings, and I like to think we’ve evolved from those kind of practices. Also, I feel any statement by us developers and designers that “losing the ability to select text is OK” lacks validity because we are biased; happy to justify taking away something fundamental from our users because we’re more concerned with getting a (frankly non-essential) feature over the line.

If we don’t like this compromise but are still determined to make the full card clickable, there’s one further option.

Option 3: The Redundant Click Trick

This technique, conceived by Heydon Pickering, uses JavaScript rather than CSS to make the card clickable.

Essentially we add an EventListener for a click on the Card and when one is detected, trigger a faux click on the inner anchor or button.

One challenge inherent in this approach is that a user attempting to select text would unintentionally trigger our faux link click. However we can again use JavaScript (using the onmousedown and onmouseup events) to detect the length of their press to infer whether they are selecting text or clicking, then take appropriate action.

The pros of this approach are that we avoid the screen reader problems and the inability to select text.

The cons are i) that it requires a more complicated, JavaScript-based approach; and ii) that the need for a “check how long the mouse has been pressed down” part isn’t ideal.

With this approach, if Analytics tracking is part of your mix I’d make sure to check that that works as expected across browsers and devices.

Summing up

So there we go – three ways to achieve a “block link” or button. But given the compromises they involve, perhaps the question should be – is it worth it? And given the tools we currently have available, I lean towards “no”.

References

Block Links, Cards, Clickable Regions etc by Adrian Roselli.

Cards by Heydon Pickering (in Inclusive Components).

Block Links are a pain and maybe just a bad idea by Chris Coyier on CSS-Tricks.

Removing underlines from links in HTML text presents an accessibility challenge. In order for a design to be considered accessible, there is now a three-sided design contraint - or what I call "The Contrast Triangle". Your text, links and background colors must now all have sufficient contrast from each other. Links must have a contrast ratio of 3:1 from their surrounding text. By not using underlines, a design has to rely on contrast alone to achieve this.

It’s interesting that Chip says that this level of contrast is needed “when we don’t use underlines on links”.

By not using underlines, a design has to rely on contrast alone to achieve this.

So this seems to be yet another good reason to include underlines in links, i.e. if you underline your links then you don’t need to worry quite as much about a third level of contrast.

Indeed, when you toggle on the “Show underlines” option on this tool, it then removes the requirement to ensure additional contrast between hyperlinks and standard body text.

However, even if your links in flowing prose are underlined, there’s always likely to be places (Navigation, Footer, CTAs etc) where you’ve probably disabled underlines on links for design effect, so I reckon this is useful for most websites.

(via https://twitter.com/jamesmockett)

For many years I’ve been applying cursor: pointer to buttons because it felt right and would improve the user experience.

As Florens Verschelde explains, that approach is probably best avoided. I was going against the W3C’s spec that cursor: pointer should be reserved for links, and was adding to the usability antipattern where “everything resembles a link”.

I’ll leave button cursor behaviour as it is from here on in.