Headers, Sections, and Flat Documents

4 posts / 0 new
Last post

I have a few questions on headers and sections.

[1] The guidelines state, "Each section should have a numbered heading that reflects its level in the document hierarchy, as numbered headings allow assistive technologies, regardless of their support for HTML5, to navigate the document structure."

Does this imply that we need to add numbers to headings that normally wouldn't have them, as well as adding headings to sections that normally wouldn't have them?

[2] The guidelines state, "Only a single heading should be included in a section. If you need to include subheadings, it is best to incorporate them into the main heading."

I'm concerned about the design complications that this could introduce. For example, Chapter 2 of Malcolm Gladwell's "The Tipping Point" begins

The Law of the Few
Connectors, Mavens, and Salesmen.

In our editorial markup system, this is chapter number, chapter title, and chapter subtitle. In our HTML vocabulary, we'd mark this up as

<section class="body-rw Chapter-rw" epub:type="bodymatter chapter">
<div class="title-block-rw">
<p class="title-num-rw">...</p>
<p class="title-sub-rw">...</p>

text of chapter...

(A guiding principle of our markup is that H1 is reserved for the title.)

If we tried to fit all of this in a single block element, we'd get something like

<h1><span class="title-num-rw">Two</span> The Law of the Few <span class="title-sub-rw">Connectors, Mavens, and Salesmen</span></h1>

So in CSS we'd be redefining the spans as blocks, and reading systems that didn't understand display: block on span would render the content incorrectly.

[3] Is it OK to use h2-h6 as freestanding heads, without additional sectioning elements? A typical chapter might be

section (a chapter)
h1 (the chapter title)
a bunch of text
h2 (primary head)
more text

I've spent too much of my life in Docbook, figuring out where the error was in </section></section></section><section><title/>...

Hi Dave,

Some answers for your questions...

[1] No, numbers there refers to h1-h6 numbered headings, not numbers in headings. ATs typically allow readers to move through the document structure via these headings, provided they accurately reflect the structure.

[2] That doesn't seem problematic to me. What the guidelines are striving for is to not do things like:

<h3>Chapter Number</h3>

For the reason in [1], this mashup of headings is problematic for the navigation of the content at the markup level. It is also technically wrong per HTML outlining (in HTML4 or 5), since headings indicate sections. Although the HTML5 outlining algorithm is all at risk and not supported by AT, you get implied sections for each heading you create by it, so in the above kind of markup it's the h4 that would actually contain the text of the chapter. If you had a section tag before the <h3>, I think the algorithm would turn it into a DOM along the lines of this:

   <h1>Chapter number</h1>

But even going by heading alone, navigation and comprehension gets problematic the more numbered headings are included, especially out of order, as it's left to the user to piece back together in their head exactly why they're encountering new headings (e.g., is "Two" a new part and the title a new chapter, or are the two related?).

[3] You can include heading numbers without section wrappers, since current AT move by the heading tags, anyway. Just be aware of the HTML5 outlining algorithm, as lack of inclusion in HTML 5.0 doesn't mean it's dead, and each heading implies the start of a new section (except in blockquote and figure, but we don't recommend using headings in them because the lack of support also means headings in those elements will interfere with structural headings).

That said, we recommend adding <section> wrappers as that allows you to attach an epub:type attribute to refine the meaning. It's not always necessary (specifically for subsections), but the semantics can be used to provide richer context to the reader (e.g., DAISY players often have an option to announce the current structure, and when jumping into an ebook from an index it simplifies comprehension).

Hope this helps.


Ah, very helpful. Thanks Matt!

Started writing some schematron last night to translate some of these guidelines into rules. Fun stuff!

Ya, I can see how that could be fun!

Accessibility is often more art than science, since it skirts between markup compliance and general usability. That's why one of the goals in the accessibility guidelines was to start by giving context as to why the rules matter, as validation alone often falls short.

Secondary menu