Page (and heading) structure conundrum

Accessibility
21

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.

22

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.

23

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).

24

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)

25

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 :slight_smile: 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).

26

You have an obnoxious attitude. Do you respond to everyone like that, including fellow pros, colleagues, and clients; or is it just an attitude that is reserved for hobbyists and novices? Way to put people off asking questions.

To answer your question: it is primarily about figuring out how to position the H1 in visual relation to the content division in which it currently resides, if it ends up not actually being in there. Such things as this are still open to development. It should be in there, to my mind. I don’t want two navigation lists in between the H1 and its sub-heading: that just seems odd and messy. And I hate messy.

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.

In the case of the main nav list, it is a way to conveniently/reliably position a list AND a heading together in a particular part of the page. Which is to the left of the content in this case, as I already mentioned. If I don’t use a heading above the main nav, then I won’t need to use the div and I might remove it.

In the case of the skip links list, the div contains, or will eventually contain, a logo and/or website title. Again, it might be removed later if the design doesn’t need it. But at the end of the day, if I want to use a div, I will.

Don’t assume. If you were not sure what I meant, you could have taken the time to ask.

27

Stomme poes: you mentioned that only some browsers can use links that point to IDs. Can you elaborate a bit about that? I thought that all browsers can do this. The ones that I’ve tried so far can.

28

Don’t take it personally… DS deals with everyone on the forum in the same way unfortunately!

29

Yes, I’ve noticed. Sitepoint is too soft on that kind of thing.

30

Stomme poes: you mentioned that only some browsers can use links that point to IDs. Can you elaborate a bit about that? I thought that all browsers can do this. The ones that I’ve tried so far can.

Safari. Try it. If you have Windows, Safari-for-Windows is the same.
The visual focus will move!
But the next “tab” you make will have you starting back where you were, not where you skipped to.
This actually kinda makes sense. How do other browsers bring focus “down” somewhere on a page when there’s no element for that browser to focus on? But somehow most browsers get it right. Safari doesn’t.

Arg, I can’t find the WebAim PDF, it’s somewhere on their site: they have a WWF smackdown-style comparison of some screen readers. They have VoiceOver failing skip links, but it’s really because of Safari, not VO.

31

Thanks, Stomme poes. I haven’t tested Safari yet (mostly because I installed it once, hated it as a browser, and promptly got rid of it). Regarding the Voice Over skiplink issue: is that anything to do with specifying a height of 0? Hiding Content for Accessibility - Snook.ca mentions that.

32

I’m trying to wrap my head around what you are saying, and failing MISERABLY; what the devil does tabbing around have to do with hash-links… tabs are for anchors and form elements, not going between on-page ID’s…

OH, you’re calling something I consider annoying (empty anchors showing up in the tab list) a feature… That’s one of the reasons I don’t use empty anchors anymore as they aren’t something I want recieving focus!

The behavior you are describing I think is present in EVERY browser too, not just Safari. ID’s can’t recieve focus, and just act as a scrollto – that’s WHY I use them!

I think that’s why I was having trouble understanding your last two posts - I kept thinking “why the devil would you WANT them to recieve focus? How does a DIV or H# even RECEIVE focus?!?”

That sounds handy - I’d like to see that.

33
Off Topic:

I think it’s a regionalism – several years ago I was working in an office where a little granola Californian started working as a secretary, and she started screaming at everyone “you can’t talk to people like this” — we were all staring at each-other like she had five heads. “Like what?”

Depends on how you are used to business being done – It’s like when people start flaming on what *** Simon Cowell or Gordon Ramsey are; when to me they act like every professional businessmen I’ve ever dealt with in New England.

While when I went to work in Georgia for six months it was like oil and vinegar. Ok, oil vs. piss and vinegar. Everyone had this bizarre “status quo for the win” lackadaisical attitude where it was forbidden to say anything negative EVER – of course that’s why the company I worked for kept rotating people from up north through that office… I was the fourth person sent down and when the boss got back a report that I was “shaking things up too much” I told him on a conference call “Look, just shut down this entire office or replace EVERYONE with staff from up there. We can’t get anyone here to show the work ethic we do up there.”

I was taught you see something bad, you call it bad - “if you can’t say anything nice” being a cop-out for thin-skinned lazy people who are afraid of progress, or those who as Ghandi would put it “to put on the cloak of nonviolence to cover impotence.”

Having traveled the world, I’ve seen it all over the place – an attitude that’s acceptable in New England will get you slapped in Florida. An attitude that’s acceptable in California will get you bullied in the midwest. An attitude that’s acceptable in western Europe will get your face punched in on the streets of NY. <brooklyn>Ya got a freaking problem with that</brooklyn> :rofl:

Just consider my posts the equivalent of “Ya cahnt geht theyah frum heeyah”. It’s a proud tradition…
We’re starting a war, we’re going to have to offend SOMEBODY! – John Adams.

Well, that and it seems NOBODY has a sense of humor anymore.

34

That sounds handy - I’d like to see that.

I didn’t find it terribly informative… I think they made it for fun or something. Someone really wanted to have a PDF about screen readers and “wrestlers”, lawlz. Anyway, the skip links section just says VoiceOver is a steaming pile of fail… but let’s see it in Firefox on a Mac. Yeah, should have magically no problem with skip links then.

http://webaim.org/presentations/2011/csun/srfaceoff/srfaceoff.pdf

That’s one of the reasons I don’t use empty anchors anymore as they aren’t something I want recieving focus!

You remove it from your page’s regular tab index by adding a tabindex of -1 to it. Simple. Now you’re not stopped by annoying empty anchors if you’re just moving straight through the page because they are no longer part of the page’s tab index.

I think that’s why I was having trouble understanding your last two posts - I kept thinking “why the devil would you WANT them to recieve focus? How does a DIV or H# even RECEIVE focus?!?”

The point isn’t for them to receive focus; the point is that your keyboard focus is no longer at the top, but in the area where you want to go (and the area you’re looking at if you jumped way down the page). After clicking a skip link, I want the next time I hit “tab” to take me to the next available anchor or form control, not remain at the top of the page.

The behavior you are describing I think is present in EVERY browser too, not just Safari. ID’s can’t recieve focus, and just act as a scrollto –

If that’s all it does is visually scroll the page then it’s worthless for actually moving your focus around the page. Luckily, IE, FF and Opera will move your focus (you use Opera, so you get this benefit if the links weren’t set off-screen… with Shift+arrow instead of Tab but whatever). If I want to select a link, I don’t want to tab (or Shift-down) 500 times. I want a skip link to take my focus away from the top of the page down to where I’m interested.

Chrome and Safari make your next “Tab” bring you back UP to where the skip link is (focus remained there all along and your next Tab is the next focusable thing after your skip link). If your skip link goes to a focusable destination though, then your next Tab will take you to the next focusable thing from where you skipped to, like all other browsers do.

If I want to scroll the page visually, I use arrows or pagedown… or most common, /searchterm or CTRL-F searchterm. Hitting “tab” from there doesn’t take me to the next focusable thing after my search term… it takes me back to where my focus was before I searched.

So sorry, I had just web back to check on Chrome because I’d forgotten if this was a Safari thing or a webkit thing… well, it’s a webkit thing because Epiphany does it too.

So webkit browsers have this issue.

And apparently some people are using Javascript to fix this which is just… ew.

35

Okay now I’m pissed, because I was SURE I had the things working in Safari on my older pages by having a focusable destination. Now I’m not seeing that anywhere.

Time to dig through my old code and find the last one who worked… cause I’m really not keen on Javascripting something that should Just Work in browsers.

36

Not something I’d bother with in the first place – I’ve always thought of hash links as being like hitting page down. I don’t complaint when normal scrolling with page-up/page-down or the mouse wheel doesn’t change the focus… tap and drag doesn’t change focus… normal arrow scrolling using the d-pad on a phone doesn’t change focus…

Wouldn’t even occur to me as a way to navigate a page.

37

Crusty:
I also ran across Opera documentation mentioning that you can header-navigate with it too: s and w I think?

38

I am a web developer but not too good in seo. But i know one thing H1 only use for your main site keyword. and 99% it will be on top of the page like logo and main header text. and use h2 or h3 for other page headings.