We’ve gone over a number of ways to assist in accessible navigation by improving the structure and semantics of your content, but navigating at the content level is only a complement to a good table of contents. EPUB 3 includes a new declarative means of creating tables of contents called the navigation document, which is a fancy way of saying that you can now create a special kind of XHTML document for reading systems to provide their own built-in navigation mechanism(s).
Declarative tables of contents are not new to EPUB 3, however. EPUB 2 had a file format called the NCX for this purpose, which was taken from the DAISY talking book standard (and that format can still be included in EPUB 3 publications for forwards compatibility with older reading systems). But the NCX was a complex solution to a much simpler problem, and actually hindered accessibility in this new context, as its lack of intrinsic display controls led to navigation levels being chopped off to improve visual rendering.
So, to strike back up on a common theme, not all markup is created equal, and the quality of your table of contents for navigation is a reflection whether you put the full structure of your publication in it or not. The new navigation document fortunately gives you the best of both worlds in that it doesn’t require the decision to pick either visual clarity or full accessibility to be made.
Let’s take a quick tour through the actual creation process to see how this is done for both reading groups.
The navigation document uses the new HTML5 nav element
to define various kinds of navigation lists, as more than just a table of contents
can be included in it. But as a primary table of contents is required in every EPUB,
we’ll begin by looking at a very minimal example:
<nav epub:type="toc">
<h1>Contents</h1>
<ol>
<li>
<a href="chapter_001.xhtml">Chapter 1. Loomings.</a>
</li>
<li>
<a href="chapter_002.xhtml">Chapter 2. The Carpet-Bag.</a>
</li>
</ol>
</nav>
The epub:type attribute identifies that this nav element represents the table of contents (via the
“toc” value). But if the rest of the navigation list looks like nothing more than an
ordered list of links, that’s because that’s exactly what navigation lists are. The
nav element should include a heading, but after
that it only ever includes a single ol element.
Each list item either contains a single link to a location in the content (as shown
in the example above), a link followed by an ordered list of subheadings, or a span element (a heading) followed by an ordered list of
subheadings. That’s really all there is to building navigation lists.
Let’s take a look at a piece of a more complex table of contents now that we know what we’re looking at:
<nav epub:type="toc">
<h1>The Contents</h1>
<ol>
<li>
<span>SECTION IV FAIRY STORIESMODERN FANTASTIC TALES</span>
<ol>
<li>
<span>Abram S. Isaacs</span>
<ol>
<li>
<a href="section004.xhtml#s190">
190. A Four-Leaved Clover
</a>
<ol>
<li>
<a href="section004.xhtml#s190-1">
I. The Rabbi and the Diadem
</a>
</li>
<li>
<a href="section004.xhtml#s190-2">
II. Friendship
</a>
</li>
</ol>
</li>
</ol>
</li>
</ol>
</li>
</ol>
</nav>
Here we start with two heading levels, one for the section and another for the author
(as indicated by the span tags that surround the text).
We then have the title of the tale (“A Four-Leaved Clover”), which has additionally
been broken down into parts, for a grand total of four levels of navigable
content.
But it’s hard enough to format all these lists for the example, let alone display them in a reading device without line wrapping getting in the way. This is the point where aesthetics would win out in the old NCX and the last level would typically be dropped, since it carries the least structurally-important information. But you’d have also just sacrificed completeness for visual clarity, an accessibility no-no. It might not seem like a big issue here, but consider the many levels of depth typical textbooks contain (numbered and unnumbered) and how difficult it makes navigating when the structure outline is gone.
The HTML5 hidden attribute arrives at this point to save
the day. This attribute is the promised solution to indicating where visual display
should end without the requirement to remove entries. Since we’ve decided we only
want to visually render down to the level of the tales the author wrote, we can
attach the attribute to the ordered list containing the part links. Removing a
couple of levels for clarity, our previous example would now be tagged as
follows:
<li>
<a href="section004.xhtml#s190">190. A Four-Leaved Clover</a>
<ol hidden="hidden">
<li>
<a href="section004.xhtml#s190-1">I. The Rabbi and the Diadem</a>
</li>
<li>
<a href="section004.xhtml#s190-2">II. Friendship</a>
</li>
</ol>
</li>
Now all a sighted reader will be presented is the linkable name of the tale (the child ordered lists will be invisible to them), but someone using an assistive technology will still be able to descend to the part level to move around.
Another advantage of this attribute is that it allows you to selectively decide how to hide rendering. For example, if your leveling changes from section to section, you aren’t locked into a single “nothing below level 3” approach to tailoring your content. Only the ordered lists you attach the attribute to are hidden from view.
Before turning to the other types of navigation lists you can include in the
navigation document, there is one additional accessibility requirement to note.
Since the a and span
elements allow all HTML5 inline content, you need to remember not to assume that
their content will always be rendered visually. Or, more to the point, to remember
that your entries might not voice properly if they include images or MathML or
similar.
If the prose you include will present a challenge to voice playback, you need to
include a title attribute with an equivalent text
rendition to use instead:
<li><a href="chapter001.xhtml#pi" title="The life of pi">The Life of π</a></li>
Some assistive technologies might voice the pi character in this example as the letter “p”, for example, which might make sense in a biology book but would be an awkwardly confusing title to announce in a math book.
But to move on from the primary table of contents, there are other ways to help readers navigate your document that are also a benefit to all. The landmarks nav, for example, can provide quick access to key structures. These can be whatever you want, but jumping to the index, glossaries, and other back matter elements are common tasks the readers may want to perform many times while reading. Think of it like a kind of bookmark list to key structures:
<nav epub:type="landmarks">
<h1>Guide</h1>
<ol>
<li>
<a epub:type="toc" href="contents.xhtml#toc">
Table of Contents
</a>
</li>
<li>
<a epub:type="bodymatter" href="chapter001.xhtml#bodymatter">
Start of Content
</a>
</li>
<li>
<a epub:type="glossary" href="glossary.xhtml#gloss">
Glossary
</a>
</li>
<li>
<a epub:type="index" href="index.xhtml#idx">
Index
</a>
</li>
</ol>
</nav>
You’ll notice that, unlike the table of contents example, the a tags have epub:type attributes attached
to them to provide machine-readable semantics. The epub:type attribute is required on all links in the landmarks navigation
list. The additional semantics are there to help facilitate quick-link options in
reading systems so that the landmarks list doesn’t have to be opened and navigated
manually each time (e.g., a dedicated reading system option to jump to the
index).
We touched on the need for page lists in the last section, so I’ll only note that a page-list nav should be included if the ebook is part of a dual print-digital workflow:
<nav epub:type="page-list">
<h1>Page List</h1>
<ol>
<li><a href="chapter001.xhtml#page001">1</a></li>
<li><a href="chapter001.xhtml#page002">2</a></li>
…
</ol>
</nav>
And don’t limit yourself to paper thinking. The navigation document allows any number of useful navigation lists you can devise. Maybe you want to give readers a quick reference to major scenes in your story, for example. There are innumerable ways in which you can expand on this functionality, but semantics and support are going to take community and player support to implement. But that’s true of all new functionality.