In the default theme that comes with Drupal we have two menus that precede the main content in the source order. Right now we are discussing whether or not to place headings on those menus—so that all menus are preceded by heading. The problem of course is that the main h1 element then comes after h2.

I do not think it is feasible at this stage to alter the source order. The theme in is use on many thousands of websites and users often makes changes which means their sites could be break in the next update. Also the design makes source ordering this problematic. We cant just throw away this theme either, we are stuck with it for now.

So my question is this, is it better to provide these headings for menus, even though they are not hierarchically correct, or leave them out?

If we add them in we’ll have a heading structure like this for all internal pages (the homepage is different, where the site name is wrapped in the h1).

h2
h2
h1
h2
etc.

Thank-you.

I use them on Dutch pages where the owner wants to follow the hip and trendy “Home” for the home page, while plenty of older people aren’t sure what that is (and it gets pronounced “homeh” or “homa” for them, or they look for a word spelled “hoom” like Grandma wrote on a note to us recently), so I often have home links (but not other links) stating “hoofd pagina”. It’s a language thing, and eventually “Home” will just be an internet norm for Dutch pages. But it’s not there yet.
The only way I’ve been able to make JAWS take a pause after the titles is to actually add a “.” at the end.

I use them when doing image replacement on logos, who are also usually links to the home page. Usually the text behind it is “Company Name”, the anchor has no text at all but the title, mostly telling people that yes, this logo is following the convention of linking to the home page. What screen readers get is “Company Name link Home Page” (”link” being the reader itself, not my title text).

I use them on inputs where for whatever reason, a question in a form is not in a form control (and thus not read out). Visual users, even keyboarders, get the p or h3 or whatever the non-form-control is. I nipped this one from Juicy Studios.

I use them on anchors wrapping thumbnail images who have no alt text, stating “larger image” (in Dutch tho) as that’s the purpose of the link, and there is no link text. Keyboarders get the suck end of this, though on a repetitive page such as a shopping cart page, one time clicking on a thumb shows you exactly what all the rest of them do. A better way to do it would be to have text announcing this right before the thumbnails, but I can’t always afford to do this.

For CSS “image maps” (usually lists) I do not use title attribute, I’ll pull a span or something offscreen and have it appear just like a title on focus or hover, since I’m already adding anchors over the map. However, I’m not sure it’s worth the pile of extra CSS and the rigidity necessary to do this for other things people like to stick titles on (like links on plain old menus). Image maps can afford to be sized in pixels, since their image is sized in pixels. Menus however need to scale, as does regular body text and anchors.

Using tooltip spans in the middle of text has been done, although Opera had a nasty bug that appeared with that, if you scrolled the page or something. Not sure if that’s been fixed in 9.6, but it was in 9.5. Something to do with an absolutely positioned child span inside a relatively positioned inline element.

I have used title in forms for when a label is also a link to something (a larger page with further explanations, to open an Excel sheet, to open a PDF) back when I was forced to open those things in new windows (with the deprecated target atty) as the back-end could not always keep filled-in but not-yet-submitted information, and having someone click a supposedly “helpful” link, only to go back with the back button to find their browser isn’t caching (you can never count on people having brower caching on) prompted this. So the anchor had a title stating that the whatever opened in a new window (later I managed to change the PDFs to just opening the PDF reader, but I still kept the titles stating this was a link to a PDF). Using Javascript was not an option.
Luckily nowadays we can track people with sessions, no need for target, though they tend to miss folks like me because I don’t accept cookies (like many other web surfers. Still using titles on anchors to state the link is a pdf, along with a background image. Worst comes to worst, people clicking on it get prompted by their OS what they want to open this PDF with, which they can cancel and go back to the page.

I use tooltips regularly on icons, whether they are anchors or not. To this day, I remember my mother driving the car and saying “I wonder, what does the little flag in the water mean again and why is it glowing?” Thus, I usually turn images off where there are lots of icons so I can read them, but a tooltip often does the same job for me. It’s too helpful when you’re being dictated to by a stringent graphic designer and you cannot add any real text or there’s no room (the purpose of the icon in the first place). Keyboarders get the suck here too, but that isn’t going to stop me from trying to at least make it useful to SOME people. I hate icons.

I’ve avoided name attributes, from back when I thought I was writing XHTML (it’s not deprecated in 1.0 but it is after that, as “name” was reserved for other things) and it’s a habit that’s stuck. That and I don’t suppose names should never be read out, those are for internal use only (just like on form inputs).

That keyboarders can’t get tooltips on :focus is the fault of the browser vendors and I lay the blame at their feet. They’re so busy adding gee-whiz factors and trying to implement that HTML5 junk, while leaving other things in the back field.

My questions are a bit similar to the ones of Allard.

I watched the video on Youtube, read your article and visited the webpage of “A List Apart”. What I noticed from this website was that in their examples of html 5, they use H1 several times on the same page. Given that W3C speaks about “guidelines” and not “must-do’s” I suppose it’s all a bit about interpretation?
My question is: I just built a website in which I used H1 as the title of the main article/articles on the page (so on some pages I had more than one H1, especially on the home page that contains bits of several articles, a bit like in a blog). This website was tested by a man using a screen reader, and he said it was very comprehensible. However, semantically these H1s came after several h2 (titles of the navigation), so I suppose that’s not correct?
Why exactly is it necessary to use the title of the page in a H1, when this title is already stated in the “title” section of the head? Won’t it then be read out twice by the screen reader, one after the other, boring the user to bits?

Also, I noticed some developers use h2 for all the links. Is this correct, or is it better to use a h2 for the title of the navigation (and then hide it via CSS)?
It does seem a bit strange to me that the titles of the navigation bars is marked h2, and the the titles of articled are marked H3 (coming much later in the HTML code). Or should they be marked H2 aswell?

Thanks for you feedback, this is really helpful!

The problem, as you point out, is that users have control over which elements on the page are keyboard accessible. In Camino, for example, users can choose between “text fields”, “all form controls”, and “all form controls and links”. Since some users enable keyboard access for all text fields, form controls, and links, if a tabindex is to be used at all it must be applied to every one of these elements on the page. The only reason to do this would be to change the order in which these elements are accessed via the tab key. This can be better achieved by rearranging the source code.

<a href=”…” …>Read more<span style=”hide me off screen”> about XYZ</span></a>