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.

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 :)

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.

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

Clear and simple, great article!

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

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.

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.

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

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.

@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.

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?

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.

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.

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! =)

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.

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

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!

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

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.