Page (and heading) structure conundrum

Accessibility
1

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… :confused:

2

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.

3

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.

4

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.

5

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.

6

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.

7

Thanks, Stomme. Much appreciated.

8

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.

9

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

10

read paragraph 6… the one starting “Though that really comes down to”

11

You were talking about title attributes at that point!

12

There’s more than one sentence… Literacy much? “display:none” is only IN the second sentence and all…

13

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

14

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

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.

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!

15

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.

16

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!

17

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.

18

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.

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.

19

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

20

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…