summaryrefslogtreecommitdiff
path: root/src/old-no-longer-pub/2014-05-16_should-you-wrap-headers-images-and-text-links.txt
blob: 853275f2558b54c5b2b6c4a2962810d443ee0678 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
---
title: Should You Wrap Headers, Images and Text Together in Links?
pub_date: 2014-05-16 12:04:25
slug: /blog/2014/05/should-you-wrap-headers-images-and-text-links
metadesc: What happens when you wrap large amounts of text and images in link tags?
code: True

---

Question marks in headlines are a pet peeve of mine because the answer is [almost always](https://twitter.com/YourTitleSucks), "no". In this case though, I'm genuinely not sure. 

[Update 2014-07-16: I lean toward no for situations with a large amount of text since it makes selecting that text really hard on mobile devices]

Matt Wilcox asked an interesting [question on Twitter](https://twitter.com/MattWilcox/status/467251442307567616) today:

> A11y question: we now often wrap headers and paras and images all in one `<a/>`... Makes sense, but how does that impact screen reader users?

And [the follow up](https://twitter.com/MattWilcox/status/467251958387331072):

> This is a good way to avoid having to link an image, header, and ‘read more’ with three identical URLs, but how are wrapped links read out?

Just in case you didn't know, HTML5 allows you to put just about anything inside an `<a>`, which means you can do things like this:

~~~language-markup
<a href="#">
    <article>
        <h1>My Article Title</h1>
        <img src="" alt="some related image" />
        <time datetime="2014-05-15T19:43:23">05/15/14</time>
        <p>Paragraph text. Couple be multiple 'grafs, could be dozens. Could be just about anything really.</p>
    </article> 
</a>
~~~

This eliminates the need have three separate links around the title, image and perhaps a "read more" link.

But as Wilcox points out, there might be unanticipated consequences that make this not such a good idea in terms of accessibility, and even usability (not sure there's a real distinction there). For example, any text becomes <strike>impossible</strike> very difficult to select, which makes me hesitate to use this technique in this particular case. There may be cases where that isn't a major problem.

I threw together a [test page](https://longhandpixels.net/demos/large-text-a11y/) that I can run through [ChromeVox](http://www.chromevox.com/) and OS X's VoiceOver (the two screen readers I have access to) and see what happens. But I don't use a screen reader on a regular basis so it's hard to know what works and what doesn't, other than obviously very annoying stuff. If you use a screen reader or have a means to test this scenario on other screen readers, I'd love to hear from you.