EPUB Accessibility Techniques 1.0

Editor's Draft 1 August 2016

This version
http://www.idpf.org/epub/a11y/techniques/techniques-20160801.html
Latest version
http://www.idpf.org/epub/latest/accessibility/techniques
Previous version
http://www.idpf.org/epub/a11y/techniques/techniques-20160711.html
Previous recommendation
N/A
Document history

Editors

Matt Garrish, Invited Expert

George Kersher, DAISY Consortium

Charles Lapierre, Benetech

Avneesh Singh, DAISY Consortium

Authors

Romain Deltour, DAISY Consortium

Markus Gylling, International Digital Publishing Forum (IDPF)

Bernhard Heinser, Access for All

Madeleine Rothberg, Invited Expert

Tzviya Siegman, John Wiley & Sons

Jason White, Invited Expert

Copyright © 2010-2016 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

  1 Overview

  1.1 Purpose and Scope

This section is informative

This document, EPUB Accessibility Techniques, provides guidance on how to meet the [EPUB Accessibility] discovery and accessibility requirements for EPUB® Publications.

This document does not cover techniques and best practices already addressed in [WCAG 2.0] and [WAI-ARIA 1.1] for which no substantive differences in application exist.

  1.2 Terminology

Assistive Technology

This specification adopts the meaning of an assistive technology from [WCAG 2.0].

Note that an assistive technology is not always a separate application from a Reading System. Reading Systems often integrate features of standalone assistive technologies, such as text-to-speech playback.

Author

The person(s) or organization responsible for the creation of an EPUB Publication. The Author is not necessarily the creator of the content.

Default Rendition

The Rendition listed in the first rootfile element in the META-INF/container.xml file.

EPUB Content Document

A document that conforms to one of the EPUB Content Document definitions.

EPUB Navigation Document

A specialized XHTML Content Document that contains human- and machine-readable global navigation information.

EPUB Publication

A collection of one or more Renditions that represents a single intellectual or artistic work.

Package Document

The Package Document describes one Rendition of an EPUB Publication. It carries meta information, provides a manifest of resources and defines the default reading order.

Reading System

A system that processes EPUB Publications for presentation to a User.

Rendition

A logical document entity that represents one rendering of an EPUB Publication.

User

An individual that consumes an EPUB Publication using a Reading System.

note

Some terms have more precise meanings for a given version of EPUB. Refer to the appropriate specification for more information.

  1.3 Typographic Conventions

The following typographic conventions are used in this specification:

markup

All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine-readable values (string, characters, media types) and file names are in red monospace font.

markup link

Links to markup and code definitions are in underlined red monospace font.

http://www.idpf.org/

URIs are in navy blue monospace font.

hyperlink

Hyperlinks are underlined and blue.

[reference]

Normative and informative references are enclosed in square brackets.

Term

Terms defined in the Terminology are in capital case.

Term Link

Links to term definitions have a dotted blue underline.

Normative element, attribute and property definitions are in blue boxes.

Informative markup examples are in light gray boxes.

note

Informative notes are in green boxes with a "Note" header.

caution

Informative cautionary notes are in red boxes with a "Caution" header.

  1.4 Conformance Statements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

All sections and appendixes of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendixes applies to all child content and subsections they contain.

All examples in this specification are informative.

  2 About the Techniques

The accessibility techniques described in this document are advisory in nature. They are intended to help Authors create EPUB Publications that conform to the requirements in [EPUB Accessibility], but they are not all applicable in all situations and there may be other ways to meet the requirements of that specification. As a result, this document should not be read as providing prescriptive requirements.

These techniques also do not address issues in digital publishing for which no universally accessible solutions exist. The W3C's Digital Publishing Interest Group has published a note that outlines many of these issues [W3C Accessibility Note]. As solutions become available, they will be incorporated into the appropriate document, whether this one or one it refers to.

If Authors encounter issues that are not covered in these or related techniques, they are encouraged to report the issue to the appropriate community for guidance on how to meet accessibility standards. The W3C Web Accessibility Interest Group has a public mailing list where issues meeting [WCAG 2.0] and [WAI-ARIA 1.1] requirements can be raised. The IDPF similarly has an accessibility forum where EPUB-related issues can be raised.

  3 Discovery Metadata Techniques

  META-001: Identify primary access modes

An access mode is defined as a "human sense perceptual system or cognitive faculty through which a user may process or perceive the content of a digital resource." [ISO24751-3] For example, if an EPUB Publication contains images and video, visual perception is required to consume the content exactly as it was created.

There are four access modes that are typically specified for EPUB Publications:

  • textual — the publication contains text content (headings, paragraphs, etc.).

  • visual — the publication contains visual content such as images, graphics, diagrams, animations and video.

  • auditory — the publication contains auditory content such as standalone audio clips and audio soundtracks for video content.

  • tactile — the publication contains tactile content such as embedded braille and tactile diagrams.

In order for a User to determine whether an EPUB Publication is suitable for their needs, they need to know which of these access modes are required to consume the content. List all applicable access modes in the [schema.org] accessMode property, repeating the property for each.

The following example shows the metadata entries for an EPUB 3 Publication that has textual and visual access modes.

<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>

Note that the access modes of the content do not reflect any adaptations that have been provided. For example, if a comic book also includes alternative text for each image, it does not have a textual access mode. See the following section on sufficient access modes for how to indicate that the available adaptations allow the content to be consumed in another mode.

Refer to the accessMode proposal for more information about this property and its values.

  META-002: Identify sufficient access modes

The access modes sufficient to consume an EPUB Publication express a broader picture of the potential usability than do the basic access modes. Where the basic access modes identify the default nature of the media used in the publication, sufficient access modes identify which modes can be used to read the entire publication. Sufficient access modes also take into account the adaptations that have been provided, allowing a User to determine whether the content will be usable regardless of its default nature.

Sufficient access modes are identified in the [schema.org] accessModeSufficient property. Repeat the property for each set of sufficient access modes.

For example, consider an EPUB Publication that contains graphics and charts, as well as descriptions for all these images. The publication has both textual and visual access modes, so the Author will include the following metadata entries to indicate this:

<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>

This metadata does not make clear that a textual access mode is sufficient to read the entire publication, or that a visual one is, only that two modes are required by default. This discrepancy is why sufficiency is also important to know.

The first set of sufficiency metadata the Author inputs will establish the textual and visual requirement:

<meta property="schema:accessModeSufficient">textual visual</meta>

Since the Author has also included descriptions for all the images, she can also indicate that a purely textual access mode is sufficient to read the content:

<meta property="schema:accessModeSufficient">textual</meta>

Users now have a more complete idea of the readability of the content.

The full set of entries in this example is as follows:

<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>
<meta property="schema:accessModeSufficient">textual visual</meta>
<meta property="schema:accessModeSufficient">textual</meta>

Note that sufficiency of access is often a subjective determination of the Author based on their understanding of what information is essential to comprehending the text. Some information loss occurs by not being able to view a video, for example, but the Author might regard the visual or auditory losses as inconsequential if a transcript provides all the necessary information to understand the concepts being conveyed.

Refer to the accessModeSufficient proposal for more information about this property and its values.

  META-003: Identify accessibility features

Identifying all the accessibility features and adaptations included in an EPUB Publication allows Users to determine whether the content is usable at a more fine-grained level than the access modes do.

For example, a math textbook might have a textual access mode, but that in itself does not indicate whether MathML markup is available. Whether a visual work only provides alternative text or whether it includes extended descriptions is also important to know when gauging its usability.

Accessibility features are identified in the [schema.org] accessibilityFeature property. Repeat this property for each feature.

The following example shows the metadata entries for an EPUB 3 Publication that has both MathML and alternative text.

<meta property="schema:accessibilityFeature">MathML</meta>
<meta property="schema:accessibilityFeature">alternativeText</meta>

The EPUB format requires that some accessibility features will always be present (e.g., a table of contents). Do not exclude these features from the accessibility metadata, as Users typically are not aware what features are built into a format. Failing to include entries will reduce the discoverability of the publication when users search for specific features.

Refer to the schema.org accessibility wiki for more information about this property and its values.

  META-004: Identify accessibility hazards

There are three widely-recognized hazards that can affect readers of digital content:

  • flashing — if a resource flashes more than three times a second, it can cause seizures (e.g., videos and animations). See also [WCAG 2.0] Guideline 2.3.

  • motion simulation — if a resource simulates motion, it can cause a user to become nauseated (e.g., a video game drawn on the [HTML] canvas element).

  • sound — certain sound patterns, such as ringing and buzzing, can cause seizures.

EPUB Publications have to report whether or not they contain resources that present any of these hazards to Users, as they can have real physical effects.

Hazards are identified in the [schema.org] accessibilityHazard property. Repeat this property for each hazard.

Unlike other accessibility properties, the presence of hazards can be expressed both positively and negatively. This design decision was made because Users most often search for content that is free from hazards that affect them, but also want to know what dangers are present in any publications they discover.

The following example shows the metadata entries for an EPUB 3 Publication that has a flashing hazard but no motion simulation or sound hazards.

<meta property="schema:accessibilityHazard">flashing</meta>
<meta property="schema:accessibilityHazard">noMotionSimulationHazard</meta>
<meta property="schema:accessibilityHazard">noSoundHazard</meta>

Do not skip reporting hazards just because an EPUB Publication does not contain any content that could present risks. Users cannot infer a meaning when no metadata is present.

If an EPUB Publication contains a hazard, provide additional information about its source and nature in the accessibility summary.

Refer to the schema.org accessibility wiki for more information about the values that can be used with this property.

  META-005: Include an accessibility summary

An accessibility summary provides a brief, human-readable description of the accessibility characteristics of an EPUB Publication, or lack thereof.

If an EPUB Publication does not meet the requirements for content accessibility in [EPUB Accessibility], the reason(s) it fails should be noted in the summary.

An accessibility summary is provided using the [schema.org] accessibilitySummary property. Do not repeat this property.

The following example shows an accessibility summary for an EPUB 3 Publication that failed to meet the content accessibility requirements.

<meta property="schema:accessibilitySummary">
   The publication is missing alternative text for complex diagrams.
   The publication otherwise meets WCAG 2.0 Level A.
</meta>

The following example shows an accessibility summary for an EPUB 3 Publication with a motion simulation hazard.

<meta property="schema:accessibilitySummary">
   Chapter four contains a first-person interactive game that could cause
   motion sickness in certain individuals. The game is only provided for
   illustrative purposes, so readers unable to interact with it will not
   be at a disadvantage.
</meta>

  META-006: Identify Accessibility API Conformance

Users of Assistive Technologies are able to interact with EPUB Publications through the accessibility APIs built into whichever platform they use (Windows, Mac, iOS, Linux, etc.). These APIs allow the Assistive Technology to communicate with the Reading System to read the text or control the interface, as needed.

Authors of static content do not have to worry about this interaction, as the User's Reading System exposes the necessary information to the accessibility APIs (provided it has been developed to be accessible). Authors who create EPUB Publications that contain dynamic content — such as scripting, custom controls and foreign interactive content (e.g., Flash videos) — do need to pay attention to the compatibility of such content, as Assistive Technologies may not receive sufficient information to provide an accessible interface.

In the case of scripted content, the static picture of the content that an Assistive Technology initially generates will not get updated unless the Author follows the accessibility practices in [WAI-ARIA 1.1]. Similarly, although Assistive Technologies have access to information about native [HTML] form elements (e.g., buttons and inputs), Authors often create custom elements whose state is opaque without correct use of [WAI-ARIA 1.1] roles, state and properties  (e.g., checkboxes made out of images). Users want to know that such content has been made compatible with Reading System that support ARIA.

The use of plugin-based applications like Flash is generally rare in newer versions of EPUB, but as plugins run in a separate space from the Reading System, the usability of their interface depends on how well they interact with the system accessibility API.

Compatible APIs are identified in the [schema.org] accessibilityAPI property. Repeat this property for each API.

The following example shows that an EPUB Publication contains scripted content that is ARIA compatible.

<meta property="schema:accessibilityAPI">ARIA</meta>

The following example shows an EPUB 2 Publication with Flash video is only compatible with the Microsoft Active Accessibility API.

<meta name="schema:accessibilityAPI" content="MSAA"/>

Refer to the schema.org accessibility wiki for more information about this property and its values.

note

The property does not apply to content in [HTML] elements with native controls, such as those provided by the audio and video elements.

  META-007: Identify Input Control Methods

Not everyone who reads an EPUB Publication uses the same input control methods. Not only will the device affect the input method (e.g., mobile or desktop), but so will the User's physical abilities. Users might use any number of input methods, from touch to mice to keyboards to voice controls and on.

As a result, all Users need to know what input controls work with the content, as it will affect not only whether they can operate the content but on what devices.

Similar to the accessibility APIs, the input control methods that can be used to read an EPUB Publication are greatly influenced by the accessibility of the Reading System. It is only when Authors include dynamic content that they assume a responsibility for ensuring that such is accessible to different input control methods.

Compatible input controls are identified in the [schema.org] accessibilityControl property. Repeat this property for each input control method.

The following example shows that an EPUB Publication contains content that is touch, mouse and keyboard compatible.

<meta property="schema:accessibilityControl">fullTouchControl</meta>
<meta property="schema:accessibilityControl">fullMouseControl</meta>
<meta property="schema:accessibilityControl">fullKeyboardControl</meta>

Refer to the schema.org accessibility wiki for more information about this property and its values.

note

The property does not apply to content in [HTML] elements with native controls, such as those provided by the audio and video elements.

  Examples

The following examples show the metadata that would be added to an EPUB Publication that has textual and visual access modes, is sufficient for reading by text, contains alternative text and [MATHML] markup, and has a flashing hazard.

EPUB 3

<package … >
   <metadata>
      …
      <meta property="schema:accessMode">textual</meta>
      <meta property="schema:accessMode">visual</meta>
      <meta property="schema:accessModeSufficient">textual visual</meta>
      <meta property="schema:accessModeSufficient">textual</meta>
      <meta property="schema:accessibilityFeature">MathML</meta>
      <meta property="schema:accessibilityFeature">alternativeText</meta>
      <meta property="schema:accessibilityHazard">flashing</meta>
      <meta property="schema:accessibilityHazard">noMotionSimulationHazard</meta>
      <meta property="schema:accessibilityHazard">noSoundHazard</meta>
      <meta property="schema:accessibilitySummary">
         The video in chapter 2 presents a flashing hazard. A transcript is
         provided that covers all the essential information contained in the
         video. The publication otherwise meets WCAG 2.0 Level A.
      </meta>
   </metadata>
   …
</package>

EPUB 2

<package … >
    <metadata>
       …
       <meta name="schema:accessMode" content="textual"/>
       <meta name="schema:accessMode" content="visual"/>
       <meta name="schema:accessModeSufficient" content="textual visual"/>
       <meta name="schema:accessModeSufficient" content="textual"/>
       <meta name="schema:accessibilityFeature" content="MathML"/>
       <meta name="schema:accessibilityFeature" content="alternativeText"/>
       <meta name="schema:accessibilityHazard" content="flashing"/>
       <meta name="schema:accessibilityHazard" content="noMotionSimulationHazard"/>
       <meta name="schema:accessibilityHazard" content="noSoundHazard"/>
       <meta name="schema:accessibilitySummary" content="The video in chapter 2 presents a flashing hazard. A transcript is provided that covers all the essential information contained in the video. The publication otherwise meets WCAG 2.0 Level AA."/>
    </metadata>
    …
</package>

  4 WCAG Techniques

  4.1 General Guidance

Techniques for meeting the requirements of the Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG 2.0] are defined in Techniques for WCAG 2.0 [WCAG 2.0 Techs]. This document does not repeat these techniques.

In general, the differences between the application of WCAG techniques to Web pages and their application to EPUB Content Documents is minimal, but the following sections outline some key differences.

One point to note is that the WCAG techniques cover a greater range of technologies and content types than are typically found in an EPUB Publication, so many are not applicable.

The following sets of techniques are the most broadly applicable to EPUB Content Documents:

Other techniques will apply depending on the technologies used (e.g., a [SWF] video in EPUB 2) or any alternative formats embedded in the EPUB Publication (e.g., a PDF form).

  Helpful Resources

Authors not familiar with [WCAG 2.0 Techs] may find the number of techniques daunting, as they are intended to provide broad coverage of possible solutions.

Assistance applying these techniques to EPUB Content Documents is available from the following sources:

  4.2 Content Access

  ACCESS-001: Ensure linear reading order of the publication

[WCAG 2.0] Success Criterion 1.3.2 specifies that each Web page have a meaningful order, but the content of an EPUB Publication typically spans multiple documents. It is consequently essential not only that each EPUB Content Document has a meaningful order, but that the order is meaningful from document to document.

Authors need to ensure that all EPUB Content Documents are included in the spine [Packages 3] and put in sequence so that the reading order is preserved.

The following example shows the linear progression of chapter references in an EPUB spine.

<package …>
   …
   <manifest>
      …
      <item id="chap01" href="xhtml/chapter01.xhtml" …/>
      <item id="chap02" href="xhtml/chapter02.xhtml" …/>
      <item id="chap03" href="xhtml/chapter03.xhtml" …/>
      …
   </manifest>
   <spine>
      …
      <itemref idref="chap01"/>
      <itemref idref="chap02"/>
      <itemref idref="chap03"/>
      …
   </spine>
</package>

Authors also need to ensure that they identify whether items in the spine contain primary or supplementary information using the linear attribute [Packages 3] so that the Reading System can optimally present such content.

The following example shows a non-linear answer key between two chapters.

<spine>
   …
   <itemref idref="chap01"/>
   <itemref idref="answers01" linear="no"/>
   <itemref idref="chap02"/>
   …
</spine>

  ACCESS-002: Provide multiple ways to access the content

[WCAG 2.0] Success Criterion 2.4.5 requires there be more than one way to locate a Web page within a set of Web pages. By default, EPUB Publications meet this WCAG requirement so long as Authors follow the EPUB requirements to include all EPUB Content Documents in the spine and ensure access to all non-linear documents [Packages 3].

The reason an EPUB Publication passes by meeting these requirements has to do with differences in how a User interacts with the set of documents in an EPUB Publication. In particular, although an EPUB Publication typically consists of many Content Documents, Reading Systems automatically provide the ability for the User to move seamlessly from one document to the next, so long as they are listed in the spine [Packages 3]. To the User, an EPUB Publication is a single document they have complete access to, not a set of disconnected pages that they need links to move through.

The required table of contents provides a second method to access the major headings of the publication. The User can jump to any heading and continue to navigate from there, regardless of how the publication is chunked.

Following these two requirements therefore satisfies the need for multiple ways to access the content. Reading Systems also typically provide search capabilities, something the Author cannot provide, so Users also have a third option available in most cases.

Although Authors only need to follow EPUB requirements to meet this criteria, they are still encouraged to provide additional methods to improve access beyond the minimum. Some suggestions include:

  • adding at least one link to every Content Document in the spine to the table of contents, when feasible;

  • adding an index to locate major topics;

  • adding additional navigation aids to the EPUB Navigation Document (e.g., lists of figures and tables).

  1 Note About the Table of Contents

A common question about the EPUB table of contents is what completeness it needs to have with respect to the headings of the publication. Although the obvious answer seems like it should be a simple aggregation of all headings for all sections, practically there are a number of usability challenges to this approach.

Factors such as device screen sizes can make the table of contents for publications with a deep hierarchy of headings unreadable, so Authors trim headings below a certain depth to improve the quality. Reading Systems also do not always provide structured access to the headings in the table of contents, or shortcuts to move easily through the headings, leaving Users that have them read aloud navigating the links one at a time.

Although it is expected that Reading Systems will improve access to the table of contents as accessibility support for EPUB evolves — making complete tables of contents usable by everyone — there are legitimate usability reasons why they are not provided now.

When Authors choose not to provide links to all the headings, however, they should optimize the linking they do provide for the best overall reading experience. Some considerations on how to achieve this include:

  • ensuring that there is at least one link to every EPUB Content Document — allowing the User to reach each document simplifies navigation to the minor headings within them;

  • only omitting minor headings from the table of contents — although a subjective decision, there is often a level of diminishing value for navigation (e.g., fourth level and lower headings often only delimit short subsections on a topic).

  4.3 Semantics

  SEM-001: Include ARIA and EPUB semantics

The [WAI-ARIA 1.1] role attribute is used to provide additional semantic information about the host markup to Assistive TechnologiesAuthors can attach it to any element. The use of roles allows Assistive Technologies to automatically scan the markup and compile a list of landmarks for Users, enabling quick access to key features of the content.

The following example shows a generic landmark role. The name to use for this landmark is specified by the [WAI-ARIA 1.1] aria-labelledby attribute.

<section role="region" aria-labelledby="puz01">
   <h2 id="puz01">Puzzles and Games<h2>
   …
</section>

The role attribute is similar in nature to the type attribute [Content Docs], which provides additional semantic information to enable EPUB Reading System behaviors.

The following example shows the epub:type attribute used to provide additional semantic information.

<section epub:type="learning-objectives">
   <h2>Objectives<h2>
   …
</section>

The key difference between these attributes is that the role attribute bridges accessibility while the type attribute provides hooks to enable Reading System behaviors. Omitting roles lessens the accessibility for Users of Assistive Technologies, in other words, while omitting types diminishes certain functionality in Reading Systems (e.g., pop-up footnotes or special presentations of the content).

Since each attribute offers different advantages, it is recommended that both be used whenever applicable to provide the best reading experience for all readers.

It is often the case that the attributes will have have corresponding semantics. In these situations, it is recommended that both attributes be attached to an element.

The following example shows a footnote identified in both the epub:type and role attributes.

<aside epub:type="footnote" role="doc-footnote">
   …
</aside>

  Helpful Resources

The following documents list the semantics that are available for use with each attribute:

  • The Digital Publishing WAI-ARIA Module [DPUB Vocab] provides a set of core publishing roles, but any roles from [WAI-ARIA 1.1] can be used in the role attribute.

  • The EPUB Structural Semantics Vocabulary [Structure Vocab] provides the default values that can be used with the type attribute, but the attribute is extensible to allow semantics from other vocabularies.

The following documents explain the application of ARIA roles for Authors already familiar with the use of the EPUB 3 type attribute for semantic inflection:

  SEM-002: Do not repeat semantics across chunked content

Although EPUB Publications appear as single contiguous documents to Users when read, they are typically composed of many individual EPUB Content Documents. This practice keeps the amount of markup that has to be rendered small to reduce the load time when the User cannot interact with the documents. It is rare, at least for books, that an EPUB Publication contains only one Content Document with all the content in it.

When content is chunked in this way, it often requires the Author to make decisions about how best to restructure the information. A part, for example, cannot contain all the chapters that belong to it. The Author instead has to flatten the structure and separate the part heading from each chapter.

Although visually these restructuring decisions can be hidden from readers, they impact the functionality of Assistive Technologies. In the case of [WAI-ARIA 1.1] roles, the result is that only the subset present in the currently-loaded EPUB Content Document are exposed to Users. An Assistive Technology cannot provide a list of landmarks for the whole publication, as it cannot see outside the current document.

To counteract this destructuring effect, Authors sometimes think to re-add or re-identify structures in the belief that having this information in every document will be helpful to Users (e.g., adding an extra [HTML] section element around a chapter to indicate it belongs to a part, or putting the part semantic on the body tag). All this practice does, however, is add repetition that is not only disruptive when reading, but can actually make the structure of the publication harder to follow. Authors are therefore advised not to attempt to rebuild structures in these ways.

For example, consider a book that has five parts and each part contains five chapters. Structurally, each chapter belongs to its part (i.e., is grouped with it), as in the following markup:

<section role="doc-part">
   <h1>Part 1</h1>
   
   <section role="doc-chapter">
      <h2>Chapter 1</h2>
      …
   </section>
   …
</section>

Since this would lead to a large content file, the part heading is typically split out into its own Content Document so that it will appear on its own page:

<html … >
   …
   <body role="doc-part">
      <h1>Part 1</h1>
   </body>
</html>

Each chapter is then separated into a separate Content Document:

<html … >
   …
   <body role="doc-chapter">
      <h2>Chapter 1</h2>
   </body>
</html>

It is not necessary to add a part wrapper to each chapter, as in the following example:

<html … >
   …
   <body role="doc-part">
      <section role="doc-chapter">
         <h2>Chapter 1</h2>
         …
      </section>
   </body>
</html>

Doing so introduces a new part landmark into each document, which will cause an Assistive Technology to inform the User that the landmark is available to navigate to.

  SEM-003: Include EPUB landmarks

[WAI-ARIA 1.1] landmarks are similar in nature to EPUB landmarks [Packages 3]: both are designed to provide Users with quick access to the major structures of a document, such as chapters, glossaries, indexes, etc. ARIA landmarks are compiled automatically by Assistive Technologies from the roles that have been applied to the markup, so Authors only need to follow the requirement to include roles for the landmarks to be made available to Users.

Although automatic generation of ARIA landmarks simplifies authoring, it also means that ARIA landmarks are limited to how the EPUB Publication has been chunked up into Content Documents. An Assistive Technology can only present the landmarks available in the currently-loaded document; it cannot provide a complete picture of all the landmarks in a multi-document publication (see the previous section for more discussion about content chunking).

EPUB landmarks, on the other hand, are statically compiled by the Author prior to distribution, and are not directly linked to the use of the type attribute [Content Docs] in the content. They are designed to simplify linking to major sections of the publication in a machine-readable way, as Reading Systems do not scan the entire publication for landmarks, either. EPUB landmarks are typically not as numerous as ARIA landmarks, as Reading Systems only expose so many of these navigation aids.

Given these differences in application, however, it is important to include EPUB landmarks and not rely only on the presence of ARIA roles to facilitate navigation, and vice versa. Each aids navigation in its own way.

The EPUB specification does not require that Authors include a specific set of landmarks, but it is recommended to include a link to the start of the body matter as well as to any major reference sections (e.g., table of contents, endnotes, bibliography, glossary, index).

The following example shows the EPUB 3 landmarks as expressed in the EPUB Navigation Document.

<nav epub:type="landmarks">
   <ol>
      <li>
         <a epub:type="toc" href="toc.xhtml">
            Table of Contents
         </a>
      </li>
      <li>
         <a epub:type="bodymatter" href="chap01.xhtml">
            Start reading
         </a>
      </li>
      <li>
         <a epub:type="endnotes" href="notes.xhtml">
            Notes
         </a>
      </li>
      <li>
         <a epub:type="bibliography" href="bibliography.xhtml">
            Bibliography
         </a>
      </li>
      <li>
         <a epub:type="glossary" href="glossary.xhtml">
            Glossary
         </a>
      </li>
      <li>
         <a epub:type="index" href="index.xhtml">
            Index
         </a>
      </li>
   </ol>
</nav>

The following example shows the EPUB 2 landmarks as expressed in the Package Document guide element.

<guide>
   <reference type="toc" href="toc.xhtml" title="Table of Contents"/>
   <reference type="text" href="chap01.xhtml" title="Start reading"/>
   <reference type="endnotes" href="notes.xhtml" title="Notes"/>
   <reference type="bibliogrpahy" href="biblio.xhtml" title="Bibliography"/>
   <reference type="glossary" href="glossary.xhtml" title="Glossary"/>
   <reference type="index" href="index.xhtml" title="Index"/>
</guide>

  Helpful Resources

The following resources explain EPUB and ARIA landmarks in more detail.

  4.4 Titles and Headings

  TITLES-001: Include publication and document titles

[WCAG 2.0] Success Criterion 2.4.2 requires that each Web page include a title. EPUB has a similar requirement for EPUB Publications: publications require a [DCMES] title element in the Package Document metadata. The [WCAG 2.0] requirement is not satisfied by the EPUB requirement, however.

When authoring an EPUB Publication each EPUB Content Document also requires a descriptive title that describes its content. If not provided, Assistive Technologies often will announce the name of the file to Users.

The following example shows a title for an EPUB Content Document.

<html …>
   <head>
      <title>Chapter 1</title>
      …
   </head>
   <body>
      <h1>Chapter 1: Loomings</h1>
      …
   </body>
</html>

If the title includes structural context (e.g., the part heading a chapter belongs to, or the name of the publication), order the title such that the most precise description of the current document comes first.

The following example shows a structured title.

<html …>
   <head>
      <title>
         III. The Night Shadows —
         Book the First—Recalled to Life — 
         A Tale of Two Cities
      </title>
      …
   </head>
   <body>
      <h1>III. The Night Shadows</h1>
      …
   </body>
</html>

For more information about titles, see Technique H25 [WCAG 2.0 Techs].

  TITLES-002: Ensure numbered headings reflect publication hierarchy

To a User, an EPUB Publication appears as a single document that they read from beginning to end, even though the content is often split across numerous EPUB Content Documents. As a result, their natural expectation is that the headings reflect their position in the overall hierarchy of the publication, despite the publication not actually being a single document (e.g., if a part heading is expressed in an [HTML] h1 element, each chapter that belongs to the part will have an h2 heading).

[WCAG 2.0 Techs] G141: Organizing a page using headings instructs Authors on correctly using numbered headings within a document, but with EPUB Publications the numbered headings also need to remain consistent across documents. Practically, this means that each EPUB Content Document does not have to begin with an h1 heading unless the first heading is a top-level heading — the first heading needs to have a numbered heading element relative to its actual position.

Authors also to need chunk their content so that the first heading in a document always has the highest number. For example, if a document starts with an h3 heading, there shouldn't be an h2 heading later in the document (e.g., do not include the start of a new section with the trailing subsections of the previous). It is acceptable for their to be subsequent headings at the same level as the first (e.g., multiple subsections in one document could all have h3 headings).

The following example shows two consecutive EPUB Content Documents in a textbook. The first contains a section heading (h2) and the first two subsections (h3). The second contains the final two subsections (h3).

<html …>
   …
   <body>
      <section>
         <h2>Section 1.1 - Conquest</h2>
         
         <section>
            <h3>Section 1.1.1 - First Encounter</h3>
            …
         </section>
         
         <section>
            <h3>Section 1.1.2 - Tensions Rise</h3>
            …
         </section>
      </section>
   </body>
</html>
<html …>
   …
   <body>
      <section>
         <h3>Section 1.1.3 - War</h3>
         …
      </section>
      
      <section>
         <h3>Section 1.1.4 - Aftermath</h3>
         …
      </section>
   </body>
</html>

  4.5 Descriptions

  DESC-001: Include alternative text descriptions

[WCAG 2.0] Success Criterion 1.1.1 requires a text alternative for all non-text content. In the case of image content, the provision of alternative text (e.g., in an [HTML] alt attribute) is sufficient for meeting the requirements of the [EPUB Accessibility] specification.

Authors are strongly encouraged to include extended descriptions, but the utility of extended descriptions often depends on the needs of the User. Until the publishing ecosystem matures, making it easier for Authors to include extended descriptions and write them to optimally meet the needs of the greatest number of Users, they are not required.

If extended descriptions are not included, note the omission in the accessibility summary.

note

The requirement for a text alternative does not apply to decorative images that contribute no information to the text. These are identified by an empty alt attribute.

caution

This guidance applies to the evaluation of EPUB Publications strictly for achieving conformance to the [EPUB Accessibility] specification. If an EPUB Publication is distributed in an environment where extended descriptions are required, this guidance for conformance will not be sufficient.

note

The use of alternative text as a sufficient description for all images may be removed in a future version of these techniques.

  Helpful Resources

The following documents provide guidance on including extended descriptions:

  DESC-002: Include descriptions for MathML content

Reading Systems typically do not provide self-voicing of [MATHML] markup, even when the equations can be rendered visually. Although polyfill scripts such as MathJax provide the ability to visually render MathML equations when scripting is supported, they do not provide an accessible alternative for non-visual readers. As a result, the inclusion of MathML markup alone is not sufficient to make equations accessible to non-visual readers.

EPUB 3 recommends the use of the altimg attribute to include a fallback image [Content Docs] for Reading Systems that cannot render the equations, but a visual fallback alone is not sufficient for all readers.

Due to these rendering limitations, inclusion of a description is recommend to complement the markup and also provide a text-accessible alternative.

A short description can be provided using the [WAI-ARIA 1.1] aria-label attribute on an [HTML] div or span element surrounding the MathML markup. For lengthier descriptions, use the aria-describedby attribute attribute.

note

Although the [MATHML] alttext attribute provides similar descriptive capabilities, it is not as well supported by Assistive Technologies as the ARIA attributes. If support increases in the future, this technique will be updated to also cite it as an option. Authors are not discouraged from also including the attribute, or from using it for other purposes (e.g., storing the description with its equation in content management systems).

The following example shows an aria-label attribute with a brief description of the math.

<div role="math" aria-label="twelve and three-fourths plus two and one-fourth equals fifteen">
   <math…>
      …
   </math>
</div>

The following example shows an aria-describedby attribute that references an extended description.

<div role="math" aria-describedby="mathdesc">
   <math…>
      …
   </math>
   <p id="mathdesc" class="hidden">
      left-parenthesis g of f right-parenthesis
      left-parenthesis x right-parenthesis
      Equals
      g left-parenthesis f left-parenthesis x
      right-parenthesis right-parenthesis
   </p>
</div>

  4.6 Accessible Alternatives

As EPUB Publications can be composed of more than one Rendition, it is possible that different versions of the content will have different levels of accessibility. For example, an image-based version of the content that lacks alternative text or descriptions could be bundled with a WCAG-compliant text-based serialization. This type of accessible bundling is acceptable, as [WCAG 2.0] allows non-conforming content provided a conforming alternate version is available.

The [Multiple Renditions] specification defines a set of features for creating these types of EPUB Publications. In particular, it specifies a set of attributes that allow a Reading System to automatically select a preferred Rendition for the User, or to provide the User the option to manually select between the available options. This functionality technically meets the requirements of [WCAG 2.0] in terms of ensuring the User can access the accessible version.

In practice, however, the [Multiple Renditions] specification is not broadly supported in Reading Systems at the time of publication. As a result, a User who obtains an EPUB Publication that contains more than one Rendition will only have access to the Default Rendition. Unless this Rendition is the accessible one, the EPUB Publication might not be readable by them.

Authors therefore need to use their best discretion when implementing this functionality to meet accessibility requirements. EPUB Publications that contain multiple renditions are conformant to the [EPUB Accessibility] specification if at least one Rendition meets all the content requirements, but Authors at a minimum need to note that a Reading System that supports multiple renditions is required in their accessibility summary. Any other methods the Author can use to make this dependence known is advisable (e.g., in the distribution metadata).

This section will be updated with techniques for using multiple renditions when there is enough support in Reading Systems to broadly recommend their use.

  5 EPUB Techniques

  5.1 Structured Audio Playback

  AUDIO-001: Identify skippable and escapable structures

The [SMIL] markup that underpins EPUB's [Media Overlays] playback functionality lacks the semantic richness of [HTML] markup. SMIL contains only two structural elements: seq for grouping and par for identifying synchronization points. As a result, when a User initiates synchronized playback, Reading Systems have limited information to work unless more detail is added by the Author.

To provide a richer reading experience, Authors need to mimic complex structures in the SMIL markup and add semantics to identify the structures using the type attribute [Media Overlays].

Without this additional semantic information, Reading Systems cannot provide a playback experience that allows Users escape from complex structures like tables and lists during playback (they will have to move forward one synchronization point at a time until they determine the structure is finished). Reading Systems also will have no way to tailor the reading experience so that secondary material, such as footnotes, can be automatically skipped.

The following example shows nested seq elements used to represent the rows and cells of a table.

<smil … xmlns:epub="http://www.idpf.org/2007/opf">
   <seq epub:type="table">
      <seq epub:type="table-row">
         <par epub:type="table-cell">
            …
         </par>
      </seq>
   </seq>
</smil>

The following example shows a par element identified as containing a footnote.

<smil … xmlns:epub="http://www.idpf.org/2007/opf">
   …
   <par epub:type="footnote">
      <text src="xhtml/chap01.xhtml#fn001>
      <audio src="audio/chap01.mp3" beginClip="0:29:12.28" endClip="0:31:43.95">
   </par>
   …
</smil>

  Helpful Resources

See the following sections in the [Media Overlays] specification for more information on structuring SMIL markup for accessibility:

  5.2 Page Markers

  PAGE-001: Provide page break markers

Both the EPUB Structural Semantics Vocabulary [Structure Vocab] and Digital Publishing WAI-ARIA 1.0 Module [DPUB Vocab] include a semantic for static page breaks: pagebreak and doc-pagebreak, respectively.

It is recommended that both semantics be applied to EPUB 3 content to ensure maximum compatibility with Reading Systems and Assistive Technologies.

The following example shows an HTML5 span element identified as a pagebreak.

<span id="page001" title="1" epub:type="pagebreak" role="doc-pagebreak"/>

A title or aria-label attribute is required on the element, as it provides the value that is announced to the User.

EPUB 2 does not include markup to identify static page break marks in the content. Page break destinations can be included to enable hyperlinking, but the page list is the only way a User can jump to the locations.

The following example shows an XHTML 1.1 span element used as a hyperlink destination.

<span id="page001"/>

Do not use the [HTML] a element to identify page break locations in EPUB 3 Publications. Although this element was previously defined as the anchor for a hyperlink destination, its purpose has been changed in [HTML] for use solely as a link.

  PAGE-002: Provide a page list

Including page numbers without a means of easily accessing the page break locations does not help Users navigate the content. A page list is a complementary piece to page numbering that provides a list of hyperlinks to each static page break location. When present, Reading Systems can provide users direct access to the list or use it to provide automatic page jump functionality.

The EPUB Navigation Document allows the inclusion of a page-list nav [Packages 3], while the EPUB 2 NCX file provides the same functionality through the pageList element [OPF2].

The following example shows an EPUB 3 page-list nav element that contains a list of links to the static page breaks.

<nav epub:type="page-list">
   <ol>
      <li><a href="georgia.xhtml#page001">1</a></li>
      <li><a href="georgia.xhtml#page002">2</a></li>
      <li><a href="georgia.xhtml#page003">3</a></li>
      …
   </ol>
</nav>

The following example shows an EPUB 2 NCX that contains a list of page break locations in its pageList.

<ncx xmlns="http://www.daisy.org/z3986/2005/ncx/"
     version="2005-1"
     xml:lang="en-US">
   …
   <pageList>
      <pageTarget id="p1" type="normal" value="1">
         <navLabel><text>1</text></navLabel>
         <content src="content.html#p001"/>
      </pageTarget>
      <pageTarget id="p2" type="normal" value="2">
         <navLabel><text>2</text></navLabel>
         <content src="content.html#p002"/>
      </pageTarget>
   </pageList>
</ncx>

  PAGE-003: Identify the source

Users typically want to know the source of the page break markers included in an EPUB Publication when they are derived from a static media. Considerations like which printing, by which publisher or imprint, and whether the pagination comes from the hard or soft cover edition will affect decisions about its usefulness (e.g., does it exactly match the pagination of a print book used in a classroom).

To allow Users to determine the suitability of the pagination, identify the ISBN of the source work in the Package Document metadata.

The following example shows a dc:source element containing the ISBN of the print source of pagination. This example is valid for both EPUB 2 and 3.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
   …
   <dc:source>urn:isbn:9780375704024</dc:source>
   …
</metadata>

If an ISBN is not available, include as much information as possible about the source publication (e.g., the publisher, date, edition, and binding).

The following example shows a dc:source element containing a text description of the source.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
   …
   <dc:source>ACME Publishing, 1945, 2nd Edition, Softcover</dc:source>
   …
</metadata>

If the page break markers are unique to the EPUB Publication, do not identify a print source.

  6 Distribution Techniques

  DIST-001: Do not restrict access through digital rights management

EPUB Publications typically require preservation of the publisher's and author's intellectual property when distributed (e.g., so that they can be made available for individual sale through online bookstores or distributed through library systems). The most common way to address this need has been through the application of digital rights management (DRM) schemes to the packaged EPUB Publication. DRM enables a variety of security features that aren't native to the EPUB format, such as the ability to limit access to a single User and to limit the length of time the person can access the publication (e.g., library loans).

In general, DRM can be made to work interoperably with Assistive Technologies, but problems arise when DRM restrictions remove direct access to an EPUB Publication or restrict access to the content within it. Unless the Reading System implementing the DRM provides API level access to the content, it can prove difficult, or even impossible, to generate text-to-speech playback, or for a refreshable braille display to have access to the underlying text, as well as cause other accessibility issues.

The application of digital rights management therefore must not impair or impede the functionality of Assistive Technologies on EPUB Publications Users have the right to access.

  DIST-002: Include accessibility metadata in distribution records

When an EPUB Publication is ingested into a distribution system, such as a bookstore or library, a metadata record is often provided separately to the distributor. In these scenarios, the metadata used to enable discovery of the publication typically comes from the distribution record alone, not from the metadata in the Package Document.

The result is that it is necessary to include as much accessibility metadata in distribution records as their vocabularies allow.

note

The use of distribution records does not remove the requirement to include accessibility metadata in the Package Document. The metadata in the Package Document ensures accessibility information is always available with the publication.

The following example shows an ONIX record with accessibility metadata that states that the EPUB Publication has no accessibility features disabled (10), a table of contents (11) and a correct reading order (13).

<ONIXMessage release="3.0">
   <Header>
      …
   </Header>
   <Product>
      …
      <DescriptiveDetail>
         <ProductFormFeature>
            <ProductFormFeatureType>09</ProductFormFeatureType>
            <ProductFormFeatureValue>10</ProductFormFeatureValue>
         </ProductFormFeature>
         <ProductFormFeature>
            <ProductFormFeatureType>09</ProductFormFeatureType>
            <ProductFormFeatureValue>11</ProductFormFeatureValue>
         </ProductFormFeature>
         <ProductFormFeature>
            <ProductFormFeatureType>09</ProductFormFeatureType>
            <ProductFormFeatureValue>13</ProductFormFeatureValue>
         </ProductFormFeature>
      </DescriptiveDetail>
      …
      <TitleDetail>
         <TitleType>01</TitleType>
         <TitleElement>
            <TitleElementLevel>01</TitleElementLevel>
            <TitleText>Accessible EPUB 3</TitleText>
         </TitleElement>
      </TitleDetail>
      …
   </Product>
</ONIXMessage>

  Helpful Resources

See the following resources for more information about including accessibility metadata in distribution records:

  Acknowledgements and Contributors

This section is informative

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB Accessibility specification and techniques were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:

Work on these documents was undertaken by an accessibility subgroup led by:

Active members of the working group included:

IDPF Members

Invited Experts/Observers

For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3 Overview].

  References

Normative References

[Content Docs] EPUB Content Documents 3 .

[DPUB Vocab] Digital Publishing WAI-ARIA Module 1.0 . Matt Garrish, et al.

[EPUB Accessibility] EPUB Accessibility .

[HTML] HTML .

[MATHML] Mathematical Markup Language (MathML) Version 3.0 . David Carlisle, et al. 21 October 2010.

[Media Overlays] EPUB Media Overlays 3.1 .

[Packages 3] EPUB Packages 3 .

[SMIL] SMIL Version 3.0 . D. Bulterman, et al. 01 December 2008.

[WAI-ARIA 1.1] Accessible Rich Internet Applications (WAI-ARIA) 1.1 . Joanmarie Diggs, et al.

[WCAG 2.0] Web Content Accessibility Guidelines (WCAG) 2.0 . Ben Caldwell, et al.

[WCAG 2.0 Techs] Techniques for WCAG 2.0. . Michael Cooper, et al.

[schema.org] schema.org.

Informative References

[EPUB3 Overview] EPUB 3.1 Overview . Garth Conboy, et al.

[Multiple Renditions] EPUB Multiple-Rendition Publications 1.0 . 26 August 2015.

[SWF] SWF File Format Specification Version 19 . 2012.

[W3C Accessibility Note] Digital Publishing and Accessibility in W3C Documents . 03 May 2016.