How with YOU handle HTML5 <nav>

HTML & CSS
1

Hey everyone,

I read an article the other day (that I now can’t find…damn me for not bookmarking it) and looking at this SP thread http://www.sitepoint.com/forums/showthread.php?t=708900 (which somehow degraded into a plugin holy war) and it got me thinking about the <nav> element. The author of the article was saying in his HTML5 documents, he is no longer going to use <ul>'s for his navigation, because it is redundant. His argument is that we developers turned to the <ul> for navigation because it was the closest thing we could find in (X)HTML to use for navigation. His syntax is very simple:


<nav>
<a href="#">Link One</a>
<a href="#">Link Two</a>
</nav>

Seems simple to me, but I’m still on the fence about this one. It seems perfectly semantic to do this, but I’m still a little against it and can’t tell if I don’t want to do it because I legitimately see something wrong with it, or because I’m being stupid and just adverse to change.

So what are you going to do? <nav><ul> or <nav><a>?

2

Also, directly from the spec:

A nav element doesn’t have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose…

http://dev.w3.org/html5/spec/Overview.html#the-nav-element

3

I think you mean this article: http://blog.echoenduring.com/2011/02/23/how-html5-changes-the-way-we-think-of-navigation/#comment-63381

I don’t use HTML5 (yet) but if I would I’d still keep the list in there. It would just feel weird to stick them in there without a list; like there is no relation between the different items, which I think there is.

4

@ScallioXTX yes! That was the article. Thank you for posting it.

I think I agree with you, but let me play devils advocate for a second here: the <nav> element is supposed to bring meaning to the elements inside it. So, semantically speaking, everything inside that element is a piece of navigation, how much more relationship do you need?

Also, I should clarify one point. I’m talking about just straight up navigation…no headers. I think you would need lists if you did something like this:


<nav>
<h1>Heading</h1>
<ul>
<li><a href="">item</a></li>
</ul>
<h1>Second Nav Header</h1>
<ul>
<li><a href="">item</a></li>
</ul>
</nav>

but if it’s just a bunch of links…does it still make sense?

[COLOR=#0000FF][B][/B][/COLOR]

5

His argument is that we developers turned to the <ul> for navigation because it was the closest thing we could find in (X)HTML to use for navigation. His syntax is very simple:

How is this different from the old 1999 style of
<div>
<a href=“foo”>Foo</a>
<a href=“bar”>Bar</a>
<a href=“baz”>Baz</a>
</div>
?

Why do we use lists instead of a div filled with anchors? For the same reason Grandma has her pills in a pill box, separated by days, instead of just a whole jumble in a cookie tin. One has order and structure. The other doesn’t.

If you look at the HTML5 sites out there, you’ll notice they use nav as a wrapper for uls. One good reason to do this is for older user agents and older Accessibility Technology (like screen readers). If they don’t understand <nav> that’s fine, they’ll still see that there’s a list (and lists are navigable by AT).
Nav has a default role of “navigation” but again this only is apparent to user agents who are new enough to understand HTML5 (such as FireFox4 and the latest version of NVDA).

Nav is not limited to lists, but a navigation list remains a navigation list, and so you are not going to chuck <ul> for such a list either way. Nav does not mean “list”, it only adds the role of “navigation” to child elements inside it. Sometimes I wonder, why not just use a role attribute then?
http://html5doctor.com/nav-element/

Actually, I would even have to go look up if <li> is a legal direct child of <nav>. I thought it wasn’t.

Ah, no: http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-li-element
It’s a valid child of ol, ul, and in HTML5, menu. Not nav.

6

You would want to avoid bare anchors next to each other at any cost anyway (irrespective of html5 or not).

If css was turned off the text would all be one line all close together and hard to identify and separate. (I also believe that some screen readers would assume the links were prose and read as one sentence without pausing making it very awkward. (Stomme could probably confirm this)).

(As an aside I also dislike that html 5 allows anchors to wrap block elements because I assume that would create the same problems above as well as the exisiting browser problems that have been noticed since people started doing this.)

7

I also believe that some screen readers would assume the links were prose and read as one sentence without pausing making it very awkward.

In SayAll or similar it’ll sound like one sentence anyway:

link home link contact link products link press relations link privacy

But since they are focusable elements you can choose to listen to one at a time with tab or some shortcut whether it’s in a proper list or just a div full of anchors.

The difference in readers when you have a proper list appears when you “go down a line”. Orca can just skip the whole ul as if it were a single line if you want, which can be nice. in JAWS each “new line” would be the next link, so to skip out of that you can “n” (next non-link text).

When the links are just loose anchors in a box, they’ll not have the go-down-one-line behaviour; they’ll be like a bunch of links within a paragraph. Since “link” is announced before each one, you know either way it’s a bunch of links (this gets annoying in Wikipedia!!).

What you miss with a bunch of anchors in a box is, the ability to skip TO that list (edit, a modern reader can let you skip to the navigation landmark aria role, and nav is supposed to have that role by default, but few browsers and AT actually see/add that role to nav yet). A bunch of anchors isn’t anything; a list is a structure you can choose to visit, count, backwards and forwards. Using <nav> with loose anchors inside might tell the AT that these links are part of “main site navigation” (of course, this is up to the developer and may vary widely, so may not mean anything to the visitor anyway) but you can’t jump to that list using a quick key because instead of a list, it’s a jumble of links.

I actually haven’t seen a site lately who wrapped an anchor around a block to test, but what the reader does is likely based on what the browser does. Remember when I had that typo <a/> and Firefox created all these new “anchors” from the text that followed? Orca announced those as anchors, JAWS did not… IE did not show the following text as anchors and JAWS equally ignored them.
I wouldn’t count on AT being able to click on an anchor wrapping a block with HTML5 until after testing, because it seems AT vendors would have AT ignore that with HTML4 since it was usually a mistake.

Something I should go look at.