Train Simple's html video gives an example of using an h1 tag to wrap the logo anchor text and h2 tags to wrap the text for the links in a nav element. I understand that if you don't have a header of some type for your nav element, it will not be good semantically, and your H5O outline will suffer as it will appear as an Untitled Nav which I guess is undesirable. I contacted Train Simple and was told that this was just one case where he used it but it doesn't mean you will do this in every case.

But now I see that I do need an h tag element somewhere within the nav element seeing that it is a semantic based element and will appear in the document outline which is used by user agents. As they teach in Train Simple, an Untitled section within the document outline is undesirable for optimization purposes.

So, I doubt that it is a good idea semantically to put h2 tags on every line of the navbar, but where do you put them? w3c's website has a model of a nav system with a single h1 element with the word "Navigation" contained just inside the nav element above the links. But who wants to have the word, "Navigation" above their navbar? Won't this look a bit dorky? It may pass the semantics part of the equation but won't the end user say, "Duh!" when they see a navbar that is obviously a navbar with the word: "Navigation" above it?

using an h1 tag to wrap the logo anchor text and h2 tags to wrap the text for the links in a nav element.

That's a lousy idea, because none of these things are headings.

I understand that if you don't have a header of some type for your nav element, it will not be good semantically, and your H5O outline will suffer as it will appear as an Untitled Nav which I guess is undesirable.

I really don't think that's true at all. The <nav> element has its own semantics, and has its own place in the new document outline.

It is sometimes recommended to place a heading over your navigation, as non-sighted users navigate via headings. Not sure if that will be needed once HTML5 is supported by screen reading software, but anyhow, you would normally move that heading off screen for sighted users, as they don't need to see it.

I often use an h1 on a corporate site for the logo where the logo contains the company name and a possible short tag-line (as most logos do) but I would use an image replacement technique so that its all text.

As far as wrapping heading tags around navigation elements then that is wrong as they are not headings and indeed would make it hard for non sighted users to skim through the documents headings (using ctrl h or something similar). A heading tag above the navigation may be useful as Ralph said above but should be hidden from sighted users. It's not something that I would usually do though.

A heading tag above the navigation may be useful as Ralph said above but should be hidden from sighted users. It's not something that I would usually do though.

Okay, that explains what Ralph meant. So I can make an h2 tag nested just within the nav element and hide it for sighted viewers. What do you suggest I do to hide it? I have heard that if you try hiding keywords by using the same text color as the background you can be penalized for spam. Do you think google would penalize me for hiding h2 text?

Okay, that explains what Ralph meant. So I can make an h2 tag nested just within the nav element and hide it for sighted viewers. What do you suggest I do to hide it? I have heard that if you try hiding keywords by using the same text color as the background you can be penalized for spam. Do you think google would penalize me for hiding h2 text?

The best method is to absolutely place the header off the screen to the left e.g .element-name {position:absolute;left:-999em}. You won't usually be penalized for doing something good. You will only get penalised if you stuff the heading with keywords that don't make sense to the layout.

Do you think you could explain what is your technique? Perhaps you have an article written on that?

This is very old but explains the method and just view source to see the actual code as it is al in the head.

This is very old but explains the method and just view source to see the actual code as it is al in the head.

Sorry, I am not even coming close to understanding this. I have read what you said and looked at the link, but apparently I don't know enough about this to understand it. May I just ask what is the reason for this?

Sorry, I am not even coming close to understanding this. I have read what you said and looked at the link, but apparently I don't know enough about this to understand it. May I just ask what is the reason for this?

The basic idea is that instead of an image in the html you supply text content in the html but replace the text content with a background image instead. Typically this is done for logos or headers where a company (or site) name is actually a stylised text image and for accessibility (and seo) it would make a little more sense to have the details as text content in the html instead.

If you have a site that has a logo image that says "ABC TRADING - The best widgets you can get" then instead of using a foreground image in the html you can put that actual text into the html and then use an image replacement technique to provide the original stylised image as a background image. This means that screenreaders may read the text more easily than looking at the alt text in an image and if images are turned off or missing then you still have the text in the html showing whereas not all browsers will show the alt text correctly if the image is missing or you get the broken image icon showing and messing the page up.

Whether or not it is better to have the image in the html or not it still does make it easier to manage the layout if you have that image in the background and controlled via css.

You would not do this for all images of course but only images that are used in place of text content such as graphical headings that have very stylised text that can't be produced in a browser so the author has created an image. In these cases you can use an image replacement technique instead.

I typically use it for logos and site names but rarely use it anywhere else in the page.

On the other hand I don't see a big drawback to having the actual image in the html as long as the alt attribute content is descriptive enough and you don't mind that some browsers may not show the alt content if the image is missing - or they just show the horrible missing image icon and square outlined box.

In the end it's just another tool in the box to use when you think fit.

But now I see that I do need an h tag element somewhere within the nav element seeing that it is a semantic based element and will appear in the document outline which is used by user agents. As they teach in Train Simple, an Untitled section within the document outline is undesirable for optimization purposes.

I see what you mean now. I've been reading a bit more about HTML5, and because the <nav> element is a sectioning element, it must include a heading. Otherwise you get that "Untitled section" rubbish in the document outline (not that this outline is recognised by any devices yet). Still, it seems like a ridiculous rule to me—another nail in the coffin for the HTML5 elements and the proposed new document outline.

I wouldn't use a heading tag for the logo text at all. Heading tags have a semantic purpose and there should only ever be one H1 tag on any given page.

A better technique is to a image replacement and then use the HTML hgroup tag to give the logo text a grouping that you can then apply styling to using a class hook.

As Ralph said the hgroup was dropped early this year so you should be removing it from your documents and not using it. That's the danger of jumpig in early into an unfinished spec. Html5 also allows for multiple h1's where appropriate as h1 nested in sections become lower priority and will fit naturally into the outline. It's not something I like though. (Html4 did also allow multiple h1's but there would need to be very good reason to use them.)

Html5 also allows for multiple h1's where appropriate as h1 nested in sections become lower priority and will fit naturally into the outline.

Also bear in mind that this outline doesn't exist yet, and may never do, according to its own inventor (Hickson). So at the moment, and quite likely into the far future, using multiple h1s will cause a lot of confusion for people on assisting devices. So the growing advice is to stick with the regular, millennia-old practice of structured headings.

Also bear in mind that this outline doesn't exist yet, and may never do, according to its own inventor (Hickson). So at the moment, and quite likely into the far future, using multiple h1s will cause a lot of confusion for people on assisting devices. So the growing advice is to stick with the regular, millennia-old practice of structured headings.