Navigation Menu (Why use ul?)

[bradproctor]

I was recently told I should be using unordered lists for my navigation menu. I've seen them used in navigation menus as well quite often. For example,

<ul id="menu">
 <li><a href="">Item 1</a></li>
 <li><a href="">Item 2</a></li>
 <li><a href="">Item 3</a></li>
</ul>

My question is what is the use of the list? I've been writing them like the code below for quite some time without any trouble. Less code, and it styles in CSS just fine...

<div id="menu">
 <a href="">Item 1</a>
 <a href="">Item 2</a>
 <a href="">Item 3</a>
</div>

Is there something I'm missing?

Thanks,
Brad

[tedster]

A list is the most semantically accurate mark-up for a menu, because it is not just links but a list of links. That's the main point behind this trend as far as I know.

[rocknbil]

Agreed . . . otherwise usurped by HTML5's <nav>. :-)

I've been writing them like the code below for quite some time without any trouble.

Visually, that works. But those links are now "empty content" wrapped by a container which has no semantic meaning (div, span, br, all have no contextual meaning.)

The list scenario says . . . "I am a list of links." It's just one more attribute to building smart documents.

[Fotiman]

<nav> doesn't usurp the list though. It supplements it.

<nav>
  <ul>
    <li><a href="#">home</a></li>
    <li><a href="#">blog</a></li>
    <li><a href="#">gallery</a></li>
    <li><a href="#">about</a></li>
  </ul>
</nav>

[alt131]

Hi bradproctor and welcome to WebmasterWorld :)

I think your point about more/less html is an important one. Frequently code that doesn't use lists is much heavier than your sample, so lists would actually reduce the bloat.

In your case that's not so, but there is a trade-off. Recalling that html marks-up content, and that conveys a meaning about the nature of the content so the user agent can deliver it to the user most effectively. The first example might work for user agents that understand whatever styles you've applied, but if they don't, or the style is lost it resolves to:

Item 1Item 2Item 3

Which is difficult to read, and gives a smaller target area that makes the links difficult to select with a mouse. Other user agents, such as assistive devices using voice will "speak" some equally less helpful variation of

linkItem 1linkItem 2linkItem 3

Using a list means items will be displayed in a way that provides basic readability and usability, and assistive devices will usually warn the user in advance so they are prepared to hear a list of links and decide which one to follow afterwards. In your case those benefits require adding 23 characters to the html, but in this case I would suggest it's worthwhile.

[edit reason]Spelling!

[koan]

Aside from the semantic reasons, having a list also provide design opportunities like a background image in the link element and the li element for each item, ex: the CSS sliding doors technique.

[Vladimir]

As alt131 has already noticed the mark-up you have provided can be shorted then UL based only in some simple cases. If you have an advanced drop-down menu, that structure is not enough. And writing the code like this:
<div id="menu">
<div><a href="">Item 1</a></div>
<div><a href="">Item 2</a></div>
<div><a href="">Item 3</a></div>
</div>
makes no sence in comparison to UL. More then that, if you have muli-level menu how the levels will differ? UL, LI tags simplify that too.

[edited by: tedster at 12:47 am (utc) on May 23, 2011]

[pokra]

+1 with what @koan said.

[penders]

alt131: The first example might work for user agents that understand whatever styles you've applied, but if they don't, or the style is lost it resolves to:
Item 1Item 2Item 3

There is white space between the links (newline), so I think this will resolve to:

Item 1 Item 2 Item 3

Which is still 'readable' in this instance.

[pageoneresults]

<nav>
 <ul>
 <li><a href="#"></a></li>
 <li><a href="#"></a></li>
 <li><a href="#"></a></li>
 </ul>
</nav>

Which can appear...

<header>
<nav>
 <ul>
 <li><a href="#"></a></li>
 <li><a href="#"></a></li>
 <li><a href="#"></a></li>
 </ul>
</nav>
</header>

or...

<aside>
<nav>
 <ul>
 <li><a href="#"></a></li>
 <li><a href="#"></a></li>
 <li><a href="#"></a></li>
 </ul>
</nav>
</aside>

or...

<footer>
<nav>
 <ul>
 <li><a href="#"></a></li>
 <li><a href="#"></a></li>
 <li><a href="#"></a></li>
 </ul>
</nav>
</footer>

Gotta love the document segmentation available with HTML5. :)

In regards to links in list elements, it's always been the suggested practice to put lists of items (links included) into <ul>, <ol>, <dl> elements for the reasons explained above.

In reference to white space, there is a Priority 3 Checkpoint for formatting links with white space between them. "10.5 - Until user agents render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links."

Using list elements allows much more control over the semantics and display of your links.

[alt131]

@pageoneresults - that is my habit too, but note 10.5 is from version1, and according to the comparison of checkpoints between WCAG 1&2 [w3.org], it is nolonger required (although noted as still useful for users with cognitive disabilities).

@penders, just did some quick tests in latest versions, and you're right - thanks for picking that up. Still a small target area though, and not sure the benefit of debating when readable=readable :). Note that although 10.5 above is nolonger required, it is now reflected in Success Criterion 1.3.1 (info and relationships), which provides for semantic structure to make information and relationships determinable, and H48 provides for meeting that by using a list to mark up groups of links.

[penders]

@alt131 It was just minor point, but I thought worth mentioning - not that I necessarily thought it was OK still. Thanks for the accessibility info and link.

[alt131]

@penders - No fear, that was how I read your post - really appreciate you taking time to make sure even "minor points" are accurate/up-to-date - definitely worth a mention! (And finally gave me a good reason to follow through the WCAG list issue too.)