Get your images out of the way
Graphics are a major stumbling block and point of contention when it comes to accessibility. Non-sighted users can’t see them, to state the obvious. They also lengthen loading times considerably and often get in the way of the flow of other content. This simple trick tackles all these issues at once. By ‘tackles’ I do not mean ’solves’, it is still up to the designer’s skill to apply graphics sensibly.
The issues with graphics broken down:
- Non-sighted people can’t see them; many visually impaired people can’t see them well enough. Especially text in images is a major issue.
- Images are considerably larger in terms of kilobytes than plain text; this means they lengthen loading times considerably. For users with slow connections such as people living in rural areas where satellite or dialup connections are the only options, people with a limited budget or using mobile devices this is a major stumbling block.
- Images can easily get in the way of the way the eye moves over text. Reading from a screen is a lot more tiring than from paper as it is, each time you make the user’s eye ‘jump’ left or right to catch up with the text you are adding to this burden.
All three of these issues are dealt with in this simple tutorial. What I provide is a pragmatic approach, not a standards-zealot one. It is up to you to ensure cross-browser compatibility and, if at all possible, W3C compliance.
What we are going to do can also be done using JavaScript, and there is no really compelling reason to not use JavaScript other than the fact that many users have JavaScript turned off. This trick therefore is just slightly more ‘bullet proof’.
Accessibility made simple
“Accessibility at times seems to be a serious ball-and-chain proposition for designers and developers alike. The very nature of the WCAG guidelines is one of restrictions and imperatives. Although I sometimes disagree with them, I do hold the WCAG guidelines to be authoritative. But reading through them they do read as if you should give up two-thirds of your toolbox. In this series of articles I intend to provide simple and pragmatic approaches to using most of your toolbox without sacrificing unreasonable levels of accessibility. Accessibility is not the goal of design; it is a tool to do better design. Some of my tricks do bend or even break the rules, as far as I am concerned this is quite OK, if you provide a reasonable alternative for those with limited access. Where appropriate I will also provide tips on how to do that.
The case
Most websites provide decorative images to liven up text, add some atmosphere or simple decoration. Usually these will reside in a background layer and therefore the reference to them will not sit in the actual document. This is fine. This way they do not get in the way of user who can’t see them, or do not want to see them.
Then there are images with actual informational content, such as text, a map or a graph. These should be in the document’s flow since otherwise there would be a gap in the information. You provide an alt-text descriptor as an alternative and screen readers, for example, will more or less neatly present this information to the visitor.
Then there’s the third option: Images that do enhance the informational content of the document, but cannot usefully be included for non-sighted users. For example: A travel site may add some snapshots of a tourist attraction or landmark. Non-sighted users, who can’t see these in real life, have no need for the image in the document. For sighted users however they can be immensely useful.
What to do with these? A screen reader such as JAWS, which I recently tried for myself, will pause upon the graphic, then say in its unpleasant robotic voice “Graphic…” and read the alt-descriptor. Now, imagine you are non-sighted and someone holds up a picture in front of you and tells you “Hey, I’m holding up a picture of this neat building, great eh?” This in effect is what the alt-descriptor means for the non-sighted user in such cases.
The simple solution would be to also take these images out of the flow and be done with it. A useful way to do this looks like this in plain HTML/CSS:
<div class="bodycopy">
<div class="img">
</div>
<p> […Lorem ipsum…] </p>
</div>
And the css:
.img {
position: relative;
float: left;
width: 400px;
height: 267px;
background: url(poort.jpg);
}
As you can see I have placed an empty DIV inside my content-DIV and put the image in its background. Screen readers will now neatly skip over the image and not even announce its presence to the user, eliminating what otherwise would only be an annoying distraction.
Since a DIV is a block level element, just as an image, it will otherwise behave exactly the same as an image and can be styled in much the same way.
An image placed as background to a DIV
Getting it even further out of the way
For many average designs, this is where it ends, but I’m not the type to settle for average and neither are you, I’m sure. The image is rather large and sits uncomfortably in the text, pushing just that one line below it and hindering the reader who likes to read from right-to-left. Besides, screen real estate is a valuable commodity; we are using rather a lot of it for just this one image. Note that I am not bothering with things like margins for now, to keep the code snippets short.
So I made a thumbnail image to replace it. A thumbnail is a great way to let the user know that there is more to be seen without sacrificing too much screen space.
To place a thumbnail this way and get it to link we need the anchor, <a>, element. We could decide to place the thumbnail in the flow. But then we’d undo what we did before and have this graphic element in our document’s flow again. Fortunately CSS allows us to take pretty much any element and style it the same way as a DIV. The A is no exception, only since it is natively in-line, we need to set it to display as block.
<div class="bodycopy">
<a href="poort.jpg" title="Thumbnail: Goes to larger image." class="img">
</a>
<p> […Lorem ipsum…] </p>
</div>
And the css:
.img {
position: relative;
display: block;
float: left;
width: 102px;
height: 78px;
background: url(poort-thumb.jpg);
}
Note that we have undone some of the advantage of the above technique. As far as not announcing the presence of the image to screen readers goes. The screen reader will now announce the presence of a link. If this is where you stop and sit back, be sure to add an appropriate title for the screen reader to read. The non-sighted user may not have use for a link to an image, but you should always tell him/her where the link goes at the very least to prevent the user from following the link and getting lost.
A thumbnail takes up far less space
But we can do even better, and take advantage of a few lesser-known options in HTML and the way in which screen readers behave.
Making it a hover rollover instead
What if we eliminate yet one more click and simply bring up the larger graphic when a user scrolls over the thumbnail? As long as your thumbnail is clearly recognizable as such, this would be natural behaviour for your user, if he or she were interested in the larger graphic.
Rollover effects are a can of worms as far as usability goes, but that is mostly because people don’t use them sensibly. Take care to not place rollovers in the natural path of the mouse, so people don’t get annoyed at a rollover effect they didn’t want. Make sure a rollover doesn’t block the path to another button or link altogether, and try to avoid covering up very important areas of your site. Also avoid introducing flicker to your site, more on that further on in this article.
Stick to these pointers and you should be fine.
Note on browsers and support for hover
Most major browsers honour the hover state on all elements, with the notable exception of Internet Explorer 6 which only accepts hover trickery on the anchor element and Internet Explorer 7 which only displays hover effects on non-anchor elements when not in quirks mode. Whether or not you want to spend time on fixing issues for Internet Explorer 6 users is up to you. Whether or not your site will always run in standards compliance mode is up to you to think about. You’d have to be really sure though, because one typo could dump your entire site into quirks-mode.
So, pragmatism and caution leaves us with only the Anchor element to play hover tricks with. Fortunately, the anchor is a much nicer element to work with than most people realize.
Remove the href
Many people do not realise that the anchor element actually needs no href attribute. According to the W3C: “Authors may also create an A element that specifies no anchors, i.e., that doesn’t specify href, name, or id.” Also, when a screen reader has no text to read whatsoever associated with an element, it should ignore it. Testing with JAWS seemed to indicate that for JAWS at least, this is the case. There are many screen readers out there, though. So there are no guarantees. In my opinion some improvement is better than none, but do note that from here on out we are entering largely uncharted waters and your mileage may vary. I have tested this trick with JAWS and in the major current browsers.
By removing the href the anchor is effectively no longer a link. This is nice because users will click just about anywhere. It becomes a ‘dummy’ element with no other function but as a container for your styling.
So, on with the show: we remove the href attribute and instead use hover to provide the larger image when the user moves the mouse pointer over the thumbnail.
Note that removing the href attribute breaks this trick in Internet Explorer 6. Not removing the href solves this, but introduces a host of other problems. If you do decide to cater to IE 6 users, I recommend using conditional comments and providing them with a solution as described above: a link to a larger graphic.
The code:
<div class="bodycopy">
<a class="img">
</a>
<p>
[…Lorem ipsum…] </p>
</div>
And the css:
.img {
position: relative;
display: block;
float: left;
width: 102px;
height: 78px;
background: url(poort-thumb.jpg);
}
.img:hover {
position: relative;
display: block;
float: left;
width: 400px;
height: 267px;
background: url(poort.jpg);
}
As you can see, we’ve added the hover state and simply changed back the dimensions and the background of the element to those of the larger image. We removed the href, thus retaining the ‘hoverability’ of the element but no longer actually providing a link.
Unfortunately many browsers still do not honour hover states on other elements, so we are stuck with the anchor as container.
The hovered image pushes te text aside
To clean up the design even further you could consider getting the image to sit on top of the text instead of, as it does now, pushing the surrounding text aside. One way to do this is like so:
<div class="bodycopy">
<div class="spacer"> </div>
<a class="img">
</a>
<p>
[…Lorem ipsum…]
</p>
</div>
and the css:
.img {
position: absolute;
display: block;
left: 0;
top: 0;
width: 102px;
height: 78px;
background: url(poort-thumb.jpg);
}
.img:hover {
position: absolute;
display: block;
left: 0;
top: 0;
width: 400px;
height: 267px;
background: url(poort.jpg);
}
.spacer {
float: left;
width: 102px;
height: 78px;
}
Now the image will 'float' over the text
We’ve just set the positioning to absolute and added the spacer div to clear the text from the thumbnail again since it will, quite correctly, not flow around an absolutely positioned element. There are lots of downsides to this, such as no real way to fix a floating element in place, so you are severely limiting your options for placing your thumbnail, but solving those falls outside the scope of this tutorial in the sense that it’s neither simple nor really the core of the issue. Which approach you choose depends on many other conditions relating to your design and layout, so I’ll leave it to you to figure those out.
One last hurdle to tackle
The one thing we haven’t tackled yet is loading times, and with this trick this issue is more pertinent than ever because a slow loading hover image will produce flicker. (Flicker looks bad, but can also in rare cases induce seizures with people who have certain types of epilepsy.) There is one fairly reliable trick I know, but pay heed that different browsers may do things differently so do not rely blindly on it.
Preload your images
In short, that’s the trick. Make your browser fetch the images before you need them. This is in no way a sure-fire technique but it usually works. Place references to your images below your content and then use CSS to hide them.
Like so:
<div class="preload">
<img src="poort.jpg" alt="" />
</div>
The css:
.preload {
position:absolute;
left:-9999px;
}
Despite the fact that many accessibility tutorials still advocate using display: hidden, do not use this. This effectively removes the elements from the flow, and they will therefore often not be preloaded at all. The way shown above will ‘display’ the images, only off-screen.
Place the images at the bottom so the page loads first and then starts to preload the images, otherwise your users will have to wait for invisible images to load.
Your images are now back in the document’s flow. But they are out of the way, at the bottom. To be really nice to the non-sighted we are now going to inform them that there is no need to skip past all these images one by one.
Place an anchor above your list of images with a text such as “no content below this point, back to top” and use the same css as for the preload above to hide it from other users.
But you knew that right?
In closing
This trick has many pitfalls and downsides. It is certainly not the way a purist would do things. I found it useful at times though, even if you are not going to use this technique, for whatever reason, I hope it has enlightened you about some aspects of accessibility for websites. We have achieved the following:
- Removed an annoying distraction from the flow of your site for non-sighted users.
- Lessened the impact of a large graphic on the readability of your content.
Other points to consider:
- If you are providing a graphic for your users, it must have some value. Think hard about providing the same value to non-sighted users, for example by complimenting a map with a step-by-step street-guide.
- This technique almost by accident also has the advantage of hiding an unwanted element to screen readers. If you think you need to do this more often, consider doing it correctly: by adding a print/aural style sheet. These are often still not honoured but they might in the future and you’ll be ready.
Happy web-building!
1 Comment
Pingback by Portfolio David Dylan Jessurun — October 19, 2009 @ 1:46 am
[...] http://www.defcon0.com/get-your-images-out-of-the-way/ [...]