Accessible EPUB 3 Page 5
by Matt Garrish
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:
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:
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:
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:
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:
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:
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.
The Untold Story: Metadata
Bringing up the topic of metadata usually triggers thoughts about the need to include title and author information in an ebook. While certainly a necessity, this kind of traditional metadata is not what we’re going to delve into now.
One of the big issues facing people with disabilities as they try to enter the ebook market is how to discover the quality of the ebooks they want to buy. One ebook is not the same as another, as we’ve been discussing, and readers need to know what they’re getting when they pay for your product. And you should be rewarded for your commitment to accessibility by having your ebooks stand out from the crowd.
Unfortunately, in the past, once you pushed your ebook into a distribution channel, whatever good work you had done to make your content accessible would become indistinguishable from all the inaccessible content out there to the person on the purchasing end. At about the same time that EPUB 3 was being finalized, however, the people at EDItEUR introduced a new set of accessibility metadata for use in ONIX records. This metadata plugs the information gap.
Note
This guide can’t possibly explain all of ONIX, nor would it be the appropriate place to do so. If you are not familiar with the standard, please visit the EDItEUR Web site for more information.
An ONIX record, if you’re not familiar, is an industry-standard message (xml record) that accompanies your publicatio
n, providing distributors with both content and distribution metadata. This information is typically used to market and sell your ebook, and these new properties now allow you to enhance that information with the accessible features your ebook includes. Retailers can then make this information available in the product description, for example, so readers can determine whether the ebook will adequately meet their needs. It’s also not a stretch to imagine this information being integrated into bookstore search engines to allow readers to narrow their results based on their needs.
To include accessibility metadata in your ONIX record, you use the ProductFormFeature element, which is described in the standard as a composite container for product information (e.g., it is also used to provide product safety information). To identify that the element contains accessibility information, it must include a ProductFormFeatureType child element with the value 09, as in the following example:
When this value is encountered, it indicates that the value of the sibling ProductFormFeatureValue element is drawn from ONIX for Books codelist 196, which defines the new accessible properties and the values to use in identifying them. As of writing, this codelist includes the following properties:
No reading system accessibility options disabled (10)
Table of contents navigation (11)
Index navigation (12)
Reading order (13)
Short alternative descriptions (14)
Full alternative descriptions (15)
Visualised data also available as non-graphical data (16)
Accessible math content (17)
Accessible chem content (18)
Print-equivalent page numbering (19)
Synchronised pre-recorded audio (20)
So, for example, if our EPUB contains accessible math formulas (using MathML) we would indicate it as follows:
Likewise, to indicate accessible chemistry content (using ChemML) we would use the value 18:
You must repeat the ProductFormFeature element for each accessibility requirement your EPUB meets; it is not valid to combine all your features into a single element.
You must also ensure that you make yourself familiar with the requirements for compliance before adding any accessibility properties; each of the properties defined in codelist 196 includes conformance criteria. EPUB requires table of contents navigation, for example, but the addition of the required navigation document does not automatically indicate compliance. You need to include full navigation, plus navigation to any tables and figures, before you comply with the table of contents navigation requirement. Likewise, all EPUBs have a reading order defined by the spine element in the package document, but that does not mean you comply to including a reading order. You need to ensure that sidebars and footnotes and similar information has been properly marked up so as not to interfere with the narrative flow, as we went over in the section on the logical reading order.
It is additionally worth noting that there are three properties that aren’t directly related to the content of your EPUB:
Compatibility tested (97)
Trusted intermediary contact (98)
Publisher contact for further accessibility information (99)
Each of these properties requires the addition of a child ProductFormFeatureDescription element to describe compliance:
Whatever compatibility testing you’ve performed should be listed using code 97 so that readers can better determine the suitability of your ebook for their purposes. Not all reading systems and assistive technologies work alike, or interact well together, and real-world testing is the only way to tell what does and does not work.
There are organizations who specialize in testing across a broad spectrum of devices who can assist you in evaluating your content, as this kind of evaluation can be no small undertaking. A good practice to develop, for example, might be to periodically have typical examples of content coming out of your production stream tested for compatibility issues. The resulting statement could then be re-used across much of your content, so long as the features and markup used remain consistent.
Once you start getting creative with your content (e.g., using extensive scripted interactivity), you should engage experts as early on in the process as you can to ensure any statement you make remains true, however.
The other two codes provide contact information for the person(s) in your organization, or at a trusted intermediary, who can provide additional accessibility information:
If you’re providing educational materials, for example, you’ll want to provide educators a way to be able to contact you to determine whether your content will be accessible by students with various needs that may not be specifically addressed in your compatibility testing statement or in the available metadata properties.
Chapter 3. It’s Alive: Rich Content Accessibility
It’s now time to turn our attention to the features that EPUB 3 introduces to expand on the traditional reading experience; the excitement around EPUB 3 doesn’t come from text and images, after all.
This section takes focus on the dynamic aspects of EPUB 3. Rich media, audio integration, and scripted interactivity are all new features that have been added in this version. Some of these features, like audio and video support and scripting, introduce new accessibility challenges, while others, like overlaying audio on your text content and enhancing text-to-speech rendering, improve access for all. (The members of this latter group are also commonly referred to as accessibility superstructures, because they are added on top of core EPUB content to enhance accessibility.)
But let’s get back to business of being accessible…
The Sound and the Fury: Audio and Video
The new built-in support for audio and video in EPUB 3 has its pros and cons from both mainstream and accessibility perspectives. The elements simplify the process of embedding multimedia, but come at the expense of complicating interoperability, and by extension accessibility—specifically as relates to video.
There is currently no solution for the general accessibility problem of video, namely that not all reading systems may natively play your content. The video element permits any video format to be specified, but not all reading systems will support all formats. Support for one or both of the VP8 codec (used in WebM video) and H.264 codec is encouraged in the EPUB specification to improve interoperability, but you still have to be aware that if you have an EPUB with WebM video and a reading system that only supports H.264 you won’t be able to view the video.
Until consensus on codec and container support can be found, there is no easy solution to this problem. You can try targeting your video format to the distribution channel, but that assumes that the readers buying from the online bookstore will use the reading system you expect, which isn’t a given. Even seemingly-simple solutions, like duplicating the format of all video content, are only feasible on small scales and don’t take into account the potential cost involved.
Note
It is possible that some reading systems may provide no video support
at all.
But that was more of an aside to say that if you don’t think accessibility is worth your time and effort, consider there may be a larger audience than you might expect that could be relying on your fallbacks in the near term.
Playability issues aside, though, HTML5 is still a leap forward in terms of multimedia support. It’s fair to assert that no one will miss plugins for rendering audio and video content, certainly not on the accessibility side of the fence. From roach-motel players that let you navigate in but never let you leave to players lacking keyboard support to utter black holes, the accessibility community typically does not have a lot of good things to say about multimedia as deployed on the Web.
That the new native elements can be controlled by the reading system in EPUB 3 should translate into greater accessibility, however. To enable the default system controls, you need only add a controls attribute to the element: