EPUB Accessibility Techniques defines discovery and content accessibility requirements for EPUB® Publications.
This document, EPUB Accessibility Techniques, provides informative guidance on how to understand and apply the discovery and accessibility requirements defined in the EPUB Accessibility 1.1 specification [[epub-a11y-11]] that are unique to EPUB publications.
This document does not cover general web accessibility techniques already addressed in [[wcag2]] and [[wai-aria]], for example, for which no substantive differences in application exist. Following those techniques, as applicable, is also essential to meeting the accessibility requirements of the EPUB Accessibility 1.1 specification.
This document is not intended to be read in isolation, in other words, as it does not define conformance requirements for making accessibility claims or cover every method for producing accessible content. An EPUB publication must meet all the requirements of EPUB Accessibility 1.1 to make a claim of accessibility. Verifying only the techniques in this document does not mean an EPUB creator can claim conformance to EPUB Accessibility 1.1.
This document uses terminology defined in EPUB 3.3 [[epub-3]] and EPUB Accessibility 1.1 [[epub-a11y-11]]:
Only the first instance of a term in a section links to its definition.
The accessibility techniques described in this document are advisory in nature. They are intended to help EPUB creators create EPUB publications that conform to the requirements in [[epub-a11y-11]], 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 [[dpub-accessibility]]. As solutions become available, they will be incorporated into the appropriate document, whether this one or one it refers to.
If EPUB creators 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 [[wcag2]] and [[wai-aria]] requirements can be raised. The W3C Publishing Community Group issue tracker can be used to ask for support implementing EPUB-specific requirements and the EPUB 3 Working Group's issue tracker to report issues with this document.
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.
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 applicable mode.
Do not list access modes for content that does not contain information necessary to
understand a publication. Most EPUB publications contain cover images, for example, but it is not
necessary to see the cover image to read the publication. The same is true of publisher logos and
images in the content are only for presentational purposes (i.e., have no information so have empty
[[html]] alt
attribute values). If these are the only visual content, then it is not
valid to list a visual access mode. Similarly, if the only audio an EPUB publication contains is
background music (e.g., for an instructional video with text captions, or as mood music while
reading), listing an auditory access mode is not valid.
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
Property [[a11y-discov-vocab]] for more information about this
property and its values.
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 all the individual modes, and sets of modes, that allow a user to read a publication. Sufficient access modes account for the affordances and adaptations that the EPUB creators have provided, allowing users to determine whether they can the read content 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.
The most strongly recommended sufficient access modes to list are the ones that consist of only a single value. Users seeking alternatives to the default encoding of the information typically want to read the content without switching reading modes (e.g., they want a purely textual alternative to use text-to-speech playback or an auditory alternative to listen to prerecorded narration). Listing the single value sets allows users to easily determine whether a publication will meet their reading needs.
The most common single sufficient access modes for EPUB publications are:
textual
— setting this value indicates that the publication is screen-reader
friendly (i.e., all the content is available for text-to-speech rendering by an assistive
technology). EPUB creators can set this value for EPUB publications that conform to Level A [[wcag2]] or higher, for example, as
there must be textual alternatives for non-text content to meet these thresholds.auditory
— setting this value indicates that pre-recorded audio is available
for the publication. EPUB creators can set this value for EPUB publications that provide media
overlays for all the content.As an example of setting sufficient access modes, consider an EPUB publication that contains graphics
and charts, as well as descriptions for all these images. The publication has both textual and
visual content, so the EPUB creator will
include the following schema:accessMode
metadata entries to indicate this:
<meta property="schema:accessMode"> textual </meta> <meta property="schema:accessMode"> visual </meta>
This metadata does not make clear whether a textual access mode is sufficient to read the entire publication, or whether a visual one is, only that the user requires the ability to read in those two modes by default. This discrepancy is why sufficiency is also important to know.
Since the EPUB creator has also included textual alternatives and/or descriptions for all the images in the example publication, the metadata can also indicate that a purely textual access mode is sufficient to read the content:
<meta property="schema:accessModeSufficient"> textual </meta>
Without this metadata, users would not have known that they could read the publication only via its textual content.
It is important to emphasize when listing individual values in the
schema:accessModeSufficient
property not to simply restate each individual access
mode. When adding a schema:accessModeSufficient
property with only a single value,
all information in the publication must be available in that mode.
For example, the EPUB creator would not declare a sufficient access mode of "visual
" for
the example publication as the information is not entirely available in image-based form. (Photo
books without text would be examples of works with a purely visual sufficient access mode.)
EPUB creators may also list any sets of sufficient access modes that allow full access to the information. As the most typical set of values is the combination of all the access modes, however, the information this provides users is less helpful in determining the usability of a publication.
For example, the metadata the EPUB creator inputs for the example publication re-establishes that there is a textual and visual reading option:
<meta property="schema:accessModeSufficient"> textual,visual </meta>
The order in which EPUB creators list the access modes in a set is not important. The only requirement is to separate the values by commas.
The complete set of schema:accessMode
and schema:accessModeSufficient
entries for the example publication 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 EPUB creator 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 EPUB creator 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
Property [[a11y-discov-vocab]] for more information
about this property and its values.
The accessModeSufficient
property, as defined in [[schema-org]], allows more
complicated expressions than can be represented in the EPUB 2 or 3 package document (e.g.,
definition of lists of values and inclusion of a human-readable description). A future version
of EPUB might allow for richer metadata, but the basic expression shown in this section is
sufficient for discovery purposes.
Setting the correct access modes and sufficient access modes for EPUB 3 publications that contain synchronized text-audio playback requires evaluating whether playback is essential to reading the publication or an additional feature.
EPUB 3's media overlays [[EPUB-3]] allows EPUB creators to synchronize the full text of a publication with full audio narration. These types of publications are commonly referred to as "read aloud" books, as the user chooses whether or not to turn on the narration (unlike traditional audiobooks where only the audio is available).
In this case, because the audio playback is an extra feature, EPUB creators would
not list "auditory
" as an access mode.
Rather, they would indicate the presence of text and audio synchronization as an accessibility feature:
<meta property="schema:accessibilityFeature"> synchronizedAudioText </meta>
Although the audio is not essential to reading the publication, having full audio playback capability
means that there is an auditory sufficient access mode —
the user can listen to the complete publication. Consequently, the EPUB creator would declare a
schema:accessModeSufficient
property with the value auditory
:
<meta property="schema:accessModeSufficient"> auditory </meta>
When media overlays are present, EPUB creators should not add "auditory
" to all the
possible sufficient access modes just because it is possible to turn on text-audio playback.
For example, a publication with media overlays that has text and images (with text alternatives)
would only declare the following sufficient access modes: "textual
",
"auditory
, and "textual,visual
".
It would not declare "textual,auditory
" or
"textual,visual,auditory
".
Another use for media overlays — more typical among accessible republishers such as libraries that serve blind and low vision readers — is to provide full audio synchronized to the major headings of a publication. These types of publications are more like traditional audiobooks, as all the information in the work is typically available in auditory form. The minimal text does not allow meaningful visual reading or text-to-speech playback; it is only to provide structured navigation capabilities.
In this case, being able to hear the audio is essential to being able to read the publication, so EPUB creators will list an auditory access mode:
<meta property="schema:accessMode"> auditory </meta>
In a reverse of the first case discussed, EPUB creators will not identify text-audio synchronization as a feature of the publication since the amount of text provided is trivial.
Likewise, since the text in the publication only provides heading navigation, EPUB creators will not list a textual access mode. The user does not need to, and is not expected to, visually read this text.
Some publications that provide the body in auditory form may include the backmatter in text form, allowing users to use text-to-speech playback to render it. In this case, there would be a textual component.
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 alone 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 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.
Be aware that although the vocabulary for the accessibilityFeature
property [[a11y-discov-vocab]] contains the values
"none
"
and "unknown
", these terms cannot be used to meet the reporting requirements
for the property. Authors must indicate at least one feature that is not one of these values to
claim conformance to EPUB Accessibility 1.1 [[epub-a11y-11]].
Refer to The
accessibilityFeature
Property [[a11y-discov-vocab]] for more information
about this property and its values.
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 Guideline 2.3 [[wcag2]].
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 or parallax scrolling with CSS).
sound — certain sound patterns, such as ringing and buzzing, can cause seizures, while loud or sudden changes in volume can also negatively affect users.
EPUB creators have to report whether their EPUB publications contain resources that present any of these hazards to users, as they can have real physical effects.
What precisely constitutes a sound hazard, and how to test for these hazards, is not standardized as of publication of this document. EPUB creators will have to use their discretion on when to specify a sound hazard until additional guidance is developed. This technique will be updated whenever there is more clarity on this issue.
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. To indicate that hazards are not present, use the values
"noFlashingHazard
", "noMotionSimulationHazard
", and
"noSoundHazard
".
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. The value
"none
" can be used in such cases instead of repeating each non-hazard. When the
"none
" value is used, no other hazards values may be specified.
If an EPUB publication contains a hazard, provide additional information about its source and nature in the accessibility summary.
If an EPUB creator cannot determine if a publication presents a specific hazard for users, list that
hazard as unknown. The following values are used to identify individual unknown hazards:
"unknownFlashingHazard
", "unknownMotionSimultationHazard
", and
"unknownSoundHazard
".
For example, determining whether sound hazards are present can be challenging as the causes are
currently not well defined. In this case, EPUB creators may prefer to set the
"unknownSoundHazard
" value, as in the following example.
If it is not possible to determine any hazards, the value "unknown
" can be used in place
of setting the individual hazards to unknown. This value should be used sparingly, however, as it is
of no value to users. EPUB creators should make every effort to determine if hazards are present.
When the "unknown
" value is set, no other hazard values may be specified.
EPUB creators must ensure that information about all three types of hazards is included when not
using the "unknown
" or "none
" values.
Refer to The
accessibilityHazard
Property [[a11y-discov-vocab]] for more information
about this property and its values.
An accessibility summary provides a brief, human-readable description of the accessibility characteristics of an EPUB publication that cannot be expressed through the other discovery metadata.
The accessibility summary should not simply repeat the conformance information provided in the
dcterms:conformsTo
property, for example, or the features listed in the
schema:accessibilityFeature
properties. When other accessibility metadata is
present in the package document, systems that process EPUB publications can already present it to
users. Repeating it in the summary only makes them hear the information again.
EPUB creators should not include an accessibility summary when they have nothing more to add to the conformance claim and other discovery metadata.
If an EPUB publication does not meet the requirements for content accessibility in [[epub-a11y-11]], the reason(s) it fails should be noted in the summary. Similarly, if an EPUB creator is hesitant to make a formal claim of conformance, the reasons why can be explained in the summary.
An accessibility summary is provided using the [[schema-org]] accessibilitySummary
property.
Do not repeat this property to provide translations of a summary. EPUB does not define a method for
including translations. Putting different xml:lang
attributes on properties does not
indicate a translation and could lead to wrong summary being rendered to users.
Refer to The
accessibilitySummary
property [[a11y-discov-vocab]] for more
information.
The use of the schema:accesibilityAPI
property is no longer necessary for EPUB publications. EPUB creators are not responsible for
the interaction between reading
systems and the underlying platform APIs.
Meeting the requirements of [[wcag2]] is a better measure of the accessibility of scripting, as this property does not differentiate between ARIA markup used for document structure or for identifying controls.
The use of the schema:accesibilityControl
property is no longer necessary for EPUB publications. This property
does not differentiate issues arising from the reading system interface from
those in the underlying content, which has led to confusion about its use.
Meeting the requirements of [[wcag2]] will mitigate most known issues with the content and is sufficient for authoring purposes.
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.
Techniques for meeting the requirements of the [[wcag2]] are defined in Techniques for WCAG. This document does not repeat those 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 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).
EPUB creators not familiar with [[wcag2]] 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:
DAISY Accessible Publishing Knowledge Base — compendium of best practices by content type, with links to the applicable WCAG techniques.
BISG Guide to Accessible Publishing & Cheat Sheets — includes a set of top practices for making content accessible.
Success Criterion 1.3.2 [[wcag2]] specifies that each web page have a meaningful order (i.e., that the visual presentation of the content match the underlying markup).
As EPUB allows two EPUB content documents to be rendered together in a synthetic spread [[epub-3]], the order of content within a single document cannot always be evaluated in isolation. Content may span visually from one document to the next. For example, a sidebar might span the bottom of two pages.
Ordering each document separately by the visual display will lead to users of assistive technologies encountering gaps between the start and end of the spanned text. If the markup cannot be arranged to provide a more logical reading experience (e.g., the beginning of the spanned content at the end of the first page followed by the conclusion at the start of the next), another means of satisfying this criteria will be necessary to avoid failure (e.g., a hyperlink could be provided to allow a user to jump from the break point on the first page to the continuation on the next).
Success Criterion 2.4.5 [[wcag2]] 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 EPUB creators follow the EPUB requirements to include all EPUB content documents in the spine and ensure access to all non-linear documents [[epub-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 EPUB 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 [[epub-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 EPUB creator cannot provide, so users also have a third option available in most cases.
Although EPUB creators only need to follow EPUB requirements to meet this criterion, they are still encouraged to provide additional methods to improve access beyond the minimum. Some suggestions include:
adding at least one link to every EPUB content document in the spine to the table of contents, when feasible;
adding an index to locate major topics; and
adding additional navigation aids to the EPUB navigation document (e.g., lists of figures and tables).
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 several 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 EPUB creators will trim headings below a certain depth to improve the readability. Further, reading systems do not always provide structured access to the headings in the table of contents, or provide shortcuts to navigate the links. The result is that users have to listen to each link one at a time to find where they want to go, a tedious and time-consuming process.
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 EPUB creators 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; and
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).
The table of contents provides users more than just links into the content. It is also a means to understand the structure and ordering of an EPUB publication. Consequently, users may have difficulty locating where they are in a publication, where they want to go, and also how to return to previous locations when the order of entries in the table of contents does not match the linear reading order.
EPUB creators should therefore ensure that the entries in the table of contents always match the linear order of the content. Specifically, the order of entries should reflect both:
Only if there is a logical case for an alternative arrangement of entries should the ordering differ. Such scenarios typically only occur when the content does not have to be read linearly or when additional information is included at the end of a table of contents. For example, the table of contents for a magazine might be ordered to list all the major articles first, followed by features, etc.
When the ordering of the table of contents does not match the content, EPUB creators should include an explanation why in the accessibility summary.
EPUB creators should avoid including links to supplementary content at the end of the table of contents. Links to figure, tables, illustrations and similar content is better included as a separate navigation elements (either in the EPUB navigation document or in the spine). EPUB creators can include links to these additional navigation lists in the table of contents.
Web sites are constructed very differently from EPUB publications. A typical web site wraps the content of each page within a repeating template, for example. This template gives each page a consistent look and feel, but users are rarely interested in the wrapper content after visiting the first page. Visual readers can typically skip past the site header, navigation bars, search boxes, and other helpful but seldom-used features to get right to the content.
To provide the same ease of access to readers who would have to navigate sequentially through the repetitive content, success criterion 2.4.1 [[wcag2]] requires a means of bypassing the repeated content in a set of pages. This success criterion does not apply to typical EPUB publications, however, as EPUB content documents do not repeat content in the same way that web sites do.
Each new content document may begin with similar content, such as learning objectives or key terms, but this content is part of the body of the publication and not identical to what came before. Consequently, it is not required to add a link to skip it. (Secondary content should be identified in accordance with success criterion 1.3.1, however.)
If an EPUB publication were to reproduce a set of web pages with their full site trappings, then success criterion 2.4.1 would apply, but this practice is not common.
epub:type
The following guidance is only for EPUB content documents.
The type
attribute is the only means of adding structural information to media overlay
documents so that features like lists and tables can be navigated more efficiently.
It is also required in the EPUB navigation
document to identify key structures.
Although the role
attribute may seem similar in nature to the type
attribute [[epub-3]], their target uses in EPUB content documents do not
overlap.
The key difference between these attributes is that the role
attribute bridges
accessibility in content 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 not necessary that they be used together.
Due to the lack of restrictions on where EPUB creators can use the type
attribute, pairing the attributes may cause
accessibility issues (e.g., putting roles on the [[html]] body
element).
In particular, the use of the type
attribute is not a means of satisfying
requirements for ARIA roles in WCAG.
For EPUB creators looking to move from the type
attribute to using ARIA roles, the
EPUB Type to ARIA Role
Authoring Guide guide details notable authoring differences between the two attributes.
It also includes a mapping table of semantics in the EPUB Structural Semantics Vocabulary to
equivalent ARIA roles in [[dpub-aria-1.0]] and [[wai-aria]].
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 in reading systems (i.e., to minimize the time the user has to wait for a document to appear). It is rare, at least for books, for an EPUB publication to contain only one EPUB content document with all the content in it.
When content is chunked in this way, it often requires the EPUB creator to make decisions about how best to restructure the information. A part, for example, will typically not include all the chapters that belong to it. The EPUB creator will instead separate the part heading from each chapter, putting each into a separate document.
Although visually these restructuring decisions can be hidden from readers, they impact the functionality of assistive technologies. In the case of [[wai-aria]] 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, EPUB creators 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). All this practice does, however, is add repetition
that is not only disruptive when reading but can make the structure of the publication harder to
follow. EPUB creators 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:
<html … > … <body> <section role="doc-part" aria-labelledby="p1"> <h1 id="p1">Part 1</h1> <section role="doc-chapter" aria-labelledby="c1"> <h2 id="c1">Chapter 1</h2> … </section> … </section> … </body> </html>
When more than one instance of a role is included in a document, each must be uniquely
identified. The aria-labelledby
attribute provides the name of each landmark in
the preceding example. The attribute is not required if only one instance is present, so it
is omitted from the following examples.
Since this would lead to a large content file, the part heading is typically split out into its own EPUB content document so that it will appear on its own page:
<html … > … <body> <section role="doc-part"> <h1 id="p1">Part 1</h1> </section> </body> </html>
Each chapter is then separated into a separate EPUB content document:
<html … > … <body> <section role="doc-chapter"> <h2>Chapter 1</h2> … </section> </body> </html>
If another section
tag were added around the chapter in the preceding example to
indicate it is in part one (e.g., using the aria-label
attribute so the heading is
not visible) users would hear "Part 1 Part 1 Chapter 1" because "Part 1" is also the heading in
the document that precedes the first chapter.
[[wai-aria]] landmarks are similar in nature to EPUB landmarks [[epub-3]]: both are designed to provide users with quick access to the major structures of a document, such as chapters, glossaries and indexes. ARIA landmarks are compiled automatically by assistive technologies from the roles that have been applied to the markup, so EPUB creators 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 EPUB 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 compiled by the EPUB creator prior to distribution, and
are not directly linked to the use of the type
attribute [[epub-3]] 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 EPUB creators 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 resources explain EPUB and ARIA landmarks in more detail.
EPUB 2 guide element
EPUB 3 landmarks nav
ARIA landmarks
Success Criterion 2.4.2 [[wcag2]] requires that each web
page include a title. EPUB has a similar requirement for EPUB publications: publications
require a [[dcterms]] title
element in the package document metadata. The
[[wcag2]] 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.
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.
For more information about titles, see Technique H25.
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).
Technique G141: Organizing a page
using headings instructs EPUB
creators 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 that reflects its actual position in the
publication.
EPUB creators also need to 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
should not 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 there to
be subsequent headings at the same level as the first (e.g., multiple subsections in one
document could all have h3
headings).
Success Criterion 2.4.6 [[wcag2]] currently states that all headings must describe their topic or purpose. The implication of this wording is that all chapters in a novel, for example, have a topic or purpose and that the topic or purpose is always clearly reflected by the title of the chapter. Not only is this not always the case, but this success criterion also complicates the use of chapter numbers as headings since these do not establish a topic.
After discussion in the Accessibility Guidelines Working Group's issue tracker, it is clear that the understanding document for 2.4.6 captures the intent of the success criterion better than the current wording — namely, that the requirement for headings is only that they establish a unique context for the content.
By this interpretation, the headings in publications should always pass provided they are unique.
It is expected that the wording of the success criterion will be updated to better reflect the uniqueness requirement, likely in the future WCAG 3 due the complexities of changing the wording for WCAG 2.
The first version of these techniques only required alternative text for images regardless of their complexity. This exception is no longer valid.
EPUB creators must now ensure that their image-based content meets [[wcag2]] requirements for alternative text and extended descriptions to conform with [[epub-a11y-11]].
The following documents provide guidance on including extended descriptions:
DIAGRAM Image Guidelines for EPUB 3 — recommendations for the inclusion of alternative text and extended descriptions.
Success Criterions 3.1.1 and 3.1.2 [[wcag2]] deal with the language of a page and changes of language with in, respectively.
For EPUB publications, the package document is also an important source of metadata information about the publication. For example, reading systems expose details of the publications to users in their bookshelves using this information.
Consequently, it is necessary to provide the language of all text content in the package document
to conform with these WCAG success criteria. The easiest way to meet this requirement is to add
an xml:lang
attribute on the root package
element
[[epub-3]].
If individual metadata fields within the package document are expressed in a different language,
it is similarly required that the language change be identified by an xml:lang
attribute on the element for the field.
Providing this information enables reading systems to correctly render the text content in the proper language for users.
The languages specified in the package document have no effect on individual EPUB content documents (i.e., the language of each document must be specified using the language expression mechanisms it provides).
In addition to being able to express the language of text content, the package document also allows EPUB creators to identify the
languages of the EPUB publication
in dc:language
elements [[epub-3]].
Although it is not strictly required to set this information to meet Success Criterion 3.1.1 [[wcag2]], as it is non-normative, it should be considered a best practice to always set this field with the proper language information. (Note that EPUB3 requires the language always be specified, so omitting will fail validation requirements.)
Although reading systems do not use this language information to render the text content of the EPUB publication, they do use it to optimize the reading experience for users (e.g., to preload text-to-speech engines so users do not have a delay when synthesizing the text).
The languages specified in the package document have no effect on individual EPUB content documents (i.e., the language of each document must be specified using the language expression mechanisms it provides).
Success Criterion 1.1.1 [[wcag2]] requires that text equivalents be provided for all non-text content to meet Level A. In some regions (e.g., Asia), it is not uncommon to find images of individual text characters, despite the availability of Unicode character equivalents. This practice occurs for various reasons, such as ease of translation of older documents and for compatibility across reading systems. The use of images in most instances leads to the text not being accessible to non-visual users, however.
When individual characters are replaced by images, there is invariably a negative effect on text-to-speech playback, even when alternative text is provided (e.g., if single characters within a word are replaced by images, the word will not be read as a single unit of text). It is also problematic for visual users, as the images often scale poorly and the characters cannot be changed to different font families to meet user preferences.
The use of Unicode characters for all text content avoids this problem, allowing content to successfully meet the minimum requirement for Level A.
For compliance with Level AA, EPUB creators are directed to Success Criterion 1.4.5 which further restricts the use of images of text to only a set of essential cases.
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 [[wcag2]] allows non-conforming content provided a conforming alternate version is available.
The [[epub-multi-rend-11]] specification defines a set of features for creating these types of EPUB publications. 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 [[wcag2]] in terms of ensuring the user can access the accessible version.
In practice, however, the [[epub-multi-rend-11]] 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. Unless this rendition is the accessible one, the EPUB publication might not be readable by them.
EPUB creators 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-a11y-11]] specification if at least one rendition meets all the content requirements, but EPUB creators at a minimum need to note that a reading system that supports multiple renditions is required in their accessibility summary. Any other methods the EPUB creator 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.
Ensuring the complete text of an EPUB publication is synchronized with audio is key to allowing users who require full synchronized playback, or even audio-only playback, have access to the same information as users who do not require synchronized playback.
EPUB 3's media overlays feature [[epub-3]] allows audio to be synchronized with any element in an EPUB content document, so there is no technical barrier to providing synchronized playback.
The primary consideration for this objective is what constitutes the text content of an EPUB publication. The minimal candidates for synchronization with audio are all the elements with visible text content.
In HTML, the class of elements called [=palpable content=] [[html]] can typically be synchronized
with audio or have their own built-in audio. Embedded text in SVG documents, on the other hand,
is found in the text
element [[svg]] and its descendants.
The media overlays text
element is used to reference these elements, either to play back the pre-recorded audio
in a sibling audio
element [[epub-3]] or to initiate playback of an audio or video element if the
audio
element is missing (e.g., for embedded audio and video in the
document).
EPUB creators should not synchronize hidden text content in an alternative presentation like media overlays. Synchronizing audio with invisible text will be confusing for sighted readers following the playback.
Text content in a collapsed element, like the details
element [[html]], is not considered hidden content.
In addition to synchronizing the visible text, synchronized text-audio playback must also address text alternatives for image-based content. Images may have alternative text and descriptions that are not visible to all users. As synchronization is also meant to aid users who cannot see the images, including these text alternatives and descriptions in the playback is essential to providing the user all the information in the EPUB publication.
Text alternatives and descriptions in HTML may be represented in the alt
attribute [[html]] and linked by ARIA
attributes (e.g., aria-describedby
and
aria-details
[[wai-aria]]).
Descriptions for image elements in SVG are typically represented in a desc
element but
ARIA attributes may also be used.
The default reading order should typically represent the order in which reading systems render content to users during synchronized text-audio playback. For EPUB publications, this is a combination of the sequence of EPUB content documents in the spine and the order of elements within each EPUB content document.
If there are cases where the logical reading order (how a reader would naturally read the
content) diverges from the default reading order, EPUB creators can order the playback sequence
of seq
and par
elements in a media overlays document [[epub-3]]
to match the logical order.
EPUB creators need to use caution when making alterations, however, as other accessibility issues can arise when the logical order does not match the default order. For example, the content may not be accessible to users of assistive technologies when the order in the markup does not match how the assistive technology reads the content. In these cases, using playback to create a logical order can make the EPUB publication fail WCAG conformance requirements.
One case where the logical may diverge from the reading order and remain accessible is in tables, as assistive technologies typically allow users to choose whether to read by row or by column.
Some content elements are not critical to read when following the primary narrative of a work, and that would interrupt a user's concentration if they had to stop and listen to. Footnotes and endnotes are examples of such content, as users may only want to come back and read this content after finishing the EPUB publication. The announcement of page break numbers can be similarly annoying to readers.
EPUB 3's media overlays feature
[[epub-3]] does not allow reading
systems to determine if playback sequences are skippable unless EPUB creators add additional
semantics to the markup, however. EPUB creators must use the epub:type
attribute [[epub-3]] to add semantics to seq
and par
elements [[epub-3]], thereby allowing reading systems to provide
users the option to skip their playback sequences.
The recommended structures to identify for skippability are:
endnotes
and
endnote
semantics [[epub-ssv-11]]
for groups of notes and individual endnotes, respectively.footnotes
and footnote
semantics [[epub-ssv-11]]
for groups of footnotes and individual footnotes, respectively.pagebreak
semantic [[epub-ssv-11]] to identify each.EPUB creators may identify other structures but it is not necessary to meet this requirement.
Some content elements are containers for expressing complex information. A table, for example, has data arranged in rows and cells. Lists similarly may contain many items. While users may be interested in some of the information in these structures, they also often want to escape from them to keep reading, not have to listen to the entire content before being able to move on. These are called escapable elements, because the user needs to be able to escape from them whenever they choose to simplify the reading experience.
EPUB 3's media overlays feature
[[epub-3]] only supports escapability if EPUB creators add structural semantics to the markup. EPUB creators must use the epub:type
attribute [[epub-3]] to add semantics to seq
and par
elements
[[epub-3]] to allow reading
systems to provide users the option to escape their playback sequences.
The recommended structures to identify for escapability are:
figure
semantic
[[epub-ssv-11]] to identify each.list
semantic
[[epub-ssv-11]] to identify each.aside
semantic
[[epub-ssv-11]] to identify each.table
semantic
[[epub-ssv-11]] to identify each.EPUB creators may identify other structures but it is not necessary to meet this requirement.
Identifying nested escapable structures is not recommended at this time. Refer to Escapability [[epub-3]] for more information.
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.
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.
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.
See the following resources for more information about including accessibility metadata in distribution records:
Note that this change log only identifies substantive changes since EPUB Accessibility Techniques 1.0 — those that affect the conformance of EPUB publications or are similarly noteworthy.
For a list of all issues addressed in this version, refer to the working group's issue tracker.
a11y:pageBreakSource
property. See issue 2626.pageNavigation
accessibility feature when a page list
is included. See issue 2626.pageBreakMarkers
accessibility feature not
printPageMarkers
. See issue
2626.role
attribute is most important for making page break
markers accessible. See issue 2621.none
and unknown
terms do not meet the
reporting requirements for accessibilityFeature
. See issue 2537.xml:lang
attribute on an
accessibilitySummary
property does not represent a translation. See pull request 2401.accessibilitySummary
explanation to avoid repeating
information available in the other metadata. See issue 2399.accessModeSufficient
declarations. See issue 2302.epub:type
attribute does not have to be used in coordination, nor that roles are required where
epub:type
is used.source-of
property in EPUB 3 to identify
which dc:source
element is the source of pagination. See issue 1600.