Why should we not skip levels (eg from H1 to H3)
| W3C wrote: |
| The six heading elements, H1 through H6, denote section headings. Although the order and occurrence of headings is not constrained by the HTML DTD, documents should not skip levels (for example, from H1 to H3), as converting such documents to other representations is often problematic. |
People I have spoke too believe headings on a page should be consistent through out the website at the expense of missing out a heading number, as outline in my article aimed at designing for screen reader users but is clearly a fail of a check point...
Johan De Silva / Portfolio
Last edited by Johan007 on 13 Mar 2007 09:52 am; edited 1 time in total
The idea is that if you use the heading levels correctly, the more precise semantics enable the UA to handle the document sections more precisely.
For example, a search engine could use section headings to figure out the subjects covered by a document. Higher levels indicate the general subject covered by each major section with and lower headings for any specific aspects covered in sub-sections.
In a screen reader, navigating by headings could be enriched with level-specific features. For example, navigating only between a high level of heading could make skipping between the major parts of a document more easy.
Another aspect to consider is that using headings in an irregular way requires a user to learn this irregularity when they visit your site. If headings are used in a regular way they will likely be more consistent with other websites and therefore easier to learn.
For example, a search engine could use section headings to figure out the subjects covered by a document. Higher levels indicate the general subject covered by each major section with and lower headings for any specific aspects covered in sub-sections.
In a screen reader, navigating by headings could be enriched with level-specific features. For example, navigating only between a high level of heading could make skipping between the major parts of a document more easy.
Another aspect to consider is that using headings in an irregular way requires a user to learn this irregularity when they visit your site. If headings are used in a regular way they will likely be more consistent with other websites and therefore easier to learn.
If you skip headings then it probably indicates some problems in your information architecture, or you are making arbitrary decisions about document structure that are based on the visual representation of the document or both.
| terrence wood wrote: |
| are making arbitrary decisions about document structure that are based on the visual representation of the document or both. |
| Cerbera wrote: |
| Another aspect to consider is that using headings in an irregular way requires a user to learn this irregularity when they visit your site. If headings are used in a regular way they will likely be more consistent with other websites and therefore easier to learn. |
Johan De Silva / Portfolio
Sounds like you've already made up your mind about it.
| Cerbera wrote: |
| Sounds like you've already made up your mind about it. |
Johan De Silva / Portfolio
I'd be interested in seeing some concrete examples of inaccessibility here, too.
That WCAG guideline is aimed at the use of headings according their font size, as was the wont back in 1997 ie. <h2> being used instead of <h1>, in HTML 3, because <h1> was too big.
There's nothing in the HTML spec itself about <h2> etc. requiring a preceding <h1> so
is perfectly valid HTML. I guess the questions are, what issues (if any) does having <h3> precede <h1> cause assistive technology? And, even though valid, is this really best practice? If not, why not?
That WCAG guideline is aimed at the use of headings according their font size, as was the wont back in 1997 ie. <h2> being used instead of <h1>, in HTML 3, because <h1> was too big.
There's nothing in the HTML spec itself about <h2> etc. requiring a preceding <h1> so
| Code: |
| <h3>Not very important heading</h3>
<p>Not very important preamble, navigation and suchlike.</p> <h1>The most important heading</h1> <p>The meaty bits of the page. Phwoaaarrr!</p> |
is perfectly valid HTML. I guess the questions are, what issues (if any) does having <h3> precede <h1> cause assistive technology? And, even though valid, is this really best practice? If not, why not?
| eatyourgreens wrote: |
| That WCAG guideline is aimed at the use of headings according their font size, as was the wont back in 1997 ie. <h2> being used instead of <h1>, in HTML 3, because <h1> was too big. |
Mike Abbott
Accessible to everyone
| Mikea wrote: | ||
|
Precisely - but you couldn't prior to the introduction of CSS, which is where I think this guideline came from. There were a lot of pages on the web, ten years ago, using headings for their appearance, rather than meaning. People tended to avoid <h1> because it was big and ugly.
The issue for me has always boiled down to how the document structure stands up sans-css; a (sight-based) test being how the same information structure might be presented in a css-less, printed document.
For this reason, I believe the only correct architecture is to have the headings appear in order and in a tree fashion, with a single h1 and other, lesser headings descending from that - i.e. as the W3C describe it in the quoted passage in Johan's opening post.
Imo, there is rarely, if ever, good reason to skip numbers as headings are relative.
Devising the info architecture should be the first part of a project and that should pretty much be locked down before that content is then built into a particular platform (e.g. print, web, etc...).
The platform should not require any changes to the underlying info architecture, but should be formed by it.
The fact that non-sequential headings are valid is absolutely irrelevant, imho. There are a great many things which can be done which are valid, but which few would argue are 'the right way'.
Using headings non-sequentially, including skipping headings in a sequence 'breaks' the info architecture model.
(This is why I've also never endorsed practices such as placing the page's main content - the meat of the page - before all other in-document information.)
For this reason, I believe the only correct architecture is to have the headings appear in order and in a tree fashion, with a single h1 and other, lesser headings descending from that - i.e. as the W3C describe it in the quoted passage in Johan's opening post.
Imo, there is rarely, if ever, good reason to skip numbers as headings are relative.
Devising the info architecture should be the first part of a project and that should pretty much be locked down before that content is then built into a particular platform (e.g. print, web, etc...).
The platform should not require any changes to the underlying info architecture, but should be formed by it.
The fact that non-sequential headings are valid is absolutely irrelevant, imho. There are a great many things which can be done which are valid, but which few would argue are 'the right way'.
Using headings non-sequentially, including skipping headings in a sequence 'breaks' the info architecture model.
(This is why I've also never endorsed practices such as placing the page's main content - the meat of the page - before all other in-document information.)
| Bill Posters wrote: |
| The platform should not require any changes to the underlying info architecture, but should be formed by it. |
Johan De Silva / Portfolio
| Bill Posters wrote: |
| (This is why I've also never endorsed practices such as placing the page's main content - the meat of the page - before all other in-document information.) |
This is a usability decision rather than info architecture though? I don't think we ought to be presenting information the same sans-css, but in a way most appropriate to how it is being viewed - be that browser with css turned off, screen reader, mobile, etc.
Being able to re-order the content with CSS is necessary to make the headings and other information semantically correct - otherwise your interface design has to be led by the information rather than the users needs.
| Bill Posters wrote: |
|
For this reason, I believe the only correct architecture is to have the headings appear in order and in a tree fashion, with a single h1 and other, lesser headings descending from that - i.e. as the W3C describe it in the quoted passage in Johan's opening post. Imo, there is rarely, if ever, good reason to skip numbers as headings are relative. |
Slightly trainspottery and pedantic point here - W3C says you can have more than one <h1> on a page. All that's required to satisfy the WCAG guidelines is that the <h?> tags are nested in order.
The W3C explanation of headings in HTML is remarkably woolly, but says nesting headings is optional.
So I guess, rephrasing my question, what's the barrier to access by disabled people which is addressed by this guideline? Because it seems sensible advice, but there doesn't seem to be anything out there about incorrectly nested headings causing an access problem.
| twoplayer wrote: | ||
This is a usability decision rather than info architecture though? |
In most cases, it was done in the questionable belief that it aided a site's results in the serps.
In fewer cases, it's done with a view to assisting those using AT to view the web page.
Neither reason is sufficient to disrupt the natural hierarchy of information, imo.
| Quote: |
| I don't think we ought to be presenting information the same sans-css, but in a way most appropriate to how it is being viewed - be that browser with css turned off, screen reader, mobile, etc. |
I disagree. Information is information is information and people are people are people. There's nothing about a particular platform which necessarily dictates that its users will naturally prefer to receive that information out of its natural order.
As we can't guarantee how that content is going to be viewed - in a gui browser, a text reader, a print out - one structure generally has to be used.
We can, through technology, omit or include portions which have no relevance to a particular platform (e.g. a print outs can make no use of navigation), but that which is left should follow the order and hierarchy set out in the original info architecture stage.
| Quote: |
| Being able to re-order the content with CSS is necessary to make the headings and other information semantically correct - otherwise your interface design has to be led by the information rather than the users needs. |
The users' need is to get at the information. When that information follows a meaningful hierarchy, it's easier to scan, traverse and use.
CSS is not necessary to reorder content in the name of semantics. CSS has no hand in semantics. The underlying markup can and should be devised before consideration is given to CSS/the presentation layer.
...imo, of course.
| Bill Posters wrote: |
| CSS is not necessary to reorder content in the name of semantics. CSS has no hand in semantics. The underlying markup can and should be devised before consideration is given to CSS/the presentation layer. |
An example might help my point. Say I have a two column site - the <h1> is in the second column (the main part of the page). Then I want to put contact info or something relatively important in the left-hand column. It's could be a good idea to give that a <h2> like "Contact Information" so that people are able to skip to it or find it in a consistent place on my pages.
I could use CSS to place the main content before the left-hand, or I could settle for the semantically incorrect <h2> followed by the <h1>. The only other choice I have is to design the page so that nothing of importance precedes the <h1> (in the code).
I'd go for the well structured information with CSS to position it every time. IMO obviously ;)
Interesting one though. I think it's a case of the guidelines being sketchy/out of date. There were barriers at the time the guidelines were written because most sites didn't use headings or semantic mark-up. WCAG 2 says this is about the time it takes somebody using assistive technology to jump directly through the content - but still doesn't offer enough in terms of techniques.



