[html5] Understanding <nav> and <h1>

Nathan Ziarek nziarek at gmail.com
Thu Jan 21 07:17:50 PST 2010


Thanks Blue ...

I certainly don't believe there should be only one <h1> or <h2> tag
per page, but I do believe that these tags should be used for the
_content_ and not the _chrome_. This is a valid debate, one that's
been had many times, but in my view HTML is a page structure, not a
site structure, and therefore semantic elements (H, P, EM, STRONG)
should be used on elements that describe the page, not the site.

I disagree that this doesn't affect SERP and with the example of
screen reader UAs.

Assume my site looks something like this:

<div id="mainNav">
<h1>Menu Title 1</h1>
<ul><li><a>...
</div>
<h1>Title of Article</h1>
<p>lorem ipsum</p>

While the algorithm of the search engine may be able to deduce the
difference between the first and second H1 in some cases, it certainly
cannot in all cases. In those instances (and my guess it is more
common than not that the SE does not know the difference), I've
effectively diluted the semantic power of the page content  -- the
article title -- by each and every H1 in the menu.

In the case of a screen reader, if the UA is parsing the document and
reads aloud "Heading S E O" there is no way for me to know if this is
the heading of a menu item or the article of the page I am on. I do
not see a benefit to outweigh this confusion.

This all changes with the advent of a semantic layout element like
<nav>. Now all UAs that do not comprehend the design of the page
(screen readers to SE crawlers) can understand that the content within
<nav>...</nav> is not page content, but navigation. Using H1 within
this page part makes much more sense.

My question here is whether or not search engines -- and we can narrow
that to Google and Bing (minor) -- account for the <nav> element yet,
to the best of anyone's knowledge? If not, then I do believe using H1
for a navigation element hurts the semantic relevance of your content,
which effect search engines and screen readers alike.

Best,
Nathan



More information about the Help mailing list