Does <nav> belong in the <header> element?
The short answer: if your <nav> content is short, it’s ok in the <header>. If your nav content is long, then probably not.
The HTML5 spec defines the <header> attribute thus:
The header element typically contains the headings for a section (an h1-h6 element or hgroup element), along with content such as introductory material or navigational aids for the section.
There’s a very important turn of phrase in that: “navigational aids”. That’s not the same as “navigation”.
Dealing with site navigation
When you visit a URL for an article, what are you expecting to experience when the URL loads? Presumably you’re expecting the article content or else you wouldn’t have clicked the link. I doubt you’re wanting first of all to establish it’s context within the site’s navigation, peruse what else the site has to offer, and then a few seconds/minutes later get to the content. We all hate site’s that bury content within a load of crap we’re not yet interested in - we’re busy people and we came to read that article!
Well, to my mind putting nav before content is doing exactly that - wasting time and bytes on things that are of no great importance to the URL. URLs are pointers to specific information first and foremost. Not to websites that house the content, but to the content itself. The context of the article (the site to which it belongs) is secondary. The only time a site itself is primary content is on the homepage: generally an overview of the latest and greatest from all sections of the website. So, to me, logically, the nav goes last in the mark-up. That’s perfectly in line with Progressive Enhancement, where we do mark-up experience first (no CSS), then design (via CSS), then interaction enhancements (via JS).
Who cares?
When the nav is short, source order doesn’t make much difference. When the nav is long, it does. The classic example is to put yourself in the mindset of Screen Reader users. This assistive technology reads the page out to people who are blind or struggle with vision somehow. It does that by ignoring CSS layout and reading the text from the HTML, in the order the HTML is written. You’ve likely realised the problem. If the nav is the first thing on the page, every time a screen reader user loads a page they’re read the site navigation before anything else. Imagine how tiresome that gets. Now imagine you’ve built one of those fancy mega-menus with a huge pile of drop-down information and sub-sections. And you’ve put it before the page content. That screen-reader user could be waiting for minutes to get past that irrelevant crap and onward to the article content they actually clicked on.
There’s a very well known solution: when the menu is first in the mark-up responsible developers provide a “skip to content” link prior to the menu itself, so that people using screen-readers can jump to the content without having to listen to the menu being read out. Great! But it does still mean that on every page load the user has to immediately hit a skip link. Less than elegant, but generally fine.
There’s another problem though, and while it’s less nasty for the user, it’s going to be effecting a hell of a lot more people soon enough…
Mobile
Mobile devices are small. Mobile devices don’t support :hover menus too well, if at all. Mobiles don’t let you get away with stuffing content away in corners or drop-menus because there’s no screen real-estate to put it in. People on mobile may well want to navigate all of your site after they’ve read your article, but are not generally wanting to faff about scrolling past big menu’s to get to the content every time they load a page. Want an example of how poor an experience having a big nav before content is on a small device? Go look at CSS1k.com on a mobile. And that’s a well coded site using modern best practices. But, it has nav at the top.
The cool thing about HTML5’s <nav> element
Is that it’s designed with accessibility in mind. The plan is that assistive devices will offer modes that allow the user to skip straight to all nav elements, or maybe remove them automatically from reading until directly requested. Which means, it no longer matters where the navigation is for those people. It will, however, still matter for mobile and small screens.
So my suggestion is simple: Large site navigation belongs after the page content, and not in a <header> element. It’s like the spec says: the <header> is a place for navigation aids, i.e., relevant contextual quick-links. It’s not a place for long nav.
Entry Information
- Posted:
- Tue, 12th Jul 2011 at 19:07 UTC
- Filed under:
- Tags:
Comments
skip to comment formYep. I think you've found a possible problem and answered it in the same post.
Often solving one problem creates another, and it's a case of establishing which is the better of the evils in that particular case.
Good to see you back blogging again. I need to do the same
Derek Johnson on Twitter points out that there is currently an accessibility problem with JAWS when using the header element: http://www.accessibleculture.org/research/html5-aria/
I agree wholeheartedly with the accessibility argument, however I'm not convinced in all cases you won't run into issues trying to use absolute positioning to force your nav visually where you want it. HTML/CSS for me tends to be a lot easier when your HTML order matches the order you expect a user to visually scan through the content.