Jump to content

Year

Day

24 ways to impress your friends

It’s the holiday season, so you know what that means: online shopping! When I started developing Web sites back in the 90s, many of my first clients were small local shops wanting to sell their goods online, so I developed many a checkout system. And because of slow dial-up speeds back then, informing the user about where they were in the checkout process was pretty important.

Even though we’re (mostly) beyond the dial-up days, informing users about where they are in a flow is still important. In usability tests at the companies I’ve worked at, I’ve seen time and time again how not adequately informing the user about their state can cause real frustration. This is especially true for two sets of users: mobile users and users of assistive devices, in particular, screen readers.

The progress meter is a very common design solution used to indicate to the user’s state within a flow. On the design side, much effort may go in to crafting a solution that is as visually informative as possible. On the development side, however, solutions range widely. I’ve checked out the checkouts at a number of sites and here’s what I’ve found when it comes to progress meters: they’re sometimes inaccessible and often confusing or unhelpful — all because of the way in which they’re coded. For those who use assistive devices or text-only browsers, there must be a better way to code the progress meter — and there is.

(Note: All code samples are from live sites but have been tweaked to hide the culprits’ identities.)

How not to make progress

A number of sites assemble their progress meters using non- or semi-semantic markup and images with no alternate text. On text-only browsers (like my mobile phone) and to screen readers, this looks and reads like chunks of content with no context given.

<div id="progress">
	<img src="icon_progress_1a.gif" alt="">
	<em>Shipping information</em>
	<img src="icon_progress_arrow.gif" alt="">
	<img src="icon_progress_2a.gif" alt="">
	<em>Payment information</em>
	<img src="icon_progress_arrow.gif" alt="" class="progarrow">
	<img src="icon_progress_3b.gif" alt="">
	<strong>Place your order</strong>
</div>

In the above example, the third state, “Place your order”, is the current state. But a screen reader may not know that, and my cell phone only displays "Shipping informationPayment informationPlace your order". Not good.

Is this progress?

Other sites present the entire progress meter as a graphic, like the following:

A sample progress meter for a three-step checkout flow, with the second step in active state

Now, I have no problem with using a graphic to render a very stylish progress meter (my sample above is probably not the most stylish example, of course, but you understand my point). What becomes important in this case is the use of appropriate alternate text to describe the image. Disappointingly, sites today have a wide range of solutions, including using no alternate text. Check out these code samples which call progress meter images.

<img src="checkout_step2.gif" alt="">

I think we can all agree that the above is bad, unless you really don’t care whether or not users know where they are in a flow.

<img src="checkout_step2.gif" alt="Shipping information - Payment information - Place your order">

The alt text in the example above just copies all of the text found in the graphic, but it doesn’t represent the status at all. So for every page in the checkout, the user sees or hears the same text. Sure, by the second or third page in the flow, the user has figured out what’s going on, but she or he had to think about it. I don’t think that’s good.

<img src="checkout_step2.gif" alt="Checkout: Payment information">

The above probably has the best alternate text out of these examples, because the user at least understands that they’re in the Checkout process, on the Place your order page. But going through the flow with alt text like this, the user doesn’t know how many steps are in the flow.

Semantic progress

Of course, there are some sites that use an ordered list when marking up the progress meter. Hooray! Unfortunately, no text-only browser or screen reader would be able to describe the user’s current state given this markup.

<ol class="progressmeter">
	<li class="one current">shipping information</li>
	<li class="two">payment information</li>
	<li class="three">place your order</li>
</ol>

Without CSS enabled, the above is rendered as follows:

A sample progress meter for a three-step checkout flow, with no clear active state indicated

Progress at last

We all know that semantic markup makes for the best foundation, so we’ll start with the markup found above. In order to make the state information accessible, let’s add some additional text in paragraph and span elements.

<div class="progressmeter">
	<p>There are three steps in this checkout process.</p>
	<ol>
		<li class="one"><span>Enter your</span> shipping information</li>
		<li class="two"><span>Enter your</span> payment information</li>
		<li class="three"><span>Review details and</span> place your order</li>
	</ol>
</div>

Add on some simple CSS to hide the paragraph and spans, and arrange the list items on a single line with a background image to represent the large number, and this is what you’ll get:

There are three steps in this checkout process.

  1. Enter your shipping information
  2. Enter your payment information
  3. Review details and place your order

To display and describe a state as active, add the class “current” to one of the list items. Then change the hidden content such that it better describes the state to the user.

<div class="progressmeter">
	<p>There are three steps in this checkout process.</p>
	<ol>
		<li class="one current"><span>You are currently entering your</span> shipping information</li>
		<li class="two"><span>In the next step, you will enter your</span> payment information</li>
		<li class="three"><span>In the last step, you will review the details and</span> place your order</li>
	</ol>
</div>

The end result is an attractive progress meter that gives much greater semantic and contextual information.

There are three steps in this checkout process.

  1. You are currently entering your shipping information
  2. In the next step, you will enter your payment information
  3. In the last step, you will review the details and place your order

For example, the above example renders in a text-only browser as follows:

There are three steps in this checkout process.

  1. You are currently entering your shipping information
  2. In the next step, you will enter your payment information
  3. In the last step, you will review the details and place your order

And the screen reader I use for testing announces the following:

There are three steps in this checkout process. List of three items. You are currently entering your shipping information. In the next step, you will enter your payment information. In the last step, you will review the details and place your order. List end.

Here’s a sample code page that summarises this approach.

Happy frustration-free online shopping with this improved progress meter!

Like what you read?

Comments

Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.

Got something to add? You can leave a comment below.

  • prisca http://eyedea.eu

    Great article – thanks.
    I agree how important good progress indication is for a good online shopping experience – great breakdown of important details and excellent tips; I’ll be coming back to this ;)
    Thank you :)

    Vote Helpful or Unhelpful

  • Conor MacNeill http://www.eatclub.org.uk

    This is one of my favourite articles this year. I would usually go the route of the ordered list, but adding the extra spans with descriptive information is beezer. I assume kids these days still say beezer.

    Personally, instead of classes one, two and three, I’d use ‘shipping’, ‘payment’ and ‘review’, but that’s just me.

    Good article; I hope people heed it.

    Vote Helpful or Unhelpful

  • Johns Beharry http://johnsbeharry.com

    I’m learning so many cool new tricks here, thanks alot for the tip i’m sure if i had to do this i’d do it with a ul just little things that you gotta keep your head up for

    Thanks

    Vote Helpful or Unhelpful

  • Vladimir Carrer http://www.vcarrer.com

    Clear and simple, great article!

    Vote Helpful or Unhelpful

  • jaronBarends http://www.jaron.nl

    Very interesting. I would just like to suggest one more thing: adding a link to the already finished states, to make it easier for people to go back to previous steps.

    Vote Helpful or Unhelpful

  • Mads

    Great solution to another accessibility issue. An area we need to pay a lot more attention to.

    Vote Helpful or Unhelpful

  • simon r jones http://www.studio24.net

    nice idea on an often overlooked element.

    I’m reading Universal Design for Web Apps at present (excellent book) and that too recommends using text in span tags to give extra meaning instead of using title attributes which are often not used in speech readers.

    Vote Helpful or Unhelpful

  • Pete B

    Nice article

    It looks and feels a little strange writing text in just for the screen reader, but it’s something I’ve been doing too. Makes me feel a little less weird knowing I’m not the only one :)

    You have to hide the text as you’ve done as well (no display:none) or else the trick won’t work.

    Vote Helpful or Unhelpful

  • Harry Roberts http://csswizardry.com/

    I’ve been building progress indicators with <ol>s for a while now, but an even better idea is to throw a <strong> tag around the current <li>, that way the current step is also bolded with styles turned off:

    http://csswizardry.com/web-design+/#location-nav5-3-1

    Vote Helpful or Unhelpful

  • Drew McLellan http://allinthehead.com/

    I’ve been building progress indicators with <ol>s for a while now, but an even better idea is to throw a <strong> tag around the current <li>, that way the current step is also bolded with styles turned off:

    That presumes that the browser has a default stylesheet, that that stylesheet styles strong emphasis as bold and that the user is able to see the bold text.

    I’m not saying using <strong> is a bad idea (it’s not), but I don’t quite agree with the reasoning.

    Vote Helpful or Unhelpful

  • Derek Reynolds http://whatupderek.com

    @drew @harry You should wrap the content inside the <li> element in a <strong> element. It’s not valid to wrap the <li> in a <strong> tag.

    Great article! I am going to go back and implement some of these ideas to some old progress meters.

    Vote Helpful or Unhelpful

  • Pierre Bertet http://www.lesintegristes.net

    I’m not agree, Drew : that presumes nothing.

    <strong> means “strong emphasis”, unlike <b>, wich means “bold text style” : http://www.w3.org/TR/html401/index/elements.html

    I usually use the <strong> tag to indicate the current step, because any assistive technology should correctly restitute the strong emphasis.

    Vote Helpful or Unhelpful

  • Drew McLellan http://allinthehead.com/

    @drew @harry You should wrap the content inside the <li> element in a <strong> element. It’s not valid to wrap the <li> in a <strong> tag.

    I don’t think Harry meant literally wrap a <strong> element around the <li> element, but rather around its contents. You’re right though – we should be careful with speaking in shorthand where it could mislead.

    I’m not agree, Drew : that presumes nothing.

    Harry was stating that <strong> displays in bold without styles enabled. That was the point I was picking up on, because it’s not necessarily true. In all other ways we are in agreement r.e. strong emphasis.

    Vote Helpful or Unhelpful

  • Harry Roberts http://csswizardry.com/

    Yes, to clarify I meant <li><strong></strong></li>.

    Drew is 100% right that the method does very little visually if the user agent doesn’t display <strong> as bolded text BUT it is in no way detrimental, and the semantics are there. It’s just an extra thing that helps more often than it will hinder. Progressive enhancement?

    Vote Helpful or Unhelpful

  • Felipe http://forum.alsacreations.com

    Nice example, though there seems to remain problems for visually impaired people, mainly those having problems with colors.

    Only color is used to inform about the current step and ideally (from WCAG 1.0 priority 1) don’t rely on color alone : one could add an underline or a background icon (arrow, etc) near the current step to provide another way of providing this information.

    Vote Helpful or Unhelpful

  • Ray Drainville http://blog.ardes.com/

    This was a really useful article—thanks for it, I found the screen reader rendition especially insightful.

    @felipe: I totally agree that relying on colour alone is suboptimal in terms of accessibility, but the example here was just that—an example. It’s a good idea & certainly one that can be quickly (and confidently) built upon for accessibility.

    Vote Helpful or Unhelpful

  • Jason Robb http://jasonrobb.com

    Great article, especially because this progress meter is something I’m fighting on my current project.

    Thanks for mentioning how to copywrite steps 2 and 3 in your code sample. I was about to ask what you’d do.

    Very, very helpful. Thank you Kimberly! =)

    Vote Helpful or Unhelpful

  • Mike Brittain http://mikebrittain.com/

    Can you tell us which screen reader you are using for testing? I’m also curious whether the current state of screen readers is to ignore style sheets entirely, or whether some will attempt to make use of style sheets in particular cases.

    Vote Helpful or Unhelpful

  • Mike Stempie? http://www.veboolabs.com

    Pierre, I’m with you on that. Current step (content) should be wrapped in a strong tag.

    Vote Helpful or Unhelpful

  • Tobias http://www.urff.at

    Love the fact you’re considering screen readers here. Even well thought out websites that degrade gracefully in various legacy browsers without support for CSS and Javascript tend to be a little odd and confusing when listening to them in a reader.

    Designers should consider that whilst screen readers today offer good support for “helper” phrases such as “list of three items” this can become very, very annoying for the visually impaired audience when heavily used. I believe that in the future these visitors will demand that websites address their needs (fluent, semantic texts) rather than them having to adapt to a visual site (“helper” sentences of the reader that distract a lot from the content, i.e. “I Own A Highlighted In Bold Red End Of Highlighting Cat.”).

    Thanks, Kimberly, for the interesting article!

    Vote Helpful or Unhelpful

  • Visitor

    One of the best Meupload file searchers and download centres is here http://megauploadfiles.com/
    Find al the necessary information there!

    Vote Helpful or Unhelpful

Impress us

Be friendly / use Textile

About the author

Kimberly Blessing

Kimberly Blessing has been developing Web sites since 1994 and has been a professional standards evangelist since 2000. She has worked for large companies like AOL and PayPal, leading their transitions to Web standards. She has also consulted for institutions large and small, helping them migrate to Web standards. She is a member and former Group Lead of the Web Standards Project and is active in other local, grass-roots Web standards efforts. (Geez, can we say “Web standards” any more in this bio?) An instructor in and a graduate of Bryn Mawr College‘s Computer Science program, Kimberly is also passionate about increasing the number of women in technology.

More information

Brought to you by:

Perch - a really little cms

The easiest way to publish fast, flexible HTML5 websites your clients will love.