Why should we not skip levels (eg from H1 to H3)
meyer's article on headings is quite interesting
pick a heading
Share: 
Good article! I think Faruk Ates pretty much sums up my opinion on this:
| Quote: |
| I personally think that a descending-order hierarchy is not a bad thing at all, but lacking elements such as section for the time being, they impose too many restrictions and get in the way of sensible document linearization. |
At least, I think by forcing pages into a single descending-order hierarchy, I've created some pages where the heading hierarchy doesn't really describe the structure of the page.
Share:
| meyer's 'pick a heading' article wrote: |
| Here’s the markup skeleton for the first part of the home page as I set it up (the actual markup as of your reading this may be different):
<h1> <a href=”/” target=”_top”><span>Netscape</span> DevEdge</a> </h1> <form action=”/search/app/” id=”srch” method=”get”> <h4><label for=”search-input”>Search</label></h4> (…inputs…) </form> <h2>Netscape 7.1 is now available</h2> (…paragraph text…) <h2>The DevEdge RSS-News Ticker Toolbar</h2> (…paragraph text…) <h3>Recent News</h3> (…list of links…) |
| meyer's 'pick a heading' article wrote: |
| So we weren’t about to move the search markup just to make its heading level fit into a descending-number hierarchy. |
My mind changes about the whole issue and currently I am back to believing my original article unless I can physically see a problem with missing out an heading, I believe...
1. Content should start with H1 (but logo for the homepage)
2. Site search should be given a consistent heading for large sites even if it means skipping headings.
Johan De Silva / Portfolio
Last edited by Johan007 on 14 Mar 2007 09:35 pm; edited 1 time in total
Share:
The W3C should have avoided numbers when devising the markup for heading. There is a tendency to equate the number with how 'important' the content is (see Meyers article). I don't subscribe to this thinking. The number just indicates that the content following a heading 'belongs' with the content that precedes it or if it indicates a change in topic.
| Johan007 wrote: |
| structural labels [is] Exactly what I was getting at but for this technique to work it would not make sense to mark up with H1 and H2’s demoting the content to a lower heading. Putting Structural Labels as lower heading such as <h6> would be perfect if was not for the fact it fails W3C. |
I think you are missing the point. <h(n)> is fine for your search form (where n=6, if you wish), all it needs is to be preceded by <h (n-1)>. Therefore, put your search form in the source order somewhere following <h(n-1)>. There is no need to demote your content - there is a need to move your search box.
To illustrate: I've used the same basic source order for the past 5 years or so where the visual design is your typical header, 2 or 3 cols, footer. I prefer a 'reverse' source order because it tests well with screen reader users (and mobiles), removes the need to reinvent the wheel each time your content needs change, and it works regardless of the design you put on top of it - just add/subtract a couple of containers depending on the visual designs needs.
1. skip links - 'main content', 'links in 'section name' (optional), 'site menu' - <ul> not preceded by a heading
2. Site Branding - plain text - why waste my best heading?
3. Content title - <h1>, followed by <h2> subs, and <h3> sub-sub-headings as required.
4. Site menu - <h2>
5. Current section: Section name - <h3> (links in 'section name')
6. Main sections - <h3> (links to main sections)
7. Search and help - <h3> (search form, sitemap, privacy, accessibility etc)
This structure makes no claim about how important each piece of information is. Simply, it succeeds in grouping related content together.
Share:
| terrence wood wrote: |
| The W3C should have avoided numbers when devising the markup for heading. There is a tendency to equate the number with how 'important' the content is (see Meyers article). |
I guess that's because of the way h1-h6 are defined in HTML 4:
| W3C wrote: |
| A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.
There are six levels of headings in HTML with H1 as the most important and H6 as the least. Visual browsers usually render more important headings in larger fonts than less important ones. |
from http://www.w3.org/TR/html401/struct/global.html#h-7.5.5 Eric Meyer quotes that part of the spec also, by the way.
As someone else pointed out, the hierarchy idea for headings works fine for technical manuals and scientific papers. I imagine it may be an idea that came into HTML from TeX, which creates very structured, hierarchical documents?
Share:
| eatyourgreens wrote: |
| I guess that's because of the way h1-h6 are defined in HTML 4 |
I see your point. I'd always thought that W3C were indicating which way the headings run, not that content following <hn> was of the same weight / value / significance as other content appearing under the same <hn>. Such a literal interpretation doesn't really gel with the idea of headings equating to a table of contents does it?
Share:
| terrence wood wrote: | ||
I see your point. I'd always thought that W3C were indicating which way the headings run, not that content following <hn> was of the same weight / value / significance as other content appearing under the same <hn>. Such a literal interpretation doesn't really gel with the idea of headings equating to a table of contents does it? |
I think it makes sense if you remember that HTML was put together by a bunch of geeks who were used to marking up scientific papers in LaTeX. The table of contents for a TeX document is automatically generated, from the nested section headings. Problem is, that thinking might only apply to a limited set of all the possible types of document on the web.
There used to be a Dreamweaver plugin that generated a table of contents from page headings. I've written something similar to work with our CMS, inserting a table of contents when the page is requested - a document's read from the CMS, a list of headings is extracted, turned into links to the <h?> elements, then inserted after the main heading as a <ul>. So I'm not sure what you mean by the idea not really gelling with a table of contents? Following the HTML spec, I guess you would generate a table of contents of the main sections of a HTML document by listing all the <h1>s, for example.
Share:
| eatyourgreens wrote: |
| I'm not sure what you mean by the idea not really gelling with a table of contents? |
| Eric Meyer wrote: |
|
Meanwhile, in the sidebar, the section headings (such as “Distractions”) are enclosed in h4 elements. That makes them as important as entry headings, and I’m okay with that. |
Meyer clearly sees his sidebar content as less 'important' (having less significance) than his blog entries and sees it as neccessary to apologise (or not) for marking up subsections with different 'importance' using the same heading level.
My point is that "A table of contents" - a possible UA's use of headings - outlines a document. Headings are created based on how much the content follows on or changes the topic from the content that precedes it. It has nothing to do with the notion that content following a heading and nested at a particular level should be as significant to the document as content nested at the same heading level elsewhere in document.
Phew - that's a mouthful, I've tried to be as clear as possible, but let me try to illustrate my point.
Meyers document outline (TOC) may look something like:
Blog Entries
..Entry 1
..Entry 2
..Entry n
Sidebar (probably missing)
..Distractions
..etc
Clearly, I can see the structure - I can see that 'Distractions' is a subsection of 'Sidebar' and that 'Sidebar' is a different section from 'Blog Entries' - It doesn't matter that 'Entry 1' and 'Distractions' are nested at the same heading level (and use the same <hn>), what does matter is how they relate to the heading that precedes them.
In fact, the document outline would make little sense if we used a Meyeresque interpretation of the spec and use of 'important':
Blog Entries
..Entry 1
..Entry 2
....Sidebar
......Distractions
I doubt this is what W3C meant in the spec when they say h6 is less important than h1. Maybe they mean you must have an <h1>, you should have <h2>'s and you may have <h4> - <h6>? Or perhaps they just mean prominent or large?
Share:
There's a note in the spec that adds
| Quote: |
| HTML does not itself cause section numbers to be generated from headings. This facility may be offered by user agents, however. Soon, style sheet languages such as CSS will allow authors to control the generation of section numbers (handy for forward references in printed documents, as in "See section 7.2").
Some people consider skipping heading levels to be bad practice. They accept H1 H2 H1 while they do not accept H1 H3 H1 since the heading level H2 is skipped. |
so I think they do mean that the number has something to do with how significant the heading is. I mean, they're allowing h3 after h1, presumably if that heading isn't significant enough to warrant h2? On the other hand, as pointed out, their clever CSS section number generator won't work if there isn't some sort of structure to the headings. So to start a new section you'd have to go back to a higher level of heading tag.
Without any examples, though, it's left up to us to guess what the actual intention of the spec is. The elephant example that they give uses LaTeX-style section and subsection markup (the divs), which isn't very helpful beyond implying that heading levels do nest hierarchically after all. Despite the fact that they say that this isn't necessarily the case. It's all very confusing.
I've been thinking with pages like the NHSC articles that marking up the article heading with h1, but the navigation banner and 'In this Section' with h2 or h3 would make sense. It would indicate to a screenreader, or google, that these items are less important and can be skipped by people wanting to go straight to the page content. Or given lower priority by search engines, which want to index the content but maybe not the navigation links.
Share:
| eatyourgreens wrote: |
| I've been thinking with pages like the NHSC articles that marking up the article heading with h1, but the navigation banner and 'In this Section' with h2 or h3 would make sense. It would indicate to a screenreader, or google, that these items are less important and can be skipped by people wanting to go straight to the page content. Or given lower priority by search engines, which want to index the content but maybe not the navigation links. |
| Code: |
| <h1>MTB102, Summer 2004 and D DAY 60. A Trip in the Life Of 102.</h1> |
Johan De Silva / Portfolio
Share:
Sorry to sort of hijack this post
But after reading meyers article (and several others)
Can someone clarify
Is this a definition of skipping a heading level?
| Code: |
|
<h2>Some info</h2> <h3>Heading 3</h3> <h1>main content title</h1> <h2>heading 2</h2> |
They are in order, but I'm not starting with an <h1>. It obviously validates but would it break
3.5 Use header elements to convey document structure and use them according to specification
?
Considering the WAI own site does this very same thing:
http://www.w3.org/WAI/
After reading tons and tons of discussions on this subject and feel i'm getting more and more confused with interpreting the spec. (as are many other like me I imagine!)
Share:
| phiger wrote: | ||
Is this a definition of skipping a heading level?
|
Johan De Silva / Portfolio
Share:
So this:
| Code: |
|
<h2>Some info</h2> <h3>Heading 3</h3> <h1>main content title</h1> <h2>heading 2</h2> |
wouldn't get flagged as a priority 2 warning (in most cases)?
3.5 Use header elements to convey document structure and use them according to specification
sorry to hark on.. i've been discussing this issue at work for the past 2 months or so.
Share:
| phiger wrote: | ||
So this:
wouldn't get flagged as a priority 2 warning (in most cases)? 3.5 Use header elements to convey document structure and use them according to specification sorry to hark on.. i've been discussing this issue at work for the past 2 months or so. |
An automated checker might fail that for missing an h1, but it does use h1, h2 and h3 'according to specification'.
The real test would be to find out whether it makes the page easier, or harder, to use by a disabled user. If the former, then you could argue that you're making a reasonable effort to make the page accessible to disabled users. In which case, does dogmatic adherence to the WCAG guideline really matter? Spirit of the law vs. letter of the law, if you see what I mean.
Share:
| eatyourgreens wrote: | ||||
An automated checker might fail that for missing an h1, but it does use h2 and h3 'according to specification'. The real test would be to find out whether it makes the page easier, or harder, to use by a disabled user. If the former, then you could argue that you're making a reasonable effort to make the page accessible to disabled users. In which case, does dogmatic adherence to the WCAG guideline really matter? Spirit of the law vs. letter of the law, if you see what I mean. |
yes.. this is exactly my point. i have tested our site template with numerous users (JAWS, partially sighted, students) and the headings are beneficial.
The problem is that some people think we are not strictly adhering to the AA policy as this is the checkpoint we fail on. ( we use the same method as the WAI actually.. 1st heading encountered is h2, but the main topic of the page is a heading 1 (further down the page) but we don't skip headings strictly)
Again.. i know it's all down to interpretation. But it's very annoying when questioned about this and people point to automated checkers and don't actually understand the 'real' issues and that is users.
Share: