EPUB 3 Accessibility Guidelines


The section element is used to encapsulate sections of primary content, and establishes the publication's structural hierarchy. Clearly grouping and identifying content enables better navigation by anyone reading using an assistive technology (see also the faq).

An epub:type attribute should be attached to each section to indicate the specific nature of the content, when applicable. The EPUB 3 Structural Semantics Vocabulary currently defines the following terms for sectioned content:

When the epub:type attribute is not specified, a generic section/subsection nature is assumed based on the nesting level.

A section should not have more than one child heading, as it is not clear how these will be handled in HTML5. Additional headings are treated a delimiting the beginning of an implied section, but the outlining algorithm that defines this behavior is at risk of being removed from the specification (see the faq question on multiple headings below).

If a section does not have a heading, consider including a title or aria-label attribute on the section with the implied nature (e.g., 'chapter' or 'part'). Although it is anticipated that assistive technologies will be able to voice/render the epub:type semantics in such cases, a fallback attribute is prudent at this time. (Note that the title attribute may present a visible tooltip in contexts where the content can be hovered (e.g., by a mouse), whereas aria-label will not.)


Example 1 — Defining a section is a chapter with a heading
<section epub:type="chapter" id="c01">
   <h1 id="c01h01">Chapter 1. Loomings.</h1>
   <p>Call me Ishmael. … </p>
Example 2 — Defining a section is a chapter by attribute

title attribute

<section epub:type="chapter" title="chapter" id="c01">
   <p>It was a dark and stormy night … </p>

aria-label attribute

<section epub:type="chapter" aria-label="chapter" id="c01">
   <p>It was a dark and stormy night … </p>

Compliance References and Standards

Frequently Asked Questions

Should I use the section element for secondary content?

No, the section element should only be used to identify primary structural content.

Self-contained secondary content embedded within a section — such as sidebars, mini-articles, etc. — should be identified using the aside and article elements, as appropriate.

How do I handle large sections?

EPUBs are typically broken up into smaller XHTML content files to improve rendering, so it's often the case that an entire part cannot be contained in a single file. The question becomes, how do you split the chapters into separate files and still retain the part?

There are two approaches you can take to flattening out your content, and neither is optimal — at least in terms of retaining the original structural hierarchy in the markup. The first is to include the part heading with the first chapter:

   <section epub:type="part">
      <h1>Part I</h1>
      <section epub:type="chapter">
         <h2>Chapter I</h2>

Each subsequent chapter file would contain a single section with an h2 heading. Although this markup approach appears to suggest that the part only contains a single chapter, consistent heading numbering will allow an assistive technology to correctly orient the reader.

The other approach is to separate the part heading into its own file:

   <section epub:type="part">
      <h1>Part I</h1>

Again, each subsequent chapter file would include an h2 heading to indicate it is subordinate to the part. One advantage of this approach is that reading systems will render the part heading separately from the first chapter content.

It would be nice to see a future version of EPUB include a way of retaining information about the document hierarchy regardless of how the content gets broken up into files (e.g., in the spine), but at this time no such mechanism exists.

Do sections assist in navigation?

Yes and no.

Grouping content into section elements more clearly delineates the structure of your document, since there's no ambiguity about where the section begins and ends (e.g., in HTML4, headings were often interspersed throughout the content regardless of relation to structure). This structure allows readers using assistive technologies to move from section to section more easily.

It's also true that grouping and identifying the nature of each section with an epub:type attribute aids navigation of the document at the markup level (which is where assistive technologies usually operate).

That said, because the publication's hierarchy often gets flattened when content is split into separate XHTML files, the section element alone is left somewhat crippled as a navigation aid. A reader will have more difficulty moving quickly from part to part and skipping all the chapters in between unless they use the table of contents (i.e., each content file would have to be loaded and each section type checked to move forward at the markup level).

Can I auto-generate an EPUB navigation document from the section hierarchy?

Again, it depends on whether your content has been flattened or not. Automation of the document should always be possible, at least to some degree, but manual cleanup will likely be required the more complex the structure of your document and the more it has to be flattened for distribution.

If you only chunk your content for distribution, it's obviously wiser to generate the navigation document from the source document structure.

Should I use numbered headings or generic headings for my sections?

See the Headings section for more information.

Can I use multiple headings in a section?

It is best to avoid using multiple headings at this time, as it is not clear how they are to be handled. The HTML5 outlining algorithm is at risk of being removed from the specification, which previously defined that new headings defined new implied sections. The hgroup element for defining a heading set has now been removed from HTML 5.0.

If you need to include subheadings, it is better to incorporate them into the main heading for the section (e.g., wrapped within span tags to differentiate them visually, if necessary.

Revision History

  • Added aria-label as alternative to title.
  • Noted that outlining algorithm and hgroup are both at risk of removal from HTML5