Ordered and unordered lists have been popping up more often within the blogosphere lately. Through the use of style sheets, we can now tame our lists, rendering them in ways that traverse well beyond the traditional bulleted form so overused by PowerPoint addicts. I’ve been debating with myself whether this is a good or bad thing.
HTML lists have been around for years. And they’ve certainly been used frequently to create standard sets of links. But as we move toward a more semantic web, we’re becoming aware that certain grouped interface elements and conventions could actually be considered lists as well, even though we may not always envision a number or bullet in front of each list item.
Using a styled unordered list has become increasingly popular as a means to render site navigation. This seems acceptable enough if the navigation runs along the left or right side of the interface. After all, this fits nicely with the preconceived notion of what a list is: three or more succinct items, listed one item after another. I start to have trouble with using lists for navigation in scenarios where said navigation runs horizontally across the top of a page, like it does across the top of this site.
By declaring a list item’s display attribute as “inline”, and removing any list markers by setting the list-style-type attribute to “none”, you can effectively create a display of horizontally grouped items as if you had typed out a comma-delimited list of your past responsibilities in the middle of a resumé paragraph. Is that still considered a list? CSS can be used to override almost every default rendering of any HTML element. But with the use of CSS comes the responsibility to ensure the content is still accessible, navigable, and easy to use when style information is ignored or not supported. If CSS is used to style an element beyond the point that it’s still recognizable as that element, perhaps it’s time to question the use of that element?
I’ll admit right away that some of my concerns are rooted in presentation details. And this is the reason for my internal debate. I know structural markup should be kept separate from presentational style. But the choice of HTML element here can actually affect a user’s perception of what the links are, and thus could also influence behavior and expectations.
Unstyled unordered lists are usually rendered as vertical bulleted lists, with each successive item below the previous. As I’ve said, this is fine for left- or right-side navigation. But when a vertical list of links appears at the top of a page, we tend to think of them as “Contents” links which anchor to a point further down on a long page, and not site-wide navigation which reveals top-level architecture. We’ve come to expect site-wide navigation across the top of the page is horizontal in nature, not vertical.
So we can make the styled version of a navigation list fit horizontal expectations. But what about the unstyled versions we leave behind as raw vertical lists? Should navigation intended to be rendered as tab-like in nature be structured differently than a typical bulleted list?
After all that doubt, I’m still willing to give it a try. The navigation here was originally rendered by simple <a> and <strong> tags, divided by hidden pipes, such that it looked something like this without style applied:
Home | Log Archive | Articles | Portfolio | …
It was conveniently constructed to appear like normal horizontal navigation, and even used the strong element to highlight the current page or section. It saved space when viewing in a desktop browser at least 640 pixels wide since it only occupied one normal line of text. But it did look quite ugly as it wrapped on smaller PDA and mobile screens. And the pipes were awkwardly read aloud as “vertical bar” in screen readers, producing something like “link: home vertical bar, link: log archive vertical bar…”. Not very cool either.
As of last night, I’ve decided that maybe navigation is best structured as a list, whether intended to be rendered vertically or horizontally. A group of short navigation items can easily be classified as a list. And I don’t need to limit my preconceptions of lists to vertically-oriented versions. To rationalize, I only need turn back to my original definition of a list:
“three or more succinct items, listed one item after another”
View this page without style using an older browser (v. 4.x or earlier), or using this Toggle CSS style sheets favelet (from Tantek Çelik) to see the raw bulleted list. (Use the favelet again to bring the style sheets back, or just reload the page.) A few minor additions were made to my style sheets — mostly to compensate for normal behavior of the new list. The current styled version contains no visible differences over the previous styled version. Most people would never know the difference. But now screen readers should read the navigation as a clean list without the annoying “vertical bar” announcement, and the wrapping issue on small screens has been addressed.
Some may still disagree that horizontal navigation is a list, citing expansions of the doubts I expressed above. But I’m willing to try small changes. Whether they’re improvements or not? Might still be debatable. But this is the Web, it’s all changeable.
Next on the list to debate internally: Tantek’s consideration (and execution) that a blog is just one big set of nested lists, consisting of “time date ordered sequences“. (He’s been well ahead of all of us in the use of horizontal unordered lists for navigation.) Hmmm. Extra convincing will be necessary if I’m to believe that multiple paragraphs work well when marked up as one gigantic nested list item. Fortunately, he’s still using all the heading elements to help convey typographic hierarchy.