I completely disagree. You break up your webpages, they stand alone as documents. You reference them separately.

The header, footer, and nav is not the cover of the magazine. They are the little bits of text on the top and bottom of each page to denote the magazine title, the section title, the page number, et al.

These elements are not relevant while reading the magazine article they surround. Similarly, they do not have weight in regards to the primary content of the webpage. They are merely context, and ways to get to other pages. In a magazine, you can always turn the page, flip back to the table of contents, or close it to look a the cover.

There’s always another level to present as a document. An article. All articles in the magazine. The entire magazine issue (with editor’s note et al). All magazine issues. The magazine as a collection. The magazine as an organization.

However, in all these levels, it is very clear what is primary and what is secondary or contextual.

If you have a whole book on one page, the book title is h1, table of contents is h2, sections are h2, chapters are h3, index is h2. It makes even more sense if you think about a textbook instead of a novel. Logical groupings multiple hierarchical levels to break up info.

If a book is split by parts (sections, chapters, et al), then you can present each part as a separate page, with references to the other parts and the book as a whole.

The christian bible is another good example, with the chapter and verse structure. Specific verses are often referenced specifically, so it is reasonable that they may exist on their own webpages to facilitate (h1 is chapter:verse). However, of course they may be viewable in context with the chapter as a whole on a single webpage (h1 is chapter). Further, the entire book may be presented as a whole (please don’t) to facilitate download or offline reading.

To use a popular web example: a blog. A blog may be a webpage (h1 is blog title), to show articles sorted by recent first (article titles are h2). Obviously each blog article is it’s own webpage (h1 is article title), with list of comments. If comments are to be referenced alone (as with a forum, a reply is merely a post with a parent), then a comment may be granted an h2 and a link, given that it may be an h1 on its own webpage.

Daunting…but great article. Not sold yet, but we’ll see how the consensus plays out.

[quote]
I think that is exactly the problem – people keep confusing the document information hierarchy of H1-H6 with the DOM hierarchy of nodes. Your document should make sense as a web page and as a printed page. No?
[/quote]

My turn to rant.

I don’t think a web page is a document. A web page *contains* a document, in the context of header, navigation, footer etc. Or more than one document. Just like a printed document is rarely just a document. It’s within a journal, magazine, or whatever.

I can have a properly structured article – the main content of the page – with proper h1 – h6 headings. But then I’m in a quandary of how to structure the other areas, and land up with h2s before the h1; missing heading levels on some pages where a bit of the header is not logically needed; etc. This aspect of a web page structure often seems to be glossed over in these discussions on heading structure

So, I’d be happy to have the scopes of article, header, footer, navigation etc, each to have their own heading structure.

And futhermore I think Cory is right. Modern web pages are dynamic, grabbing bits of content from all over. To eshew this because it doesn’t fit into the “a web page is a single document” model would be to be left behind.

I s’pose this boils down to how the markup of web pages develop. It would be lovely to predefine it accessibly, and say what web pages should be like. But that’s not and never will be the real webby world. It’s just not the nature of the web. It’s nature is what can be coaxed, wrenched or stuffed into a web page by developers doing things they’re “not supposed to do”, regardless of accessibility. They become the standard that businesses aspire to. This drives developments, for good or bad.

Perhaps the best we can do is influence this process, and figure how to make structure it accessibly.

Dynamically constructed pages are here to stay. HTML5 heading structure might just provide the solution for accessibility and access technology to cope with today’s web pages by allowing a web page to be logically structured, albeit recursively, while accommodating at least to some degree modern web page design.

Until the next development, that is.

If you check the outline of an HTML5 document you’ll notice that the logo’s only logical place is to be at the top level of that outline / DOM tree. If you omit assigning an tag to the logo, you’ll most likely get an “Untitled section” somewhere, anyway. That’s not cool.

Sorry but it’s logo on the top level for me.