Is NAV okay for SKIP LINKS navigation?

[tenfingers]

For years I've been using this markup to insert SKIP LINKS into the body of lengthy pages with lots of sections and internal navigation links:

<!-- old -->

<div class="skiplink"><a href="#content">Skip navigation</a></div>

The element is styled with a negative text-indent and zero line-height to keep it off the display, and has worked fine all these years. Ain't broke, so why fix it?

I'm taking this site out of the 2005 world (probably more like 2001) into the modern era by swapping in HTML5 semantics with the aim at making it more future friendly. Which brings me to my question:

Is the NAV element okay to contain these page fragment links?

<!-- new -->

<nav><a href="#credits" class="skiplink">Jump to program and document credits</a></nav>

For IE 8 I had to move the style hook to the anchor.

[deathshadow60]

Generally I've been using a full menu for that, with accesskeys and titles for on-page navigation.

	<ol class="jumpto">
		<li>
			<a href="#pageWrapper"
				accesskey="1"
				rel="nofollow"
				title="Top of Page"
			>Top of Page</a>
		</li><li>
			<a href="#mainMenu"
				accesskey="2"
				rel="nofollow"
				title="Main Menu"
			>Main Menu</a>
		</li><li>
			<a href="#content"
				accesskey="3"
				rel="nofollow"
				title="Page Content"
			>Page Content</a>
		</li><li>
			<a href="#sideBar"
				accesskey="4"
				rel="nofollow"
				title="Page Extras"
			>Page Extras</a>
		</li><li>
			<a href="#footer"
				accesskey="9"
				rel="nofollow"
				title="Bottom of Page"
			>Bottom of Page</a>
		</li>
	</ol>

Go to my crappy personal page (2 years of webrot) in Opera, and hit "shift-esc" to see why I do it this way.
Home - DEATHSHADOW PASCAL

As to Nav? why waste a unnecessary wrapper on it. I mean, unless you don't already have a block level wrapper there is no reason to waste code on any of that extra HTML 5 bull.

But I say the exact same thing about HEADER, SECTION, ARTICLE and FOOTER... pointless wasteful unnecessary crap to stack on top of the ridiculously loose structural rules that make HTML 5 more a trip back to 1997 than improvements to coding practices compared to 4 or X1.0 STRICT!

[tenfingers]

Generally I've been using a full menu for that, with accesskeys and titles for on-page navigation.

Go to my crappy personal page (2 years of webrot) in Opera, and hit "shift-esc" to see why I do it this way.
Home - DEATHSHADOW PASCAL

Novel technique, with only one drawback (minor) that I can see : the display:none; property on the .jumpto class. Neither robots nor screen readers can see this. But it's not an issue that can't be tackled with, visibility: hidden; or text-indent: -9999px; methods. (They do have 'names' but I never get them right without first searching. The methods are familiar, though.)

As to Nav? why waste a unnecessary wrapper on it. I mean, unless you don't already have a block level wrapper there is no reason to waste code on any of that extra HTML 5 bull.

But I say the exact same thing about HEADER, SECTION, ARTICLE and FOOTER... pointless wasteful unnecessary crap to stack on top of the ridiculously loose structural rules that make HTML 5 more a trip back to 1997 than improvements to coding practices compared to 4 or X1.0 STRICT!

As a matter of fact, these are free standing blocks, child elements of the content wrapper, or page wrapper, as the case may be. I admit, DIV is just as appropriate, and doesn't require restyling. But I'd like to get my feet wet, and have started with something a little less complicated, the footer and hidden navigation.

I'm finding that IE 8 with a shim is still spotty on styling HTML5 elements, but the revised styling on the anchor solves this. It's not a debate. Whether I like it or not, I would still like to be able to add HTML5 and CSS3 (and eventually the new DOM) to my repertoire just so I can have a chance to learn the in's and out's, and quirks as they may arise.

In five years I will have forgotten all the tweaks and the reasons behind them. And just like a decade ago, everything will eventually fall into place.

[deathshadow60]

Novel technique, with only one drawback (minor) that I can see : the display:none; property on the .jumpto class. Neither robots nor screen readers can see this. But it's not an issue that can't be tackled with, visibility: hidden; or text-indent: -9999px; methods. (They do have 'names' but I never get them right without first searching. The methods are familiar, though.)

I've had screen reader users actually complain about their presence (just more to get past before they get to the content!)... really those types of menus are for non-screen CSS and handheld users anyways -- and why would I want search engines to see ON PAGE links in the first place? Non-issue.

[tenfingers]

I've had screen reader users actually complain about their presence (just more to get past before they get to the content!)... really those types of menus are for non-screen CSS and handheld users anyways -- and why would I want search engines to see ON PAGE links in the first place? Non-issue.

I see your point. This is just one more of the many discoveries years late that one thing or another is incorrectly implemented or unnecessary, or implemented for the wrong reasons.

In other words, these elements are faux pas if the target audience isn't using non-screen or hand held devices?

My reasoning has been to allow screen reader users to jump around each entry until they get to one they are after. It is not only applied to major page elements. But now that I read what you post, it makes sense to apply the same logic.

As for wanting robots to see the links, I don't know how that got in there. By the same token, do robots follow in page links? I've always believed they were ignored, but then I saw the nofollow in your menu and wondered, "Is there juice going through fragment links?"

[deathshadow60]

The nofollow are on there because while on-page links do not enhance your search results, google does actually penalize you for on-page links that are hidden using display:none. It's an annoying combination of "I want none so screen reader users don't get them" and "If I do that, google slaps me down for content cloaking"... the nofollow stops google from thinking the display:none is content cloaking of links. Stupid, but it works.

Usually the best way for screen reader users to get around your page is to have a logical heading order. MOST screen readers let people use heading tags as a way to navigate the page, which is part of why I'm such a stickler about using headings PROPERLY.

A great way to test that is with the FF Web Developer Toolbar. Under the "information" menu is a "document outline" -- which will warn you about missing headers, and lets you easily see if your heading tags make any sense.

Which for most people -- they don't. Remember, the reason for only one h1 on a page is that all other headings are by definition subsections of it... just as h3's are supposed to be the start of subsections of the h2's, and so on and so-forth.... which is why for example having h2's before your h1 makes no sense, and 'hanging' headings that skip over numbers make even less sense.

It's one of the things numbered headings, table headings, captions and legends are supposed to be for -- and why semantic markup beats the ever living tar out of presentational markup when it comes to accessibility.

[tenfingers]

You've been a big help, @deathshadow60. If not with the actual OP, then with settling my mind as to which way to go from here. Those hidden blocks will be removed. There is good heading structure, already, so from what you say, the navigation is unnecessary. Thanks for stressing that.

It also follows that it is self defeating to declare a block as navigation and then hide the contained link.

I still need navigation to get around large blocks of links, though. It's not something I can do away with, as far as I understand. But since the skip link is independent of the list, it will remain in a free stranding div. What should I be doing, if not this, in your view?

[tenfingers]

Having done away with section jumps, this is my take on what to do next:

<nav>
 <a href="#nexthiddenlink" id="hl_n" rel="nofollow">Skip Navigation</a>
 <ul id="longlinklist">
  <li> .. </li>
 </ul>
 </nav>

The anchor is contained in the nav block, so is not an orphaned inline element, and the standalone block has been done away with. The ID is on 'a' and 'ul' for IE 8. A workaround, but not drastic. I've left off the title attribute to limit verbosity to just the link text.

What if anything needs to change in my thinking on this?