sections have <h> element, like xhtml 2?

[matt clark]

I notice html 5 has a section element, but does it have a <h> tag, as xhtml 2 does, which "knows" what level it is from its position in the hierarchy.

I love this feature, as it means (for example) that I can write a blog post which goes in the database with its main heading wrapped in <h>I love halibut</h>. On one page, this might be the top-most heading, contained in only one <section> and thus analogous to an <h1>.

In an archive page, I might have a deeper section nesting:

<section>
<h>Archives for last year</h>
<section>
<h>I love halibut</h>
</section>
</section>

in which case, it's analogous to an h2 and maybe styled differently e.g.

section h {color:red;}
section section h {color:green}

Is such a construct proposed?

[zcorpan]

I notice html 5 has a section element, but does it have a <h> tag, as xhtml 2 does, which "knows" what level it is from its position in the hierarchy.

Yes, although it isn't called <h> it's called any of <h1> to <h6>. If you use sectioning elements and you don't care about the document outline degrading gracefully in legacy UAs then you can use <h1> for all your headings. See http://www.whatwg.org/specs/web-apps/cu ... #headings0

[matt clark]

Thanks.
Reading the spec now, I can see that it means as you describe - but it's pretty difficult to understand it.

My gut feeling initially was that, if everything is a <h1> then semantics and document hierarchy has gone to the wall - but I guess the rationale was that each <h1> is the primary heading *within that section* - and can be styled

section h1 {color:blue;}
section section h1 {color:purple;}

What's the reason for not choosing a hierarchically neutral element name (like <h>?), out of interest?

[wgabrie]

The <heading> tag is a "section" not just a heading.

Code: Select all

<heading>
<h1>Introduction to the Solar System</h1>
<h2>Learn about the inner planets</h2>
</heading>

[zcorpan]

What's the reason for not choosing a hierarchically neutral element name (like <h>?), out of interest?

It wouldn't be backwards compatible with legacy UAs. At least if you use H1 for all your headings, legacy UAs know that it is a heading, just not which level. If this is still a concern (which would be understandable) you are free to use the other heading elements so that it would degrade completely in legacy UAs.

[anne]

FWIW: <h> is <h1> and there's no <heading> element. I think you mean <header>.

[legendscrolls]

I notice html 5 has a section element, but does it have a <h> tag, as xhtml 2 does, which "knows" what level it is from its position in the hierarchy.

Yes, although it isn't called <h> it's called any of <h1> to <h6>. If you use sectioning elements and you don't care about the document outline degrading gracefully in legacy UAs then you can use <h1> for all your headings. See http://www.whatwg.org/specs/web-apps/cu ... #headings0

From my experience some web browsers such as WebbIE prefix 'Page Headline: ' to all <h1>'s which would certainly be very annoying for those with visual disabilities and using such text-based browsers with speech software listening to 'Page Headline: ' everywhere a <h1> is used.

I would suggest authors either use one <h1> for the very first heading of a document and then use <h2> (as the highest ranking, not-make-a-fuss heading) for all other headings or use <h2> for absolutely all headings instead of all <h1>s.
This would be practical accessibility.

[zcorpan]

From my experience some web browsers such as WebbIE prefix 'Page Headline: ' to all <h1>'s

Interesting. This doesn't sound very useful to me, and I can imagine that it doesn't work well with real Web pages even today. Perhaps they should consider changing their implementation.

which would certainly be very annoying for those with visual disabilities and using such text-based browsers with speech software listening to 'Page Headline: ' everywhere a <h1> is used.

Indeed.

I would suggest authors either use one <h1> for the very first heading of a document and then use <h2> (as the highest ranking, not-make-a-fuss heading) for all other headings or use <h2> for absolutely all headings instead of all <h1>s.
This would be practical accessibility.

I agree.

http://lists.whatwg.org/pipermail/whatw ... 13577.html

I've also reported this problem to WebbIE.

[alasdair]

I'm Alasdair King, the WebbIE developer. Thank-you very much for contacting me. I've been reading your HTML5 proposals with great interest.

Right, WebbIE's headline handling works thus:
1 Check page for any H1 elements. If found, mark them with "Page Headline:" and stop.
2 Check page for any H2 elements. If found, mark them with "Page Headline:" and stop.
3 Check page for any H3 elements .... et cetera.

The user can press a hotkey to go to the (next) headline after the page loads. The headline is selected so most screenreaders will read the headline text.

This is based on the following thinking: the biggest problem for blind people is getting an idea of the page content - that is, knowing where to start reading and getting there. That's the benefit of headlines: they are usually located just before the page content, after the navigation bars, so if you find one then that is a good place to start reading. In practice, few sites use them, and those that do often use them wrongly (e.g. for visual effect, or not reflecting real semantic structure), and developers don't agree with what using them right would entail anyway (should you always have an H1? Should it be first?) which limits their general usefulness.

So my use case is:
Blind user arrives at website. They get the page TITLE element content first, because that's more useful as a high-level summary than the Hx contents.
The user now wants to do what a sighted user does when they hit a page: scan around to find the content of interest, ignoring the advertising bars and navigation bars and legal notices, and reading a bit to find out if the page is relevant or if they should hit back and return to their Google results. Sighted people do this by scanning: blind people have to explore the page and listen to bits of it, which is very much slower.

And my requirements are:
Allow a blind user to get to where the real page content starts as quickly as possible, just like a sighted person can (for the HCI people: keep the task profile similar).

And my design is:
Some pages have elements that indicate the start of content: H1-H6 are used for this, but not often and not consistently. So provide a shortcut key to let the user skip to the first, highest-level one found.

Criticisms:

1 The presence of a headline isn't announced: the user has to hit the shortcut key. If skipping to a headline is so useful, then why not move the user straight to the headline every time a new page is loaded?
Response: Because then, on some pages, the user will be flicked down to halfway down the page, missing the useful title element content: and on pages that are misusing the headline elements there will be no sense in the destination. And it'll be more code and more complexity, and that's bad.

2 This loses the semantic differences between the levels of headline and misses the opportunity for the user to use headlines to better understand the page structure, like having a function that displays a tree or list of headlines.
Response 1: This isn't the use case I'm trying to support. Sighted people can immediately infer the structure of a page because they can see the rendered result, blind people can't. But inferences about structure are used to identify the content of interest: they aren't of interest in and of themselves. The correct use of the headline is to allow a blind user to have the same task profile as the sighted user - get to the content easily - not understand the page structure.
Response 2: Most web pages don't use headlines, and those that do don't use them consistently, so there isn't much point in doing anything more complex because it'll break on most pages. Chicken, egg, of course.

Bit long, forgive me, but I respect the work you've been doing so I thought you deserved a detailed description. I'm always happy to change things, of course, if you can identify a better solution for blind WebbIE users. Many thanks.

[zcorpan]

Right, WebbIE's headline handling works thus:
1 Check page for any H1 elements. If found, mark them with "Page Headline:" and stop.
2 Check page for any H2 elements. If found, mark them with "Page Headline:" and stop.
3 Check page for any H3 elements .... et cetera.

So you're saying that "Page Headline:" is prepended to all h1-h6 elements? If so, then it wouldn't make any difference if the author used <h1> for all headings or <h2> for all headings.

[alasdair]

"Page Heading:" is prepended to all instances of the highest-value heading element. So if there is one H1 element, it gets "Page Heading:" and nothing else does. If there are three H1 elements, they all get "Page Heading:" and nothing else does. If there are no H1 elements but two H2 elements, both H2 elements get "Page Heading:" and nothing else does. If there is one H6 element and no H1-H5 elements then the H6 element gets "Page Heading:"

(At least, the next version will: the current version only works for H1-H3, but I updated it for H4-H6 over Christmas. Just in case you're testing!)

[zcorpan]

I see. Then using all <h2>s as opposed to all <h1>s (as legendscrolls suggested) wouldn't help.

Wouldn't it be more useful if only the first highest-level heading gets "Page Heading:" prepended to it, rather than all elements of that level? Or perhaps just the first heading (regardless of level)?

[alasdair]

Wouldn't it be more useful if only the first highest-level heading gets "Page Heading:" prepended to it, rather than all elements of that level?

That's a good suggestion, I'll consider it. Thank-you. Will have to check out some real sites first, of course.

Checking the HTML5 specification, perhaps I could render the first Hx after of a new section element at the top of the section with "Section Heading:" And give users "next section" and "previous section" hotkeys, and maybe even a list of sections in a separate listbox. But those are slightly different use cases, and I'll have to see how some big sites start using HTML5...