CSS Wizardry » Accessibility http://csswizardry.com Just another WordPress weblog Wed, 16 May 2012 12:57:59 +0000 http://wordpress.org/?v=2.8.6 en hourly 1 Styling alt text on images http://csswizardry.com/2011/06/styling-alt-text-on-images/ http://csswizardry.com/2011/06/styling-alt-text-on-images/#comments Sat, 18 Jun 2011 17:41:39 +0000 Harry Roberts http://csswizardry.com/?p=2870 I tweeted a tip the other day whereby you add text styles to images so that their alt text is differentiated if images, for whatever reason, cannot be loaded.

The tweet sparked more interest than I expected so I thought I would give the technique a more thorough writeup. The CSS is incredibly simple but it’s just one of those things that can make a lot of difference to someone’s UX.

The thinking is that by applying text-styles to images you can affect their alt text and how that appears if the image fails to load. This can help users realise there’s something different about a piece of content and that it’s perhaps not directly a part of the current text.

A lot of people weren’t aware this would or does work but if you think about it, any alt text you’ve ever seen will have been the same face, colour and style as the rest of the page. alt text (and therefore images) can be styled!

The code

I started doing this a long, long time ago but for some reason completely forgot about it until I started developing inuit.css.

I tend to always apply italics to the text and oftentimes a text colour. Italics is fairly failsafe as figures and asides etc are often set in italics.

Text colours can be more troublesome as it could be misconstrued as being a link, so use this wisely and avoid using the same colour as your links appear in.

Another fairly progressive (but potentially unstable) addition is to use the :after pseudo-element to append the text ‘(image)’ onto the alt text. This only seems to work in Firefox (4).

The code, in full, is simply:

img{
    font-style:italic;
    color:#c00;
}

/*
In Firefox we can insert the word (image) into the alt text of an image that hasn’t loaded.
*/
img:after   { content:" (image)"; }
img::after  { content:" (image)"; } /* New CSS3 standard notation */

So there we have it, a simple, tiny addition to make your users’ experience a little more polished and complete…

]]> http://csswizardry.com/2011/06/styling-alt-text-on-images/feed/ 8 Mark up a semantic, accessible, progressively enhanced, mobile optimised progress bar (bonus: style the numbers in an ordered list!) http://csswizardry.com/2010/11/mark-up-a-semantic-accessible-progressively-enhanced-mobile-optimised-progress-bar-bonus-style-the-numbers-in-an-ordered-list/ http://csswizardry.com/2010/11/mark-up-a-semantic-accessible-progressively-enhanced-mobile-optimised-progress-bar-bonus-style-the-numbers-in-an-ordered-list/#comments Wed, 17 Nov 2010 18:27:32 +0000 Harry Roberts http://csswizardry.com/?p=1711 How about that for an over-the-top title? But it’s true, that’s what we’re going to be doing. It’s been a while since my last post, unfortunately, so I thought I’d make up for it with this sizeable offering in which we will learn a lot of really great techniques in order to make something as simple as a progress bar. By which I mean a breadcrumb-esque meter of steps, such as you might find on a checkout process; we are making this:

Screenshot of the final product.

And in doing so we will cover:

N.B. This article isn’t so much about a progress bar, but more an illustration that best practices and more advanced techniques can be applied to even the most insignificant aspects of a build to create something awesome!

Design and build

Let us assume the brief is this:

We require a numbered progress bar to indicate user location (past, current and future) during a checkout path on the OurService™ website. It must:

  • Be fully accessible.
  • Provide a section title with supporting information.
  • Highlight the user’s current location in the process.
  • Be navigable.
  • Work on mobile devices.

The design, let’s assume, is predefined. It looks as above, purely because it has to. The design is not the major focus of this article, the code and techniques are.

“Code what you consume, not what you see.”

Design

The progress bar shall be a linear, left to right series of linked labels. Current location shall be indicated by a change in colour, progression onto the next step shall be indicated by an arrow.

Build

For the purposes of this tutorial we shall assume the current page is the payment page.

One school of though I find invaluable when it comes to sensible and semantic builds is code what you consume, not what you see. This is a very broad generalisation but works for the most part. Code content independently of (and before you consider) coding any styles. Web development basics, but fundamental to web standards and progressive enhancement.

So, what are we consuming? It’s an ordered list of steps which indicate location in a process.

Okay so first off we know we need an <ol> as this list has fixed and definite order. We also require titles and supporting copy for each item. As the titles and supporting copy require separation from one another we are going to wrap the titles in a <span>; a generic inline container. This leaves us with:

<body id="payment-page">

  <ol id="progress">

    <li class="details-step">
      <a href="#">
        <span>Your details</span>
        Name, email, address.
      </a>
    </li>

    <li class="account-step">
      <a href="#">
        <span>Create account</span>
        Username and custom URL.
      </a>
    </li>

    <li class="products-step">
      <a href="#">
        <span>Product options</span>
        Choose your package.
      </a>
    </li>

    <li class="payment-step">
      <a href="#">
        <strong>
          <span>Payment</span>
          PayPal, or credit card.
        </strong>
      </a>
    </li>

    <li class="go-step">
      <a href="#">
        <span>Go!</span>
        Start using OurService™
      </a>
    </li>

  </ol>

</body>

There are a few things in this code which I’ve not yet mentioned, one is the ID on the <body>, another being the class on each <li> and the last being the <strong> wrapped around the payment page’s text. I shall explain these next.

<body> ID and list item classes

A combination of an ID on the <body> and a class on a list item can allow you to know what the current page is. The CSS #payment-page .payment-step{} will target the payment section of the progress bar when it is on the payment page in the process. Similarly, #go-page .go-step{} will target the go item on the go page. I wrote a much more in-depth article on this over at Venturelab.

The <strong> around the payment step’s text

If you’re determining current page programatically, one could argue inserting a class="current" on the relevant item. This is doable, but avoiding such a class name is far nicer.

As stated earlier we are assuming the current page to be the payment page. Now, we can style the current step on any page using CSS, as outlined above, however how would a user with styles disabled be able to tell what the current page is? How can we highlight this for those users?

Well the solution would be to programatically wrap a <strong> around the text on that page, undo the bolding effects with CSS for browsers with styles enabled, and allow people viewing unstyled content to see that the bolded item is the current page. This gives us:

Unstyled progress bar

As you can see, users with styles disabled can clearly see the current link is the bolded one, this makes the progress bar that little bit more accessible to those who might need it.

So there we have it, the markup that powers the whole thing.

Styling

Now to style this thing up. First off we’ll look at the very basic CSS, and that alone:

/*------------------------------------*\
  MAIN
\*------------------------------------*/
html{
  height:101%;
}
body{
  font-family:Calibri, Arial, Verdana, sans-serif;
  background:#fff;
  color:#88979e;
  width:940px;
  padding:10px;
  margin:0 auto;
}

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  list-style:none; /* Remove the bullets */
  float:left; /* Make its width equal to the combined width of the items inside it */
  margin-bottom:20px;
}
#progress li{
  float:left; /* Stack them all up left */
  font-size:0.75em; /* Make the entire item smaller */
  font-style:italic; /* Make the entire item italic */
}
#progress a{
  display:block;
  text-decoration:none;
  padding:10px 25px 10px 10px; /* Padding to accomodate background image */
  background:#7b8d77;
  color:#fff;
}
#progress span{
  font-size:1.333em; /* Bring the size of the title only back up */
  font-weight:bold;
  display:block;
  font-style:normal; /* Undo the italics */
}
#progress strong{
  font-weight:normal; /* Remove the bolding for CSS enabled browsers */
}
#progress a:hover{
  text-decoration:none;
}
#progress a:hover span{
  text-decoration:underline; /* Underline the title on hover */
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d; /* Arrow image on the current step */
}
#go-page .go-step a{
  background:#a49d4d; /* Arrow image not needed on final step, colour only */
}

All of the above is very obvious, it is essentially just like creating a normal navigational menu, and gives us this:

Basic progress bar

Styling numbers in ordered lists

Next up we style the numbers in the ordered list by using the very very useful and much unknown CSS counter module. Because you have such limited control over the appearance of your bullets in (ordered) lists they can be a pain to style. This pain is alleviated somewhat when using an unordered list as you can simply use a background image. It is an altogether different story when you’re using an ordered list as the bullet needs to change with each list item.

What we do here is use CSS to do a very prog-like job; we get it to loop through each item in a parent container and then increment a user-defined value each time it encounters a specified child. Sounds Greek? Read this.

Once we have this number available to us we use the CSS :before pseudo-element and the content:; property to insert the number before each item. How cool is that?!

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  list-style:none;
  float:left;
  margin-bottom:20px;
  counter-reset:step; /* Set up name of increment on parent */
}
#progress li{
  float:left;
  font-size:0.75em;
  font-style:italic;
}
#progress a{
  display:block;
  text-decoration:none;
  padding:10px 25px 10px 30px; /* Padding changed to 30px to accomodate number */
  background:#7b8d77;
  color:#fff;
  position:relative; /* Relative position to allow absolute positioning later on */
}
#progress span{
  font-size:1.333em;
  font-weight:bold;
  display:block;
  font-style:normal;
}
#progress strong{
  font-weight:normal
}
#progress a:hover{
  text-decoration:none;
}
#progress a:hover span{
  text-decoration:underline;
}
#progress li a:before{
  counter-increment:step; /* Increment the step on each occurance of this (pesudo) element */
  content:counter(step); /* Write out value of the increment */
  text-align:center;
  font-weight:bold;
  position:absolute; /* Position number */
  top:50%;
  left:5px;
  margin-top:-8px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d;
}
#go-page .go-step a{
  background:#a49d4d;
}

This then gives us this:

Non-CSS3 progress bar

Progressively enhancing

Now for the CSS3 progressive bits:

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  background:#7b8d77; /* Give the ol a background to prevent white showing through behind the items' round corners (change value to #f00 to see what I mean) */
}
#progress{
  -moz-border-radius:5px;/* Round all corners of the progress bar */
  -webkit-border-radius:5px;
  border-radius:5px;
}
#progress a{
  text-shadow:1px 1px 1px rgba(0,0,0,0.25); /* A small text-shadow */
  -moz-border-radius:5px 0 0 5px; /* Round the top- and bottom-left corners */
  -webkit-border-radius:5px 0 0 5px;
  border-radius:5px 0 0 5px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d;
}
#progress .go-step a{
  -moz-border-radius:5px; /* Round all corners of the final step */
  -webkit-border-radius:5px;
  border-radius:5px;
}

The full, combined CSS for the progress bar so far is:

/*------------------------------------*\
  MAIN
\*------------------------------------*/
html{
  height:101%;
}
body{
  font-family:Calibri, Arial, Verdana, sans-serif;
  background:#fff;
  color:#88979e;
  width:940px;
  padding:10px;
  margin:0 auto;
}

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  list-style:none;
  background:#7b8d77;
  float:left;
  margin-bottom:20px;
  counter-reset:step;
  -moz-border-radius:5px;
  -webkit-border-radius:5px;
  border-radius:5px;
}
#progress li{
  float:left;
  font-size:0.75em;
  font-style:italic;
}
#progress a{
  display:block;
  text-decoration:none;
  padding:10px 25px 10px 30px;
  background:#7b8d77;
  color:#fff;
  text-shadow:1px 1px 1px rgba(0,0,0,0.25);
  position:relative;
  -moz-border-radius:5px 0 0 5px;
  -webkit-border-radius:5px 0 0 5px;
  border-radius:5px 0 0 5px;
}
#progress span{
  font-size:1.333em;
  font-weight:bold;
  display:block;
  font-style:normal;
}
#progress strong{
  font-weight:normal
}
#progress a:hover{
  text-decoration:none;
}
#progress a:hover span{
  text-decoration:underline;
}

#progress li a:before{
  counter-increment:step;
  content:counter(step);
  text-align:center;
  font-weight:bold;
  position:absolute;
  top:50%;
  left:5px;
  margin-top:-8px;
  padding:2px 6px;
  background:rgba(0,0,0,0.25);

  -moz-border-radius:20px;
  -webkit-border-radius:20px;
  border-radius:20px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d;
}
#go-page .go-step a{
  background:#a49d4d;
}
#progress .go-step a{
  -moz-border-radius:5px;
  -webkit-border-radius:5px;
  border-radius:5px;
}

Which, when coupled with the markup, gives this:

Screenshot of the final product.

Recap

So, let’s cover what we’ve done so far. We’ve:

  • Coded up a semantic progress bar (using an ordered list and correct generic elements).
  • Made it accessible (addition of the strong around the content for non-CSS browsers).
  • Styled it all up.
  • Made use of the body ID trick to mark the current page.
  • Used CSS counters to style the numbers of an ordered list
  • Progressively enhanced it all to make it a little easier on the eyes.

Mobile optimisation

For more information on mobile/iPhone optimised sites please see my associated article.

Next up we need to optimise this thing for mobile. This couldn’t be simpler. The key to optimising sites for mobile is linearise. Linearise everything.

In your markup, add this line to the <head> section, thus:

<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>Progress</title>
  <meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />
  <link rel="stylesheet" type="text/css" href="css/new-style.css" />
</head>

This tells the user agent that the viewport should be the same as the device’s own screen-size, that it should be initially set to a scale of 1 (i.e. no scale), its maximum scale is set to 1, and that users can’t scale themselves.

Now, add the following to the very end of your CSS file:

/*------------------------------------*\
	MOBILE
\*------------------------------------*/
@media (max-width: 480px){ /* In any browser narrower that 480px... */
body{
	width:auto; /* Give the body a fluid width... */
	padding:5px; /* And a slight padding */
}
#progress{
	width:auto; /* Give the list a fluid width */
	background:none; /* Remove the list's background... */
	float:none; /* ...and float */
}
#progress li{
	float:none; /* Remove list item float, causing them to stack */
	margin-bottom:1px; /* Space them slightly */
}
#progress a{
	margin:0 10px; /* Indent the left and right of each item by 10px */
	-moz-border-radius:5px; /* Round all corners */
	-webkit-border-radius:5px;
	border-radius:5px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a,
#go-page .go-step a{
	background:#a49d4d; /* Set the background of the current item */
	margin:0 auto; /* Remove the 10px indent to show that the step is current */
}
}

Now, if you want to test this and don’t have a smartphone, or haven’t got this hosted in a live environment, simply resize your browser window right down until you see the change. I tend to use the Firefox Web Developer Toolbar addon to resize the window to 480×800px.

On the iPhone this now looks like:

iPhone optimised progress bar

Demo

For the full working demo head to http://csswizardry.com/demos/progress-bar/. For the complete CSS (with reset) please see http://csswizardry.com/demos/progress-bar/css/style.css. Also, try using Firebug to change the <body>’s ID to go-page.

Final words

As I stated previously, this article isn’t so much about the progress bar itself. What I hope this article has shown is how something as small and trivial as a progress bar has a wealth of little nooks and crannies in which to immerse yourself. Semantics, accessibility, using <body> IDs to style current states without a class="current", how to use CSS counters to style the numbers in an ordered list, how to progressively enhance lean markup, and how to optimise things for mobile in a flash.

All of the above skills are easily and quickly transferable. It might be a progress bar today, but what could it be tomorrow? Skills like the ones covered here give you the potential to make something great, out of something very very simple.

]]> http://csswizardry.com/2010/11/mark-up-a-semantic-accessible-progressively-enhanced-mobile-optimised-progress-bar-bonus-style-the-numbers-in-an-ordered-list/feed/ 11 Are CSS3 gradients Fool’s Gold? http://csswizardry.com/2010/10/are-css3-gradients-fools-gold/ http://csswizardry.com/2010/10/are-css3-gradients-fools-gold/#comments Mon, 25 Oct 2010 15:19:31 +0000 Harry Roberts http://csswizardry.com/?p=1700 During a discussion debate argument with a developer today I, in a roundabout way, arrived at the question ‘are CSS3 gradients Fool’s Gold?’ The argument itself is somewhat irrelevant and far too long winded to go into here, but the long and short of it was that he was trying to force some crazy CSS3 syntax into doing something that only a background image should be used for.

After I had pointed this out to him, one of his arguments was (and I paraphrase) ‘if a user disables images I still want them to be able to see it’.

This astounded me a little, my response was (again, paraphrased) ‘If a user wants to disable images then why spoof it? If they want to disable images they don’t want to be left with something-that-looks-just-like-an-image-but-technically-isn’t, they want that gone because they opted to disable images!’

If a user has trouble reading something because of the rainbowey background on it and they choose to disable images to aid contrast, only to find that the rainbow persists, does this not present an accessibility issue?

This then led me onto the thought that, actually, this is the same with all CSS3 gradients. I have been using CSS gradients for some time now, and they’re live as we speak on several different sites. But are they such a good idea…?

Now, I am just thinking out loud here, but are they a Fool’s Gold? Do they present accessibility issues? Or am I over-dramatising and over-thinking things?

Any thoughts or information about this would be great to help get the discussion opened up…

Addendum

Please read this bit, I do know how and why they are a good thing, but I’m not here to talk about that…

To make clear, I fully understand all the benefits of using CSS gradients, they’re a fantastic addition to CSS and I can wholeheartedly see why and where they are good (scalability, ease of change etc) however this post focusses entirely on possible drawbacks. I know all about their benefits, I just haven’t mentioned them here.

Furthermore, the rainbow gradient was a tongue-in-cheek example. It isn’t however all that far from the truth…

]]> http://csswizardry.com/2010/10/are-css3-gradients-fools-gold/feed/ 26 In response to ‘Invisible captcha to prevent form spam’ http://csswizardry.com/2010/10/in-response-to-invisible-captcha-to-prevent-form-spam/ http://csswizardry.com/2010/10/in-response-to-invisible-captcha-to-prevent-form-spam/#comments Mon, 04 Oct 2010 16:57:39 +0000 Harry Roberts http://csswizardry.com/?p=1429 I seem to be doing a lot of these types of posts lately—responses to other articles. Today’s is about an article pointed out to me by a friend and ex-colleague. The article deals with an interesting new way to combat form spam by hiding a form field from human sight, and working on the premise that a spam-bot (devoid of ‘human sight’) will continue to fill this field in, thus identifying it as being spam.

The more astute among you will have already spotted the flaw. Is it just spam-bots that can’t see? Nope, exactly.

Screen-reader users can’t see this form field in much the same way a spam-bot can’t. Their screen-reader will read out the field’s label and prompt them to fill it in.

The issue here is that humans aren’t meant to know about this field, and anyone filling it in will flag their submission up (incorrectly) as being spam.

A way round this might be to label the field as ‘Hey humans, do not put your email address in here!’ and hope that they’ll not be too confused by it, but that’s unlikely because it’s nothing but confusing. We also have to assume here that not all screen-readers will ignore content with display:none; applied to it.

An interesting idea, but pretty inaccessible to a small minority of users. And users are more important than a lack-of-spam.

]]> http://csswizardry.com/2010/10/in-response-to-invisible-captcha-to-prevent-form-spam/feed/ 7 Moving forward is holding us back http://csswizardry.com/2010/03/moving-forward-is-holding-us-back/ http://csswizardry.com/2010/03/moving-forward-is-holding-us-back/#comments Tue, 02 Mar 2010 22:03:28 +0000 Harry Roberts http://csswizardry.com/?p=840 For years, web developers have been looking forward to that next feature, that new and monumental shift which has allowed them to break away from the shackles of obsolescence and adopt new and forward thinking technologies. But it is beginning to come full circle—that thirst for new technology has slowly brought us back to square one, reimposing the constraints that we have, for years, tried to rid ourselves of. Moving forward is holding us back.

Okay, okay. That was a very alarmist intro. There is no web developers’ apocalypse around the corner (not that I know of anyway, please don’t take anything I say about the apocalypse as read. I don’t want that responsibility.), nor are we going to have to regress to using tables and spacer GIFs again. The real issue here is that with all this new technology that keeps emerging and exciting web developers is unwittingly reimposing the restrictions of yesteryear…

Screen resolutions

Remember trying to break away from 800×600px?

With the movement toward a more mobile web, screen resolutions are in fact getting smaller. The iPhone’s maximum resolution is 480px, increasingly popular netbooks are set at about 1024px wide. Such a shift toward mobile and portable devices mean that screen sizes are actually getting smaller.

In my opinion, iPhones and other mobile devices should be handled separately, serving them device specific CSS. Netbooks on the other hand are still ‘desktop’ machines like any other. Their smallness is their key feature, and at 1024px horizontal resolution, they aren’t that small anyway…

With the 960 Grid System, and an optimum line length of 52–78 characters, sticking to 1024px shouldn’t be that difficult anyway. I believe that although desktop monitor sizes are generally getting larger, other equally important technologies are creeping up, and as responsible developers you should cater for them. Sure you may want to start adopting the 1080 grid, which is all well and good if you know your audience, but to cater for the majority, we’re not ready to burst 1024 yet.

Connection speeds

Remember building for 56k dial up connections? (I don’t)

Where permanent and fixed connections are getting much faster, connections to mobile devices through means such as 3G are much slower. The ability to optimise sites to be fast loading over such connections is getting more important. As edge-case resolutions are getting smaller, edge-case connections are getting slower. Much slower.

A word on Flash

Remember 2Advanced? A site of yesteryear…

Flash seems to be dying a death anyway these days, slowly being superseded by Javascript and Canvas et al. However, what was once a fantastically powerful technology has been ousted completely from Apple’s i products, making in an inviable option for content which needs to be universally accessible.

A real life example?

Anyone with an iPhone will know what I mean—spending any amount of time on an iPhone loading poorly optimised sites is a real grind, and via some sensible optimisation these problems can be easily alleviated.

However, a more interesting example might be the one that happened to myself… When we first started at Venturelab we really were building the company from the ground up. For the first few weeks we were without desktop machines and internet. I was working on a 10.1″ netbook with a screen resolution of 1024×600px, and over a poor 3G connection via a dongle.

“Accessibility isn’t just about disabilities, it’s about varying degrees of ability to access content.”

Working in this manner really made me wonder whether enough people are delivering content in a manner which is accessible on numerous levels. Accessibility isn’t just about disabilities, it’s about varying degrees of ability to access content. As responsible developers your content should be accessible through a full spectrum of means and in an acceptable manner.

All it takes is some decent optimisation (which is also set to reap SEO benefits) and a reasonable page layout and you’re already halfway there.

]]> http://csswizardry.com/2010/03/moving-forward-is-holding-us-back/feed/ 11 A suitable alternative—on proper use of alt attributes http://csswizardry.com/2010/01/a-suitable-alternativeon-proper-use-of-alt-attributes/ http://csswizardry.com/2010/01/a-suitable-alternativeon-proper-use-of-alt-attributes/#comments Tue, 26 Jan 2010 16:03:03 +0000 Harry Roberts http://csswizardry.com/?p=318 Images in HTML come with a mandatory attribute used to textually describe the information displayed visually through the image. The alt attribute (not tag) is used by screenreaders etc to tell users who can’t view the actual image what it represents. It is also used in any circumstance where images can’t be loaded (slow connections, broken URIs etc).

When not to use it

You should never not use an alt attribute, rather leave it empty, thus: alt=""

The only time you can really get away with not having a complete alt attribute is if the image holds no context or information that the user needs to be aware of. This is usually the case when the image is purely decorational, though it may be argued that the image should therefore be added through CSS in the spirit of separating style and content. By that token it is fairly safe to say that there should never be an instance in which you leave an alt attribute empty.

You’re using it, but not quite right…

The next best scenario is that you are using images correctly, for their correct purpose and are using alt attributes, but they don’t really do as much as they should. A lot of the time I come across images that have less than ideal alt attributes.

A photograph of an abandoned car

Image sourced via Google Images—original author unknown.

One example might be the above image of a car. This, while technically correct, is not ideal: <img src="/img/car.jpg" alt="Car" />. All this tells the user is ‘Car’. It doesn’t say whether it’s a picture with the word car in it, or whether it’s a picture of a car. A much better alt attribute would be alt="A photograph of an abandoned car" (as used in my code).

Other poor uses

Another real-world example of poor alt attribute usage is actually on CNN’s website. On their home page today (26 January, 2010) they have a series of headlines with accompanying images. The code for such a pairing looks like this:

<img height="68" border="0" width="120" alt="Haiti's swanky club →
now home to misery" src="http://i.cdn.turner.com/cnn/2010/WORLD/ →
americas/01/26/haiti.camp/tzvids.haiti.aid.cnn.jpg"> →
… Haiti's swanky club now home to misery

This is wrong on two counts:

  1. A screenreader will read out to the user Haiti’s swanky club now home to misery … Haiti’s swanky club now home to misery. Every image/headline pairing on the page is laid out like this, meaning in every instance a user using a screenreader will hear the headline twice. This will surely soon get annoying.
  2. Secondly, the image was actually of earthquake survivors holding a large bag, nothing to do with clubs and, unfortunately, far from swanky.

Using the attribute properly

On the BBC’s home page however (on the same date) they are using alt attributes perfectly. They have an image of a woman wearing a veil, alongside the article’s headline France report back face veil ban. The image’s alt attribute: alt="A woman wears a full-length veil in Lyon, 25 January".

The biggest no-no of all

One thing which consistently winds me up is the ridiculously bad practice of stuffing alt attributes with keywords. alt attributes are an accessibility feature, end of. They are not a way of slipping in keywords out of sight, and any attempt to do so is irresponsible and incredibly bad practice. The only time ‘keywords’ may be validly placed in alt attributes is if it’s explicitly related to the image; for example: <img src="/img/product.jpg" alt="A photograph of Mike's Carpets' ProClean™ carpet cleaner" />.

How to do it properly

Writing proper alt text is incredibly simple, yet a little more time consuming than the ‘Car’ cop-out. All you need to do is write out in full exactly what the image shows. If it’s an elephant giving a donkey a piggy-back don’t be lazy and use alt="Elephant and a donkey". Instead, write out alt="A photograph of an African elephant giving a donkey a piggy back across a swamp".

Also, for any pages that use similar images repeatedly but are slightly different to one another, make sure your alt attributes reflect these differences. A good example would be my portfolio page. Instead of using alt="Screenshot" over and over again I used text like alt="Screenshot of Suzanna Haworth’s website" and alt="Screenshot of RAAMaudio UK Ltd." etc.

This is one of the most basic aspects of web development, but one that too many people are still getting wrong.

]]> http://csswizardry.com/2010/01/a-suitable-alternativeon-proper-use-of-alt-attributes/feed/ 3