Page (and heading) structure conundrum

[adh32]

I want to include headings, positioned off-screen, inside major page divisions such as the navigation and footer. To me, it makes a lot of sense to improve ease of use by providing these extra "hooks" (for want of a better word) by which I know that a lot of vision-limited users navigate when they use assistive software. I imagine that it would also improve their understanding of the page structure and content. Win-win (for those users, at least).

The trouble for me is in dealing with anything that sits above the main content (and its H1) in the HTML. My current structure is simple and minimal. At the very top, I have skip links; then a position:fixed vertical menu on the left with the main content to the right of it, and nothing else except a footer:

<div id="skip-links">skip links in a UL</div>
<div id="navigation">main menu items in a UL</div>
<div id="content">
<h1>main title</h1>
main content...
</div>
and a simple footer div...

As far as I can see, I have limited options. (a) Move the main menu to below the main content and change the skip links to suit. This would not alter its screen position but I have major reservations about this unconventional HTML layout that would not match the screen layout. And the skip links couldn't receive a heading in that case, though that might not be a huge issue. (b) Be slack with heading hierarchy and use lower-numbered headings in the divs above the content. Again, I'm not keen on that. (c) Move the H1 up in the HTML, above the skip links, and somehow work around or correct the HTML/screen order (because the H1 ideally needs to be below the skip links so that it's directly above the content: this makes much more sense to me). (d) Put a generic website title in an H1 and use an H2 for the content's title. I know that some sites do that, but I hate it: making the most important heading a generic title or logo? It just doesn't make sense to me. (e) Who knows...

I need recommendations and counsel, please folks! How do you solve layout issues like this in a way that ticks all the boxes: semantic HTML, tidy structure, matching HTML/screen order, meaningful content, helping all users...

[Tyssen]

I don't generally bother with a heading for the main navigation on the page because it's a fairly common practice for it to be near the top of the page so it should be fairly obvious to most people (sighted or otherwise) what it is when they encounter it. I'd only bother with headings for navigation if they appeared in other places of the layout.

You can also add extra accessibility and semantic meaning to your elements by using ARIA landmark roles, like <ul role=navigation> which is something that I do.

[adh32]

Yes, I have landmarks in place. Regarding the headings: do you not think that they also aid in-page navigation for screen reader users? I know that they are often used in that way, so if they are also useful for reaching the navigation and footer, that would seem to be a strong reason for using them in most, if not all, major segments.

[Stomme poes]

do you not think that they also aid in-page navigation for screen reader users?

They can; header-navigation is one of the easiest ways to bop around in a page. But I agree with Tyssen: you're overdoing it here. People have access to the beginning and end of the page: the skip links are the first content on the site; heading them is unconventional and unnecessary.

I don't "head" my skip links and I usually don't "head" my main menu (unless, as Tyssen mentioned, there are other menus... complex sites may have a "main" navigation menu (which I would give a role of "nav" to), a "sub" navigation (less important but still site-wide links, like privacy, terms&conditions, press releases, investor relations... and this nav might be in the footer), a "products" menu for sites who sell many products, etc) because, as Tyssen said, the main menu is fantastically obvious and users have numerous ways of navigating it. Headers are Good, but Being Too Chatty can reduce accessibility. There's a clever term for this (too much accessibility) but it escapes me. In any case, it can become annoying quickly.

Users who want to get straight to the main content have many options:
-they can use your skip links (see Safari note below); so make the link text obvious that it's for skipping
-they can call up all the lists of links on the page, and select the second one (main nav) and then Next Non-Link Text (this would be your h1)
-they can use h or h-1
-they can go directly to the role of "main" that you'll have on your content div
-they can go do the role of "nav" and then Next Non-Link Text

Lots of options. Most sites don't head skip navs or main navs, meaning these other methods of moving around them aren't lost on experienced users. I would expect less-experienced screen reader users to use the skip links heavily... so a link to your footer would not be a bad idea. Also, skip links are still pretty cool for sighted keyboarders... so have that text appear onscreen on :focus.

A note on the "using skip links to move focus down the page": this won't work in Safari, which means it won't work for VoiceOver users who don't use Firefox or some other browser. Safari moves the visual focus down when clicking on a skip link whose destination is an id attribute, but it won't move the keyboard focus. If you want to ensure VO users using Safari get real skip links, you'll need to embed something clickable at the skip destinations. I use empty anchors inside the elements whose id's the other browsers are using.

Opera sometimes won't do this either, but I forget the rule for Opera (and I worry much less about skip links in Opera: it's trickier to use with many screen readers and Opera offers spatial navigation for sighted keyboarders, meaning they have more freedom to move where they want than users of other browsers).

I personally would say heading the skip link nav is Too Much and heading the main nav is being Captain Obvious.

Having a skip link to your footer is good/fine if there's a nav in there, using role=complementary is good, heading it is something I'd only do if I had a Fat Footer (those ginormous things people manage to call footers but are like half the site page crammed with information... and may have multiple headers inside them!).

This would not alter its screen position but I have major reservations about this unconventional HTML layout that would not match the screen layout.

While I agree with your conclusion (don't move the main navigation to an unconventional order in the markup), whenever you start playing with position: fixed, that kind of talk gets nowhere fast, because screen layout becomes disconnected with any sort of reality anyway. I had a layout with main navigation in a fixed footer (but also, really in the footer) and even setting up skip links at the start of the page, I was pretty sure people would get confused. I just didn't have any authority to re-arrange that page though.

[adh32]

No, I wasn't going to add a heading to the skip links (I should have clarified that), but I thought that the main menu and, most of all, the footer could benefit from it. I was looking at what the 456 Berea St website has and figured that this would be representative of best practice. Although, as with so many things, there is probably much more than just one "correct" answer.

Re: the skip links; I have one going to the footer, which has quite a lot of supplementary links (privacy, terms, archive, etc.) and content in it. Not a ridiculous amount, but it makes it a major content section.

Re: the fixed main menu; is it OK to do this if its initial position on-screen pretty much reflects its position in the HTML? On-screen, it's lined up to the left of the H1 (and its subsequent content) with the skip links appearing above these two sections. I just like having it fixed because I appreciate the convenience when browsing.

Thanks for your input.

[Stomme poes]

No, I wasn't going to add a heading to the skip links (I should have clarified that)

ok

but I thought that the main menu and, most of all, the footer could benefit from it.

Yeah, if your footer has enough content to be headed, a header in the footer can be a good idea.

I was looking at what the 456 Berea St website has and figured that this would be representative of best practice. Although, as with so many things, there is probably much more than just one "correct" answer.

Hm, I definitely can't say Roger's site isn't best practice! Roger likely added the header specifically for navigation purposes, for a few reasons:
- there's actually stuff in the way between the skip link and the navigation (including a search form)
- and he hid the header because whether CSS is on or off, his main navigation is obviously obvious main navigation.

It still seems a little overboard to me but with that search form in there, it's probably nice to have. Also, he's mixing HTML5 stuff and wrapping excessively with divs for the browsers/UAs who aren't HTML5-ready yet, and so he's probably using the hidden headers as counterparts to the roles (since olders UAs don't understand roles and users won't be able to use them for navigating). His code might be a bit of a purposeful showcase in that regard.

On this site: http://juicystudio.com/ you see Gez has a lot of content coming before the navigation, and does the same thing as Roger, except he left it out in the open because its position makes it somewhat less obvious. I would otherwise completely rely on his CSS to easily find the menu.
If you were still thinking of having your nav in the footer (or a sidebar), then not only would a header be okay but I'd even consider leaving it out in the open for everyone.

http://lflegal.com/ which was done by Mike Cherim (who on his own blog had headers before the navigation, which is actually probably the place I first saw this technique) and was one of the two first sites to pass Vision Austraila's WCAG2 tests, also uses header navigation— but like Gez' site, the navigation is after a bunch of other content, and keeps the header onscreen.
Interestingly, there are also headings (hidden) for the breadcrumbs and some extra text ("You're exploring").

Mike Paciello's blog page http://www.paciellogroup.com/blog/ doesn't use hidden headers above the navigation but, looking at the page, the navigation doesn't look like the main course of anyone's navigating.

I dunno, I can see the arguments for headers before main navigation, but personally (yeah, opinion) it's a little more than necessary.

Re: the fixed main menu; is it OK to do this if its initial position on-screen pretty much reflects its position in the HTML? On-screen, it's lined up to the left of the H1 (and its subsequent content) with the skip links appearing above these two sections. I just like having it fixed because I appreciate the convenience when browsing.

It's probably ok. I mean, if you're thinking of screen readers, it doesn't matter where you set it with fixed positioning. If you mean everyone else, it's probably okay but you could always ask users for feedback or do user testing.

[adh32]

Thanks, Stomme. Much appreciated.

[deathshadow60]

I really don't think putting the h1 before the accessibility menus is a big deal -- it's ONE MALFING LINE. Hoody-hoo!

Though, just to rag on you a bit (not entirely serious -- not sure if those are placeholders or if you'll have them in the final code) if the accessibility menu going to be a UL, why have the DIV? If the main menu is going to be a UL, why have the DIV? Both are perfectly good block-level containers so don't waste a div on them for NOTHING -- especially the one you won't display for screen/print.

Though I would NOT position them offscreen. Display:none is typically fine if you put accesskeys on them with title attributes.

Check out Home - DEATHSHADOW PASCAL in Opera (excuse the green, it's a retrocomputing joke) and hit shift-esc to pull up the accesskeys menu.

I usually rag on people for "pointless" title attributes -- if the title is the same as the content inside the element, there is NO reason to put title on it... unless you have accesskeys! Then it actually does something useful.

Though that really comes down to do you want screen reader users to hear them or not -- I've actually had screen reader users complain about their presence which is why I display:none them for media="screen,projection,tv" but leave them alone for "handheld" where they are useful... and of course CSS off browser users love them too.

Really though, if you are practicing separation of presentation from content how does it look without the CSS? There's a reason I advocate coding the entire markup semantically before even THINKING about appearance/layout.

[Stormrider]

Though I would NOT position them offscreen. Display:none is typically fine if you put accesskeys on them with title attributes.

A lot of screen readers won't read things out that are display: none, so it kind of defeats the whole point!

[deathshadow60]

A lot of screen readers won't read things out that are display: none, so it kind of defeats the whole point!

read paragraph 6... the one starting "Though that really comes down to"

[Stormrider]

You were talking about title attributes at that point!

[deathshadow60]

You were talking about title attributes at that point!

There's more than one sentence... Literacy much? "display:none" is only IN the second sentence and all...

[Stomme poes]

Though that really comes down to do you want screen reader users to hear them or not -- I've actually had screen reader users complain about their presence which is why I display:none them for media="screen,projection,tv" but leave them alone for "handheld" where they are useful... and of course CSS off browser users love them too.

That defeats the purpose then doesn't it (the purpose according to the OP is using them for navigation)?

My posts above agree with your concern that adding headers everywhere may make the page "chatty" (which experienced screen reader users find more than annoying), BUT if you're going to add them in anyway, then make them heard.

There's zero point in having them in there and also display: none, unless they're being added for teh Googles. And I don't add crap special for them, they're the least important visitor in my view.

Though the handheld idea, that one's good (I hide stuff in my desktop.css that isn't hidden in the handheld css) but I don't hide from screen reader users.

One reason being, how do I know the visitor is experienced? Screen reader n00bs do everything slowly, they make generous use of skip links, and they are often tabbing/arrowing through everything instead of using more advanced navigation. So I try not to overdo it with headers, but if I'm gonna waffle anyway and add them in, I know those who really don't need them likely also know how to skip them anyway.

Titles: you can't know people turned "read titles" on. It may be default in their reader... it may not. Or they may have turned them off explicitly because so many sites throw titles around everywhere (as you said). Only place I trust titles is in form controls (inputs, this is when for some *good* reason there isn't an explicit label), and there's one popular reader who still ignores them (Orca).

[deathshadow60]

That defeats the purpose then doesn't it (the purpose according to the OP is using them for navigation)?

There are things OTHER than screen readers; like handhelds which is what the original point of such menus was supposed to be; I find it odd to even find people talking about screen readers for such a thing -- since they generally navigate the heading structure. (which is why I'm such a stickler for proper heading orders).

There's zero point in having them in there and also display: none, unless they're being added for teh Googles.

HANDHELD, SMALL SCREEN. HANDHELD, SMALL SCREEN!!! Bandwidth locked text only on Blazer or similar...

Especially when, as I mentioned, the device lets you use an accesskeys menu.

Titles: you can't know people turned "read titles" on. It may be default in their reader... it may not. Or they may have turned them off explicitly because so many sites throw titles around everywhere (as you said). Only place I trust titles is in form controls (inputs, this is when for some *good* reason there isn't an explicit label), and there's one popular reader who still ignores them (Orca).

90% of the time people use title attributes there's no good reason for it. I've said it a billion times if you NEED a title attribute and you aren't using accesskeys, there's something HORRIBLY WRONG with the content of the element. This is particularly true of anchors...

REALLY true when you see people putting title attributes on an anchor that's identical to the content of the anchor! /FAIL/ hard. (Yes turdpress, I'm looking at you!)

For example:

<a href="/" title="home">Home</a>

== Go back and learn how to write HTML!

[Stomme poes]

HANDHELD, SMALL SCREEN. HANDHELD, SMALL SCREEN!!! Bandwidth locked text only on Blazer or similar...

Especially when, as I mentioned, the device lets you use an accesskeys menu.

Are you claiming people using handhelds need headers to tell them what's a menu?
I certainly don't add extraneous headers for handhelds. If you need a header before your main menu then your menu isn't obvious (which is fine, this is true in most of the examples I listed earlier... the menu was nowhere near the top of the page and needed a header... ONSCREEN for EVERYONE in most cases).
The OP asked if more headers should be added to the page specifically for screen reader navigation more than anything else... that's what most of our answers in this thread were about.

And I don't touch accesskeys with a 10-foot pole. I realise large sites who are constantly revisited by people do (like SitePoint and BBC) but I will not add them to any of my pages.

Someone twotted a web site at me and said "like your browser shortcuts getting fux0red?" Now I couldn't see what he was talking about at first 'cause it turned out someone was retarded and used Javascript but anyway they hijacked CTRL-L to bring up some annoying modal popup thing (instead of letting us bring focus to our addressbar). I don't touch accesskeys because I'm not going to memorize the 500 different key combinations possible on every OS and browser just to make sure I don't accidentally interfere with someone's built-in shortcuts. Yeah, even if I stick to numbers like BBC.

But that's me.

REALLY true when you see people putting title attributes on an anchor that's identical to the content of the anchor! /FAIL/ hard. (Yes turdpress, I'm looking at you!)

For example:

<a href="/" title="home">Home</a>

== Go back and learn how to write HTML!

Yeah, I caught someone using Drupal with one of these. Title text would have been great taglines for the pages the anchors linked to, but it was ridiculous on anchors.

I wonder if most CMSes out there are adding title="" and prompting people to fill them in?? Arg arg.

[Stormrider]

Yeh, I was wondering why these were needed for handheld device... maybe 10 years ago when WAP was all the rage, but not any more!

[Stomme poes]

Yeh, I was wondering why these were needed for handheld device... maybe 10 years ago when WAP was all the rage, but not any more!

Well, if a section of content is relying on desktop styling to make it obvious to users what it is, a header is a good idea... but then, a header should have been there in the first place anyway. Looking at Gez Lemon's page, again, I would need CSS styling to find the navigation menu (it's surprisingly easy to miss, at least for me). I actually found it first by searching in the source, and then /Site Navigation to search for that text in my browser, which highlighted the header above the navigation.

[deathshadow60]

Are you claiming people using handhelds need headers to tell them what's a menu?

Huh?!?

I'm saying if you make a skipto/jumpto/accesskeys menu for ON PAGE navigation, that's mostly for handheld users where it's REALLY useful on the pathetically small display; like in Blazer, Opera Mobile or Opera mini.

I think you completely missed what I was saying or something.

The OP asked if more headers should be added to the page specifically for screen reader navigation more than anything else... that's what most of our answers in this thread were about.

Which is wierd -- that's not who I ever heard of them being for. Acessibility aid, certainly, but not for screen readers... I know when I'm stuck on a small display they're a HUGE help for skipping around the page rather than the PAINFUL scrolling through trying to find things. Hell, I even use them on desktop on occasion since Opera supports them properly.

[Stormrider]

Modern handheld devices all support CSS though... so anything you'd see on a desktop browser, you should see on the mobile one anyway.

[deathshadow60]

Modern handheld devices all support CSS though... so anything you'd see on a desktop browser, you should see on the mobile one anyway.

SOME CSS.... and not everyone is going out for the monster data plans with the $400 a pop devices (or two hundred dollar a month data plans) so there's plenty of people still using Opera Mini, Opera Mobile, and Blazer. (in fact, aren't the majority of handheld users STILL using Opera in one form or another?)

... and "anything you'd see on a desktop"?!?!? Sure, that 240x320 display is SO useful on those idiotic 1024 fixed width layouts... Someone on a droid phone is going to disagree with that one a hell of a lot...

[Stomme poes]

I'm saying if you make a skipto/jumpto/accesskeys menu for ON PAGE navigation, that's mostly for handheld users where it's REALLY useful on the pathetically small display; like in Blazer, Opera Mobile or Opera mini.

Ok, I thought you meant header tags. Skip links: I don't make them so much for screen reader users as I do for sighted keyboarders of any sort. Mobiles count as this.

I think you completely missed what I was saying or something.

Yes but I think I got it now.

Which is wierd -- that's not who I ever heard of them being for. Acessibility aid, certainly, but not for screen readers...

Yup, just about every major screen reader lets you hit a quick key (usually "h") to move to the next header (or shift+h, previous header, or choose a number to reach next/prev header of a certain level... which is why the HTML5 let-sections-determine-header-levels might be a disaster). Header-based navigation is so, so nice in a screen reader. It pretty much lets you skim any well-structured page.
Here's a video of a guy using JAWS 9 and header navigation
But NVDA and Orca and I believe Window-Eyes do exactly the same thing.
Since I learned how to navigate in JAWS via keyboard better than I ever bothered to learn keyboarding in any of my browsers, it's become preferred when I'm testing my sites' keyboardability anways.

I know when I'm stuck on a small display they're a HUGE help for skipping around the page rather than the PAINFUL scrolling through trying to find things. Hell, I even use them on desktop on occasion since Opera supports them properly.

Are you talking about header tags here? Opera lets you skip by headers just by itself? If so, this is pretty cool but totally new to me.
I suspect you're not so some code demonstrating what you mean would be nice.

(in fact, aren't the majority of handheld users STILL using Opera in one form or another?)

I think it was pretty close to the top, though with Nokia still being most popular phone worldwide, their browser that came with Symbian (webkit based in some way) may be at the top.

so anything you'd see on a desktop browser, you should see on the mobile one anyway.

I agree with Crusty on this, simply because the stuff you see on sites geared for desktop are often just... wow, wth? Way overboard. But, I like the idea that's slowly circulating around the web evangelistas... that if people are preferring your "mobile version" or using Readability plugin on your site, you have too much for "desktop" in the first place.

Getting heavily off-topic, but if you're building "mobile first" (or, simple basic everything-works-but-no-BS site) then layering desktop bloat^H^H^H erm "enhancements" on top... that should help avoid adding unnecessary desktop swill to mobiles and/or small screen.

Headers, though... If I've got them in the markup, they generally always show up on mobile/small screen. Mostly because I save most of the CSS hiding/showing/JS/CSShover stuff for larger screens, which may or may not hit iPads (I don't care) but is meant for people expecting traditional desktop stuff. And if the headers were there to assist in screen reader or low-css navigation, if they get hidden at all it's only on the "desktop" styles.

[deathshadow60]

Yup, just about every major screen reader lets you hit a quick key (usually "h") to move to the next header (or shift+h, previous header, or choose a number to reach next/prev header of a certain level... which is why the HTML5 let-sections-determine-header-levels might be a disaster). Header-based navigation is so, so nice in a screen reader.

Exactly -- that's what I meant above when I said "screen reader users usually just navigate headings" (or something to that effect)... hence why I set them to display:none as I have proper heading orders for them already.

Heck, most of the time the ID's the .jumpto/.skipto/accesskeys menus point to are right next to the headings... it's a method for keyboard navigation on browsers that don't support headings.

Which is what I assumed OP was asking about... and why the 'screen reader' part of it made little if any sense.

[Stomme poes]

hence why I set them to display:none as I have proper heading orders for them already.

Setting a header to display: none means it is not copied to the virtual buffer, is not read out, does not exist. Not all readers user virtual buffers but most of them honour display: none (except in special circumstances). Which removes the ability to use "h" keys. It also means then your reader announces the total number of headers on the page (on page load) it does not count them either.

However, abso-posing the things offscreen does not affect using "h" navigation (if an anchor is abso-po'd... that's a can of worms, some browsers keep them in the default tab index and other browsers (notably Opera) don't).

I think we're missing each other on this, since you brought up id's... because of Safari being a retard I don't reply on
<h? id="someID">Some header</h?>

I have
<h?>Some header</h?>

Both headers can be navigated with "h" (or whatever) but the first one can also be a skip link destination... but not in my code, because of Safari (as I mentioned earlier).

[deathshadow60]

You're still not understanding a word I'm saying -- you seem to keep thinking I'm talking about headings for the display:none, when I'm talking about a accesskeys/.skipto/.jumpto menu, which has ABSOLUTELY NOTHING TO DO WITH HEADINGS/HEADERS other than their being what screen readers use INSTEAD...

Ok, for example, code from 99% of what I've been writing the past two years

<div id="pageWrapper">

	<h1>
		Site Title
		<span></span>
	</h1>
	
	<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>

	<ul id="mainMenu">
		<li class="home"><a href="/" class="current">Home</a></li>
		<li class="news"><a href="/news">News</a></li>
		<li class="links"><a href="/links">Links</a></li>
	</ul>
	
	<hr />
	
	<div id="content">
	
		<h2>Latest News</h2>
		
		<div class="subSection">
			<h3>News Item Title</h3>
			<p>Some news item</p>
		<!-- .subSection --></div>
		
		<!-- news items repeat ad-nasueum -->
		
	<!-- #content --></div>
	
	<hr />
	
	<div id="sideBar">
	
		<h2>Featured items</h2>
		<p>Couple things you want to feature here</p>
		
		<h2>About Us</h2>
		<p>Quick about blurb here</p>
		
	<!-- #sideBar --></div>
	
	<hr />
	
	<div id="footer">
		Usual disclaimer garbage text nobody actually reads
	<!-- #footer --></div>
	
<!-- #pageWrapper --></div>

See how ol.jumpto links to the id's that are pretty much "next to" the start headings for a section anyways? .jumpto is the type of hidden accessibility menu being talked about here, which is NOT for screen readers. I don't mind them being hidden on screen readers BECAUSE I have proper heading tags in a logical order in the document.

hr,
.jumpTo {
	display:none; 
	/* 
		horizontal rules in my code are for non-screen/tv/projection users
		.jumpto menu is for accesskeys and CSS off users on small screen
		like blazer, or for small display like Opera Mobile and Mini's 
		"small screen" mode.
	*/
}

That's all I'm saying here. .jumpto/.skipto accessibility menus are for IN PAGE LINKS -- like to ID's or NAMES.

Which I think is where you got confused on the ID part. You do know href="#content" or href="#footer" will point at id="content" and id="footer" respectively, right?

Or are you still doing the 1997 style empty anchor nonsense for that? (Which there's ZERO reason to do once we stopped caring about Nyetscape 4)

[Stomme poes]

See how ol.jumpto links to the id's that are pretty much "next to" the start headings for a section anyways?

Ah. So you have nothing before that h1? or very little? The reason my skip links are usually the first or almost the first thing on a page... often page navigation is before the h1 on my pages, because the h1 is usually right before the content, who comes after site-border and nav stuff (that is, after what would be called role="banner" nowadays). This is how non-screen reader users skip the menu, because the skip links are in front of them.

Which I think is where you got confused on the ID part. You do know href="#content" or href="#footer" will point at id="content" and id="footer" respectively, right?

ONLY in SOME browsers.

Or are you still doing the 1997 style empty anchor nonsense for that? (Which there's ZERO reason to do once we stopped caring about Nyetscape 4)

SAFARI

Safari

Safari

Safari

Safari

Safari

Safari

Safari


Got that? Voice Over users are more likely to use Safari than another browser just as most Mac users in general are more likely to use Safari, and Safari DOES NOT move the keyboard focus to an id... ONLY visual focus, (which means only 2 things, and jack left town, hee hee :) when you're trying to avoid tabbing 500 times to get through a page.

You DO need something focusable... and form inputs would be retarded. So yeah, it's back to anchors, just without the names.

<a href="#myself" id="myself"> </a>

with or without a space, but if you want working in Saffy you must do this. href can't be # or you'll get page refresh... if it's #void I've discovered the page often jumps back up to the top, so I've made its href equal its own id (which is retarded but it works).