Why should we not skip levels (eg from H1 to H3)
Using the strict section-based interpretation, you'd do it something like this:
- Site Menu
- Main Categories
- In this Section
- Main Categories
- On the Proper Use of HTML Headings
- W3C's Specifications
- HTML 4.01
- WCAG 1.0
- HTML 4.01
- Interpretations
- Section Based
- Strict
- Loose
- Quirky
- Strict
- Importance Based
- Section Based
- W3C's Specifications
A less verbose but even less sympathetic approach would be to use three <h1>s:
- Main Categories
- In this Section
- On the Proper Use of HTML Headings
- W3C's Specifications
- HTML 4.01
- WCAG 1.0
- HTML 4.01
- Interpretations
- Section Based
- Strict
- Loose
- Quirky
- Strict
- Importance Based
- Section Based
- W3C's Specifications
Last edited by Ben Millard on 15 Mar 2007 09:40 pm; edited 2 times in total
Share: 
I'm uncertain about those examples because any software reading the page, AT or GoogleBot or whatever, won't be able to distinguish which of the h1 headings is the important one on the page - a human being can clearly tell that it's 'On the proper use of HTML headings'. I keep coming back to that idea of jumping to the first h1 in order to get to the page content. It's an idea I like, since it moves 'skip navigation' links from being implemented by the developer to being implemented by the user agent.
If the headings for the site navigation and the content are equally significant, then we need some other distinguishing feature in order to label the page content. And that feature, whatever it maybe (a class or an id, perhaps) needs to be implemented consistently across the web in order to be useful to AT and search engine bots. Or just user agents in general.
Yes, any web page can be split into sections and subsections. That doesn't mean that a single hierarchical tree is a natural structure for all web pages, however.
Share:
| eatyourgreens wrote: |
| If the headings for the site navigation and the content are equally significant, then we need some other distinguishing feature in order to label the page content. And that feature, whatever it maybe (a class or an id, perhaps) needs to be implemented consistently across the web in order to be useful to AT and search engine bots. Or just user agents in general. |
Simon Pieters
Share:
| zcorpan wrote: |
| That feature is <article> in HTML5... (and <nav> for the navigation section). |
This leads nicely to something that was bugging me about the issue: Headings for non-content areas are useful for now, but something of a hack overall.
As well as HTML5 having specific elements for these areas, if you look at the roles & ARIA work coming up, the non-content areas (navigation, footer etc.) should not need headings to identify them.
We do for now, and it's a useful discussion, but it's worth bearing in mind that we shouldn't have to worry about it for that much longer. (Well, maybe after 2011 or so?
Apologies if someone said this already, it's getting late and I am relying on Ben's excellent summary.
Share:
| Alastc wrote: |
| This leads nicely to something that was bugging me about the issue: Headings for non-content areas are useful for now, but something of a hack overall. |
| 'whatwg.org Web Applications 1.0' wrote: |
| 3.4.5.1.6. Class name "search"
The search class name indicates that the element's primary purpose is to provide the user with an interface to perform a search |
Looks like these issues are being addressed. HTML5 looks awesome, however I would still like to have clear guidelines for HTML 4 strict.Johan De Silva / Portfolio
Share:
If one takes a section-based interpretation, none of the specs limit headings to sections within the main content. Navigation, sidebars, search facilities and so forth are all fair game since they are logical sections of the document when taken as a whole.
Since my summary went down so well, I've written it up: Using HTML Heading Numbers. Feedback welcome!
(EDIT) Link updated. There is a redirect, so old links elsewhere still work.
Last edited by Ben Millard on 26 Jan 2008 12:56 pm; edited 1 time in total
Share:
| Cerbera wrote: |
| If one takes a section-based interpretation, none of the specs limit headings to sections within the main content. Navigation, sidebars, search facilities and so forth are all fair game since they are logical sections of the document when taken as a whole. |
Agreed, I just meant that the practice of using headings for non-content areas (e.g. navigation) should (in future) be superseded by other mechanisms. Why would you put a heading above the navigation if it had a role of 'nav' that people could get to and interpret more easily than using a heading?
Share:
Yeah, that might be nice. However, you could use a heading and apply a role attribute or a <nav> element (or all the above) if those approaches get standardised and implemented.
This would enable users to continue skipping around a document via the familiar heading navigation keys, whilst power users could use a "straight to navigation" shortcut when on websites which had the necessary markup. Handhelds might put the contents of <nav> elements in a collapsible overlay, so they are out of the way until the user needs them. Lots of potentially useful things.
If implemented well, I guess these structures would play well alongside each other. So how about using several at once?
Share:
The Using HTML Heading Numbers article is now at Project Cerbera. Site Surgeon is more or less derelict, so I'm gathering up the loose ends.
I went through it with a fine-toothed comb. It says the same things as before, hopefully. But now it uses fewer words and should be clearer.
(A few other articles have been given the same treatment and are in that section.)
Share: