Setting 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.

For a user to determine whether an EPUB publication is suitable for their needs, they need to know which access modes are required to consume the content. List all applicable access modes in the schema:accessMode property [[schema-org]], repeating the property for each applicable mode. Do not group all the access modes together in a single tag.

The order in which the access modes are declared currently does not carry any meaning, but best practice is to list the access modes by their relevance to reading the content. For example, if a book is primarily text but has some images, list textual first and visual second.

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.

Primary access modes

The primary access modes are the ones that directly capture how the information necessary to read and understand a publication is encoded. They do not include affordances to make content accessible, such as alternative text and extended descriptions to make visual content readable. The following sections explain when to apply each of the primary access modes.

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

Visual content indicators

The visual content indicators are a special class of access mode that extend the visual access mode. They provide additional information about the type of content that is encoded as images.

The most common method of encoding visual content in EPUB is as images. Although support for MathML has improved in recent years, it is still common, for example, to find math equations in EPUB publications represented as images to ensure their rendering. Informing users who are blind that a publication has images of math lets them know that they will have to rely on alternative text and extended descriptions instead of being able to inspect the equations in the kind of detail that MathML allows. It is also an aid to visual readers, as it indicates that the text cannot be resized (only zoomed) or have its appearance changed as necessary to make it more accessible.

But the visual content indicators are not exclusive to image formats. If a video has information that requires color perception to understand, for example, a color dependence indicator could be set. Or if an interactive chart is drawn on an [[html]] [^canvas^] element, the chart on visual could be set.

More than one visual content indicator can apply to an piece of visual content. A publication with an image of a chart that uses color to represent the data, for example, would include both the chart on visual and color dependence indicators. When declaring visual content indicators, make sure to check a publication's visual content for all that apply.

As the visual content indicators are a supplementary piece of information, their use is only advisory. It is more important to ensure that a visual access mode is set, and a declaration of a visual content indicator must never occur without a declaration a visual access mode accompanying it.

The following sections describe the visual content indicator types and how to apply them.

Setting sufficient access modes

The access modes sufficient to consume an EPUB publication express a broader picture of the potential usability than do the primary access modes. The primary access modes identify the default nature of the media used in the publication (e.g., that it has text and images). Sufficient access modes, on the hand, account for all the ways that a user can read that content.

Another way of thinking of the difference between the primary access modes and the sufficient access modes is that the sufficient access modes also account for the affordances and adaptations that have been provided. They allow users to determine whether the content can be read in a manner that is more useful to them. For example, a user with a screen reader will want to know if a book that consists of text and images can also be read entirely as text without loss of information — that there is alternative text and extended descriptions for the visual content.

Sufficient access modes are identified in the schema:accessModeSufficient property [[schema-org]].

Unlike the other Schema.org metadata expressed in the EPUB 3 package document, sufficient access modes can consist of one or more values separated by a comma and optional space. Because sufficient access modes are telling users the different ways that the content can be read, each set is expressed in a separate tag rather than each individual value.

The most common reason for having multiple schema:accessModeSufficient declarations is to capture both the default nature of a publication as well as the alternative reading pathways available. For example, that a book with textual and visual content is also fully readable as text.

Note that sufficiency of access is often a subjective determination based on an 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 visual or auditory losses might be considered inconsequential if a transcript provides all the necessary information to understand the concepts being conveyed.

Single reading modes

Although sufficient access mode are expressed as sets consisting of one or more values, the most strongly recommended sets to list are the ones that in fact consist of only a single value. The reason why these are the most important is that they tell users that all the content can be read in the specified method.

Someone who is blind, for example, might want to know that all the content is available in text form so they can use an assistive technology or their reading system's built-in read aloud functionality to read the book. Or they might want to know that all the content is available as pre-recorded audio for enhanced legibility. They are going to be less interested that if you can perceive text, visual, and auditory content that you can also read the book (even though this is the default sufficient access mode based on the primary access modes), as the visual content is problematic without the provision of alternative text and long descriptions.

The possible single sufficient access mode values are identical to the primary access modes:

textual

Setting this value indicates that information necessary to read a publication is available in textual form.

Unlike a textual primary access mode, the inclusion of text alternatives such as alternative text, extended descriptions, closed captions, and transcripts does allow a textual sufficient access mode to be set.

When textual is the only sufficient access mode set, it means that all the information necessary to read the publication is available in textual form, so it is generally interpreted as indicating that the publication is screen-reader and dynamic braille display friendly.

A single textual sufficient access mode can be set 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 information necessary to read a publication is available as prerecorded audio (whether prerecorded human speech or synthetic speech).

When auditory is the only sufficient access mode set, it means that all the information necessary to read the publication is available as prerecorded audio.

A single auditory sufficient access mode typically indicates that media overlays have been used to provide audio for all the text and visual content, but it could also set if, for example, a book of poetry also contained (non-synchronized) recordings for each poem.

visual

Setting this value indicates that information necessary to read a publication is available in visual form, such as images and video.

When visual is the only sufficient access mode set, it means that all the information necessary to read the publication is available in visual form. It is most often applied to works like comics and manga.

A single visual sufficient access mode is typically the least accessible single sufficient access mode that can be set, as it indicates that only sighted readers can access the information of the publication. It does not, by itself, mean the publication is not accessible, but there would need to be another single sufficient access mode declaration to indicate the publication is readable by non-visual users.

tactile

Setting this value indicates that information necessary to read a publication is available in tactile form. It indicates some mix of braille Unicode characters, tactile graphics, and tactile objects are included in the publication.

Unlike a tactile primary access mode, the provision of links to tactile graphics and objects does allow a tactile sufficient access mode to be set. Such linked content rarely correlates with a publication being fully readable in tactile form; see the next section on combined reading modes.

When tactile is the only sufficient access mode set, it means that all the information necessary to read the publication is available in tactile form.

A single tactile sufficient access mode is the least common single sufficient access mode, at least for mainstream publishing. It is typically associated with a braille publication produced in the EPUB format.

Combined reading modes

Although the single sufficient access modes are considered the most important to set, it is also helpful to give users a complete picture of all the ways the content can be read, especially if the primary access modes are not set.

Publications that have more than one primary access mode always have a sufficient access mode set that is the combination of all those primary modes. For example, a book with text and images has textual and visual primary access modes. Since those two values tell the user that they have to be able to read text content and perceive visual content, the content has a sufficient reading mode that is also those two values.

Because sufficient access modes account for affordances, the possible sets of sufficient access modes are not always strictly combinations of the primary modes, even if there is always one set that equals all the primary modes. An example would be a comic that only provides alternative text so is not fully accessible as text. In this case, it would have a visual primary access mode but also a set of sufficient access modes that includes textual.

The combinations of possible sufficient access modes grows as there are more primary access modes and affordances to make them accessible. This is why it is not always helpful to users to have all the possibilities listed. It can make the metadata more confusing to understand.

Overview

Aural rendering

EPUB 3 publications allow the aural rendering of text content through the use of text-to-speech (TTS) playback (commonly referred to as "read aloud" capability) and media overlays. Both renderings are capable of providing audio playback of the text synchronized with highlighting of the associated text.

Text-to-speech engines, however, often fail to provide accurate readings of the text. Heteronyms, for example, where two words are spelled the same but have different pronunciations, often result in the wrong word being pronounced. Complex words, such as chemical names and technical jargon, also result in illegible playback, as do fictional words and names created by an author (for example, in works of science fiction). TTS playback also suffers from an inability to indicating emphasis or to controlling the pacing and prosody of the narration.

It is possible to provide enhancements in the markup of EPUB publications to help TTS engines render text accurately. EPUB 3's SSML attribute, for example, were intended to allow the inlining of pronunciation information, while PLS lexicons [[Pronunciation-Lexicon]] were designed to provide a reusable library of pronunciations. CSS Speech Level 1 [[CSS-Speech]] properties address the issues text-to-speech playback quality (for example, the voice to use, whether to spell out words, and when to provide emphasis).

Unfortunately, at this time none of these technologies have been proven to work at any kind of scale in EPUB reading systems. EPUB 3's SSML attributes will likely never be implemented and are best avoided. PLS lexicons are theoretically very useful but there are no known implementations after over fifteen years of existence. And CSS Speech has only had limited experimental support in Safari browsers. There is a possibility that PLS lexicons and CSS Speech will find support some day, and other technologies may come along to fix the problem of inlining SSML pronunciation information.

Despite these shortcomings, if a publisher makes the effort to enhance TTS playback, they can indicate this by adding the ttsMarkup feature to the EPUB package document.

It is only recommended to set this feature if the TTS enhancements substantively cover the rendering issues that are likely to arise — recognizing that different TTS engines have different capabilities and authors cannot anticipate every misreading they might make.

Media overlays differ from text-to-speech playback in that they provide prerecorded audio synchronized with the text. The synchronization, and granularity of playback synchronization, is set by the creator of the EPUB publication through markup files that conform to a profile of the SMIL [[SMIL]] standard.

When including media overlays, the synchronizedAudioText feature is specified in the package document.

The audio provided with media overlays is typically human narrated but some producers will also use text-to-speech engines to create the audio. TTS is often used when providing audio-synchronized playback of backmatter, which is tedious for humans to read.

Although this prerecorded synthetic speech is prone to the same failings as dynamic TTS generation, the ttsMarkup is not set in the package document metadata if the producer makes an effort to improve their audio. There currently is no feature to differentiate the quality of prerecorded synthetic speech.

The use of the TTS enhancements and media overlays is not mutually exclusive. TTS markup enhancements could be provided, for example, to improve the quality of the media overlays dynamic TTS generation feature. Some non-visual readers also prefer to use a reading system's read aloud capabilities even when media overlays are available as it allows them to read faster.

Chemistry

Providing accessible markup for chemical formulas and equations allows users to inspect the equations themselves rather than relying images of the content with alternative text and descriptions provided by the publisher. Even when care is taken in the writing of descriptions, ambiguities can arise because human language is not always as precise as the equations themselves.

Accessible markup also provides a robust, accessible alternative to images, as the notation can be resized, searched, copied, and interpreted correctly by screen readers.

Although EPUB 3, and web browsers more broadly, do not currently support ChemML, there are still two markup syntaxes that can be used to add accessible chemical formulas and equations.

The first of these, despite its name, is MathML. MathML provides a structured, semantic representation that can be rendered directly by modern browsers and assistive technologies. MathML markup can be added directly to HTML documents or stored in separate files and embedded using the [^object^] element. Just as it is able to represent mathematical equations, its syntax is also adaptable to representing chemical equations and formulas.

When an EPUB publication contains chemical formulas and equations marked up as MathML, the MathML-chemistry feature is set in the package document.

It is not required that every chemical equation or formula be represented as MathML in order to set this value, but the coverage should be substantive. Judgement will always be involved in determining whether MathML is necessary for every equation. Some simple equations may not benefit from the additional markup overhead.

The other way to represent chemical equations and formulas is using the LaTeX typesetting system. LaTeX rendering is not natively supported in reading systems, so it is often only used by publishers for preparing print manuscripts and transformed into another form, like images, for digital publications. But it is possible to embed LaTeX-formatted equations and use a JavaScript library like MathJAX to translate them for visual reading (the caveat, of course, is that not all reading systems support scripting).

Another possible use for LaTeX-formatted equations is as the alternative text for images, although this can lead to poor pronunciation by assistive technologies.

One reason for including the raw LaTeX is that it offers users the opportunity to copy the equations and use them in an application that allows them to read the syntax. But whether users are able to do this depends on whether they know how to unzip an EPUB and locate the equations, and whether digital rights management schemes even allow them access into the EPUB.

For these reasons, it is not common to find LaTeX-formatted chemical equations and formulas in EPUBs, but if the syntax is provided the latex-chemistry feature is set in the package document.

Similar to setting MathML-chemistry, it is not required that every chemical equation or formula be represented as LaTeX in order to set this value, but the coverage should be substantive for all complex equations.

Display control

The displayTransformability accessibility feature value is used to indicate that the user can modify the presentation of the text content of an EPUB publication to their own preferences without negatively affecting the readability.

When to set the displayTransformability value depends on the characteristics of the language a publication is written in. In general, the following characteristics serve as a basis for what must be modifiable:

• the text foreground and background colors
• the font family and size
• the paragraph spacing
• the line height
• the letter and word spacing
• the text alignment

Making sure content is transformable on these characteristics will be sufficient for many languages. But not all of these characteristics will apply to all languages. And depending on the language, other requirements can be equally important to ensure are modifiable, such as:

• the writing direction (horizontal or vertical)
• the display of ruby (both visibility and text color)
• the inclusion of space characters as word separators

To claim this feature, note that text must not be represented as images unless it falls under one of the exceptions specified in success criterion 1.4.5 [[wcag2]] or the text is incidental to the purpose of the image (e.g., text on a billboard or street sign in the background of an image).

In general, reflowable EPUB publications will meet display transformability requirements so long as none of the content is constrained visually by its bounding box. This typically only happens if overflow is clipped using CSS to prevent scroll bars from appearing. An example would be if a publisher adds a sidebar with a fixed height and width and clips any content that exceeds these dimensions. If the text is sized to neatly fit in this box only at the publisher's preferred display, increasing the font size or spacing would cause text to progressively disappear.

This feature is not applicable to fixed layout EPUBs because reading systems do not allow users to modify the display. Reading systems must support the accessibility of a feature before it can be claimed.

Enhanced display

The schema:accessibilityFeature property defines two values for indicating that the display of an EPUB publication has been enhanced by the publisher.

The first of these is the highContrastDisplay feature, which is used to state that there is a higher-than-normal contrast between text and its background. legibility for users with low vision or color vision deficiencies who require a to read comfortably.

This feature can be set when text and background color combinations meet or exceed the 7:1 contrast ratio for normal-sized text. It is the equivalent of meeting [[wcag2]] success criteria 1.4.6.

Note that to meet the requirements for setting this feature that images of text also have to meet the contrast requirements. The only exceptions are defined in SC 1.4.6, with the most typical exception for digital publications being for publisher and imprint logos.

The other feature for enhanced display is largePrint which is used to indicate that a publication has been formatted for users who require larger font sizes to read.

There is no single accepted definition of what constitutes large print, so publishers should consult regional guidelines, when available, for what is acceptable. In general, though, a font size of 14pt to 16pt is considered enlarged print, while a font size of 18pt and above is considered large print. For this reason, it is recommended to include information about the large print formatting used in the accessibility summary so that users are not left guessing which size has been used.

In practice, large print is rarely used in EPUB publications. Reflowable EPUBs can typically have their font size, family, line spacing, and other properties adjusted to whatever the user prefers (see the displayTransformability feature). This is a much better feature for users than picking the specific formatting.

It is also problematic to indicate that reflowable EPUB publications are formatted for large print reading when user preference settings are typically applied to the text. The formatting the publisher has provided may not be viewable unless the user reverts their own preferences.

The largePrint feature must never be used to indicate that it is possible to reformat the text (i.e., that the display is transformable). Features are set based on the defaults of a publication not on what it might be possible to achieve.

The most likely scenario for setting the largePrint feature is when a print-equivalent reproduction of a physical large print book is created using EPUB 3 fixed layouts. But the reality is that such works are rarely, if ever, created.

Image description

Providing text alternatives is key to making images accessible to readers who cannot perceive them or have difficulty processing the content.

There are two primary features that identify that accessible alternatives have been provided: alternative text and extended descriptions. Alternative text is a short description that can stand in for the image (usually added to the alt attribute in HTML documents) while extended descriptions provide additional detail when images express information that cannot be conveyed through a brief description.

With the exception of decorative images (those that convey no information needed to understand the text), all images require alternative text to be accessible. The accessibility feature for indicating that alternative text has been provided is alternativeText.

Publishers can declare that alternative text is provided even if not every image is described, although omitting alternative text is never recommended.

The alternative text provided for images must be meaningful both to meet accessibility requirements and to claim the alternativeText accessibility feature. A publication that simply auto-fills every alt attribute with the text "Image", for example, is not providing users with a meaningful alternative.

Sometimes images will contain more information than can be expressed in a short alternative text field. In these cases, it is also necessary to provide an extended description. The accessibility feature for indicating that alternative text has been provided is longDescription.

Similar to the requirement for claiming that alternative text has been provided, the extended descriptions for images must fully capture all information being conveyed through the image. It is not required that every image have a description, though, only those that require more extensive detail.

Math

There are several ways to provide accessible math equations in EPUB publications, but support in reading systems has historically been a barrier to the adoption of the most accessible. For example, although MathML would intuitively seem to be the most accessible way to add math, it was not well supported in HTML until recently. Its rendering in older reading systems still often relies on a JavaScript library that greatly slows the presentation the more equations there are to render.

With improved rendering in newer reading systems, it is now recommended as the most accessible way to provide math content. When MathML is provided for math content, the MathML accessibility feature is set in the package document metadata.

MathML markup allows for intelligent interpretation and voice rendering by assistive technologies, allows users to explore the components of an equation, and even allows copying and pasting of equations into external applications.

Although ideally all math equations would be represented as MathML, in practice this is often impractical to do. Basic math equations can often be represented using ASCII text without any loss of information, for example. When claiming that MathML is available as accessible feature, however, all, or substantively all, equations that would be ambiguous in pure text form should be represented using MathML markup.

LaTeX is another formatting syntax for expressing math equations and its presence is indicated in accessibility metadata using the latex accessibility feature.

Unlike MathML, which is markup based, LaTeX uses text commands (identifiable by a starting slash) to structure the different components of an equation.

Reading systems do not natively support the rendering of LaTeX equations the way they do MathML, but it is possible to add a JavaScript library like MathJAX to visually render the equations. Due to the lack of consistent support for scripting in EPUB, however, most publishers do not include LaTeX formatting directly in their publications. It is more commonly found in the source from which an EPUB is generated, and converted to an image for the EPUB, otherwise users without a scripting-capable reading system will have to view and read the raw LaTeX formatting.

Even though direct rendering of LaTeX is not well supported, a possible accessible compromise would be to include the raw LaTeX formatted equation as the alternative text for an image. This would potentially allow users to copy the LaTeX to another application to inspect it. As assistive technologies would only expect text as the alternative, so would not be able to meaningfully read or display the syntax, this practice is really only recommended when advanced math users are the target audience.

While not the most desirable from an accessibility perspective, it is possible to provide accessible images of math equations if high quality alternative text and descriptions are provided. The presence of described images is indicated in the metadata using the describedMath accessibility feature.

The problem with describing math images is that human language is often not as precise as the equations it tries to describe and there is no way for the user to inspect the original equation to try and clarify. For example, the description "the square root of x and y" could be interpreted as either taking the square root of x and adding that value to y, or adding x and y together and taking the square root of the result.

Images of math are still prevalent in EPUB, however, because improvements to MathML rendering are recent and there are many current and legacy reading systems that do not render MathML well.

Multimedia

Audio and video content often require a mix of features to improve their accessibility. While audio-only files only have to take their sound into consideration, video content typically mixes both important visual information with audio that needs to be conveyed to users. Moreover, a video without any sound still conveys information that has to be captured for users.

The practices for making audio accessible are generally the same regardless of whether the audio is part of a video or is a standalone clip. The biggest difference between the two cases is that audio with video typically requires more context to be accessible because the video content is also presenting important information.

One of the most common methods for making audio content in EPUBs accessible is by adding captions. There are two ways that this can be done: closed captions and open captions.

Closed captions are when the captions are defined separately from the audio content, allowing users to control their appearance and turn them on or off as they prefer. Their presence is indicated in the package document metadata using the closedCaptions accessibility feature.

Although closed captions are most beneficial to users who are deaf or hard of hearing, they can also be helpful to users who are blind or have low vision. It is possible for assistive technologies to read aloud the captions or render them as braille (although this is not common in EPUB reading systems). Audio descriptions and transcripts are generally more helpful for users who cannot see the content.

The typical way to add closed captions for audio in XHTML content documents is using the [^track^] element [[html]], with [[WebVTT]] being the most commonly used technology for captioning.

Open captions are the opposite of closed captions — they are a part of the visual display of a video and cannot be turned off or have their appearance modified, and cannot be accessed by assistive technologies. Their presence is indicated in the package document metadata using the openCaptions accessibility feature.

Open captions are most beneficial to users who are deaf or hard of hearing; they do not make auditory content accessible to users who are blind. (While sign language interpretation is often preferable for users who are deaf, it is not easy to provide as will be discussed later in this section.)

While captions are helpful for those who cannot hear the audio, they are not always the ideal. Many users who are deaf are more proficient at reading sign language than they are written text. For these users, having an interpreter to translate what is being said on screen is preferable. The inclusion of sign language interpretation is indicated in the package document metadata using the signLanguage accessibility feature.

Similar to captioning, there are two common ways to provide sign language interpretation. One is to include the interpreter as part of the video itself, often in a bubble in the lower corner of the screen. This method is best used where there is not a lot of action (e.g., for a person giving a speech) as it can obscure what is happening for all users.

The other method is to provide sign language interpretation in a separate video and link the two video elements so that they play back together. This method is problematic for ebooks both because HTML does not have a method of synchronizing two video elements (it would require scripting, which is not well supported in reading systems) and also because the author cannot know how the videos will be laid out and paginated (the sign language interpreter could end up on a separate page from the video). It is not common to find sign language interpretation in EPUBs for these reasons.

Another drawback of captions is that they only capture auditory content. For users who cannot see what is happening in a video, the context of what is occurring on screen is lost when only captions are provided. Audio descriptions fill this gap by describing what is happening visually (e.g. actor movements or expressions). Their presence is indicated in the package document metadata using the audioDescription accessibility feature.

Another common method of making both the audio and video content accessible is through a transcript. A transcript, like an audio descriptions, can also describe more than just what is being said. For example, it can be structured more like a screen play. For this reason, they are also useful for explaining what is happening in video-only content like animated instructional videos. When transcripts are provided, their presence is indicated in the package document metadata using the transcript accessibility feature.

The one drawback of using transcripts is that they are not available in real time like captions and audio descriptions. As a result, users who can see the content but not hear it may have to watch the video once in silence and then try to match up through memory what they are reading in the transcript against what they just watched. Even with detailed transcripts that include the actions to help orient the user, the time to process the video is greatly increased.

A final audio consideration for users who are hard of hearing or have difficult processing speech is to provide greater contrast between spoken content and background noises. High contrast audio refers to audio of speech that has no background noise, that maintains a difference of at least 20 decibels between the foreground speech and background noise, or that allows users to turn off any background noise. Its presence is indicated in the package document metadata using the highContrastAudio accessibility feature.

For specific details on evaluating when auditory content meets the requirements to be classified as high contrast, refer to success criterion 1.4.7. Not all audio has to meet this requirement, for example. The audio must be primarily speech and there is an exemption for musical content.

EPUB publications will often contain a mix of the above features to make audio and video content accessible. It is not required to pick only one feature for all audio and video clips, nor should publishers feel they have to limit themselves to providing only one accessible alternative per clip. As already discussed, different users will prefer different options.

Navigation

EPUB requires that every publication provide a table of contents in the navigation document, so it is almost always possible to claim the tableOfContents accessibility feature.

The only time it would not be appropriate to claim tableOfContents is if the table of contents does not even cover all the major top level chapters or sections.

It is not required that the table of contents provide links to every sublevel heading in the publication, either. If the publisher wants to keep the table of contents in the navigation document simpler for reading system use, they can also provide a more detailed table of contents in a regular XHTML content document in the publication spine. The tableOfContents value does not only apply to the table of contents in the navigation document, although this is the one easily access by users.

Providing users access into the major sections of the publication through the table of contents is one of EPUB 3's built-in methods of meeting WCAG 2's multiple ways success criterion, the other being via the page-to-page navigation offered from the spine. Publisher should also consider adding indexes to make it easier for users to more rapidly locate specific information if interest. These can include general indexes, such as by subject or name, or more content-specific indexes, such as an index of recipes for a cookbook.

The presence of an index is indicated in the package document metadata using the index accessibility feature.

The type of index provided does not matter when setting the index feature, but to set the feature the index must provide hyperlinks to the reference locations in the work or, if the index cites page numbers, must include a page list so that users can use it to navigate to the page references that way. If no method of accessing the reference locations is provided, the index feature must not be set.

Another method for users of assistive technologies to navigate a publication is through ARIA landmarks [[wai-aria]]. These are expressed using the [[html]] [^/role^] attribute and, particularly for EPUB, using the roles in the DPUB-ARIA extension [[dpub-aria]]. When an XHTML content document is loaded, assistive technology typically check for the presence of landmark roles and provide users with a quick navigation menu.

The presence of a table of contents is indicated in the package document metadata using the ARIA accessibility feature.

ARIA landmarks should be used sparingly as their usefulness diminishes the more there are in a document. On the web, they are used to direct users to the major components of a page's layout, such as the banner, search bar, navigation menu, main body, etc. A common mistake with publications is to replicate the entire table of contents as landmarks. Such practice is not helpful as the hierarchical structure of the sections and subsections in the page is lost when using landmarks — the landmark links are always present as a single flat list, there is no ability to nest levels like in a table of contents. A general rule of thumb for ARIA is that the usefulness of landmarks begins to diminish once you have more than a half-dozen or so in a page.

The final accessible navigation feature is the ability to move through the structure of a publication by heading level in the markup. When headings are properly marked up using the [[html]] h1 through h6 elements, it is possible for reading systems and assistive technologies to provide users hotkeys that allow them to move to the next heading.

The provision of structural navigation by heading is indicated in the package document metadata using the structuralNavigation accessibility feature.

This feature is similar to having a table of contents, but does not require the user to leave their current position and search the table of contents to skip forward to the next heading.

Publications that claim to provide structural navigation should ensure that the number of each heading element used matches the hierarchy of the heading within the publication. Although this is not required to conform to WCAG 2's info and relationships success criterion, claiming structural navigation is more than just ensuring some heading tag has been used to identify each heading.

Some minor deviations from this rule are acceptable so long as the variations are consistent and users are informed of the change in structure in the accessibility summary or in front matter on how to use the book. For example, some publishers set a specific starting level for all their sidebars, such as <h3>, regardless of the heading level the sidebar falls under.

Pagination

Whether an EPUB publication is produced with a print equivalent or not, being able to locate and move to static page break locations is an feature important to help users navigate the content. It is useful in educational settings, for example, where a users who are blind might use an EPUB to read an assignment instead of the print version their peers are using.

The first feature for identifying static pagination is page break markers. These markers are inserted into the markup XHTML content documents using the doc-pagebreak role to make them readable by assistive technologies.

The presence of static page break markers is indicated in the package document metadata using the pageBreakMarkers accessibility feature.

It is not required that every page break marker from the source be present, or that they be in the same order as the source, as digital publications often omit material that is only relevant to print and have front and back matter rearranged. The markers for blank pages at the end of chapters and sections are also often omitted from digital publications. When page markers are omitted, the accessibility summary should be used to explain why.

If the page breaks markers provided have limited utility, the pageBreakMarkers feature should not be claimed. For example, if only the page breaks at the start of chapters are identified, the ability to synchronize reading is no better than what the table of contents will provide. At a minimum, if the feature is claimed in cases like this, the limitation must be explained in the accessibility summary.

While static page break markers can be useful on their own, they are most commonly paired with a page list to allow users to quickly find a destination. The page list, as its name suggests, is a list of hyperlinks to each static page break location.

The presence of a page list is indicated in the package document metadata using the pageNavigation accessibility feature.

Similar to page break markers, a page list is most useful when it includes links to all the static page break locations. If the list is incomplete because blank pages or certain front or back matter is omitted, the summary should explain why. If the page list is mostly incomplete, such as when page breaks are only provided for chapter start locations, it is recommended not to claim it as an accessibility feature.

The resource includes the source of pagination so users can safely cite and retrieve citations, or synchronize reading in mixed reading environments where both printed and digital versions are used.

Regardless of whether static page break markers or a page list, or both, are included, the source of the pagination needs to be identified, even when there is no source (EPUBs with no print or other statically paginated version). As there may be multiple print editions of a work, all with different pagination, it is important for users to know which one the EPUB's pagination matches up with.

The source of the pagination is identified in a a11y:pageBreakSource property. It is recommended to use a unique identifier such as an ISBN or ISSN to identify the source, when available.

If a unique identifier is not available, provide as much information as possible that can uniquely identify the source.

If the pagination is unique to the EPUB, use the value "none".

Portability

The absence of digital rights management (DRM) schemes is a critical accessibility feature as it ensures that users can access the content with their preferred reading systems and assistive technologies, which might otherwise be blocked by encryption. It also allows for personal use and transformations of the content that may be necessary for a user to perceive and understand it (e.g., using it with specialized text-to-speech software).

That a publication is not DRM protected is indicated in the package document metadata using the unlocked accessibility feature.

Do not set the unlocked feature unless it is known for certain that the publication will be available to users without DRM. If, for example, the publication will be sent to a distributor who will pass it on to multiple vendors, some of whom may apply DRM to the publication, the feature must not be set, even if it might be true in some cases.

Reading order

It is important to indicate if an EPUB has a defined reading order in the markup because it ensures that users of assistive technologies can follow the narrative in order. When the visual presentation of the content does not match the order in the markup, it makes it harder for non-visual readers to understand the text.

The presence of a reading order is indicated in the package document metadata using the readingOrder accessibility feature.

Unlike many of the other accessibility features, where claims can be made even if coverage is not complete, the readingOrder feature must not be set unless the entire work conforms. Users cannot be expected to read the accessibility summary for problems with the reading order and then have to make sense of the mis-ordered content.

The lack of a logical reading order at the markup level most commonly occurs in fixed layout EPUBs. Reasons why include:

• the fixed layout canvas makes it easy to use CSS to position elements in a sequence that is detached from the markup;
• the nature of spreads (two pages side-by-side) allows publishers to create visual reading experiences that cross from one page to the next and back (for example, a sidebar that spans the bottom of a page).

Reflowable EPUBs typically do not have issues with their markup not reflecting the visual reading order, as there is less control over the layout position of content. But it is possible to create reading sequences that are out of order on a smaller scale than a page, as content can be positioned in a fixed manner within container elements. For example, a sidebar element could be given a fixed width and height and have elements positioned within that space.

Ruby annotations

Ruby annotations are used as pronunciation guides for logographic characters in languages like Chinese, Japanese, and Korean (CJK). They make difficult CJK ideographic characters more accessible for language learners, native speakers of all reading levels, and people with reading disabilities. They also provide critical information for text-to-speech (TTS) engines.

Unlike other accessibility features, ruby annotations distinguish between publications that provide full coverage and partial coverage of all ideographic characters. This is because it is common for CJK publishers to provide different coverage options based on reader need. Publications with partial coverage target pronunciation support for rarer characters, proper nouns, or key terms without cluttering the text with ruby on every single character.

The presence of full ruby coverage, where all ideographic characters have annotations, is indicated in the package document metadata using the fullRubyAnnotations accessibility feature.

When not all CJK ideographic characters have ruby annotations, the rubyAnnotations value is used instead.

Tactile content

As EPUB publications can be read on refreshable braille devices, it is possible for a publication to be authored using Unicode braille characters (see Braille Patterns). The advantage of using braille characters is that it allows the text to be optimized for braille users. This avoids the user having to rely on their braille device to translate the text, which can be problematic especially for specialized notations like mathematics and music.

The presence of braille Unicode characters is indicated in the package document metadata using the braille accessibility feature.

The eBraille format is designed to represent braille character data in an EPUB-conformant package and is a better choice for authoring braille in EPUB. It is not necessary to declare that en eBraille file has a braille feature, however, since the format itself and its required metadata already make this fact clear. The braille feature is expected only when braille character data supplements the standard text.

Both eBraille and standard EPUB publications may contain tactile graphics. These are images that are specially designed to allow users who cannot see the images to explore them tactilely, either by printing the images (embossing) or rendering them on specialized refreshable braille devices.

The presence of tactile graphics is indicated in the package document metadata using the tactileGraphic accessibility feature.

The tactile graphic does not have to be displayed in the content to claim this feature. If links are provided to external graphic files, the feature can still be claimed.

Although it may seem counterintuitive that a digital format like EPUB could contain a tactile object, the case is similar to external tactile graphics. If an EPUB provides links to files that can be downloaded and printed, it is possible to declare that tactile objects are available.

The presence of tactile objects is indicated in the package document metadata using the tactileObject accessibility feature.

Word segmentation

Word segmentation refers to whether additional spacing is added to languages that do not normally use whitespace characters to separate words (e.g., Chinese, Japanese, Thai, and Lao). Adding additional whitespace can make it easier to read for some users, especially those with cognitive or visual impairments who have difficulty following visually when there are no spaces.

The presence of additional word segmentation is indicated in the package document metadata using the withAdditionalWordSegmentation accessibility feature.

The lack of word segmentation is not an accessibility feature in the strictest sense, but it is included as a feature represents to indicate that the default authoring practice has been followed for these languages.

The lack of additional word segmentation is indicated in the package document metadata using the withoutAdditionalWordSegmentation accessibility feature.

Setting one or the other of these values, as appropriate, is recommended to avoid ambiguity (i.e., leaving the user guessing if word segmentation is not provided or if the publisher forgot to add metadata). Do not, however, set either value for languages that normally use whitespace to separate words.

If a publication combines text with added word segmentation and text without, whichever method is predominant should be set as the accessibility feature. That the full text is not available in that mode should be explained in the accessibility summary.

Writing direction

Some languages, such as Chinese, Japanese, and Korean, can be written both vertically and horizontally, but the choice of writing direction can make it harder for some users to follow the text.

To indicate that horizontal writing is used, the package document metadata must indicate the horizontalWriting accessibility feature.

To indicate that vertical writing is used, the package document metadata must indicate the verticalWriting accessibility feature.

Setting the appropriate writing direction is always recommended, but do not, set either value for languages that are normally only written in one direction. For example, it adds no benefit to users to declare that English is written horizontally.

If a publication combines writing directions (for significant amounts of text, not for minor formatting like representing foreign language text), whichever method is predominant should be set as the accessibility feature. That the full text is not available in the specified direction should be explained in the accessibility summary.

Setting hazards

There are three types of 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).

• 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.

It is not only important for users to be aware if these hazards are present, but also if they are not present or if their status is unknown. Without this information, users would have no way of knowing if a publication is free from hazards or simply has not been checked, potentially leading them to obtain content which could be physically harmful to them.

To allow for complete metadata declarations, each of the hazards defined above can be in three different ways:

• When hazards are present, the flashing, motionSimulation, and sound values can be declared.
• When hazards are not present, the values to use are noFlashingHazard, noMotionSimulationHazard, and noSoundHazard.
• When hazards are not known, the values to use are unknownFlashingHazard, unknownMotionSimulationHazard, and unknownSoundHazard.

Each hazard status is identified in the EPUB package document using a schema:accessibilityHazard property [[schema-org]]. The property is repeated for each status; do not group all the hazard statuses into a single tag.

These values can be paired together to identify each risk, but authors have to ensure they do not accidentally declare conflicting statements for the same hazard type. For example, flashing, noFlashingHazard and unknownFlashingHazard must never be declared for the same publication.

To help simplify authoring hazard metadata, there are also two global values that can be declared:

• When there are no hazards of any type, the value none can be declared instead of setting a status for each individual hazard type.
• When none of the possible hazards is known, the value unknown can be declared instead of setting a status for each individual hazard type.

These values are mutually exclusive and must never be declared for the same publication. Also, when either of these global values is declared, no individual hazard statuses should be declared as it is likely to cause conflicting statements and confuse users. For example, when none is declared, the flashing, motionSimulation, and sound hazards must not also be declared, nor any of their unknown value equivalents. Best practice is to never mix a global declaration with individual ones, even if they technically do not conflict.

If an EPUB publication contains a hazard, or if the presence of a hazard type is not known, provide additional information in the accessibility summary. For hazards, this could include where the hazard occurs (both location within the publication and the point within the resource, when applicable). For unknown hazards, the reason why the hazard is not known should be stated, as well as whether and when a future update to the publication will provide more information.

When hazards are known

It is critical health and safety issue to alert photosensitive users if a publication is known to contain content that flashes more than three times in any one second period or where the flash is below the general flash and red flash thresholds.

Content that can exhibit these characteristics includes videos, animated graphics, dynamic content drawn on the [[html]] [^canvas^] element, and CSS animations.

To indicate that there is a flashing hazard, the flashing hazard value must be declared in the package document metadata.

Motion simulation is equally problematic as it can trigger severe dizziness, nausea, and disorientation in users with vestibular disorders.

Some examples of motion simulation include video games with a first-person perspective and CSS-controlled backgrounds that move at a different rate from the foreground content (parallax scrolling).

To indicate that there is a motion simulation hazard, the motionSimulation hazard value must be declared in the package document metadata.

What precisely constitutes a sound hazard, and how to test for these hazards, is not yet standardized. As a result, it is particularly important when declaring a sound hazard to explain what the hazard is being declared in the accessibility summary.

To indicate that there is a sound hazard, the sound hazard value must be declared in the package document metadata.

When hazards are not present

Many books have no content that will pose a hazard to users. This is especially true of novels and similar books that consist only of headings and text. Instead of having to declare that each individual hazard type is not present, a shorthand to cover all hazards is provided in the none hazard value.

If a publication consists of a mix of known, not applicable, and unknown hazards, then each hazard that is not present needs to be separately identified.

To indicate that there are no flashing hazards, the noFlashingHazard value must be declared in the package document metadata.

To indicate that there are no motion simulation hazards, the noMotionSimulationHazard hazard value must be declared in the package document metadata.

To indicate that there are no sound hazards, the noSoundHazard hazard value must be declared in the package document metadata.

The noSoundHazard value provides a positive assertion that the content will not interfere with screen readers or other assistive technologies.

When hazards are not known

There may be times when the presence of accessibility hazards is not known but a statement is still needed in the package document metadata. This usually happens if a placeholder is needed until an accessibility evaluation is carried out.

To indicate that no hazards are known, the unknown hazard value must be declared in the package document metadata.

If a publication consists of a mix of known, not applicable, and unknown hazards, then each hazard that is not known needs to be separately identified.

To indicate that the presence of flashing hazards is not known, the unknownFlashingHazard value must be declared in the package document metadata.

To indicate that motion simulation hazards are not known, the unknownMotionSimulationHazard hazard value must be declared in the package document metadata.

To indicate that the presence of sound hazards is not known, the unknownSoundHazard hazard value must be declared in the package document metadata.

Overview

[[[epub-a11y-12]]] [[epub-a11y-12]] defines metadata for indicating whether a publication meets its conformance requirements, as well as how to report information such as who performed the evaluation, what credentials the evaluator holds, and who to contact for more information about the accessibility of a publication.

Although this metadata is not as descriptive about the specific accessible characteristics of the content, it is just as important to set for multiple reasons. Primary among them is that reporting accessibility conformance to an accepted standard shows users that the content is broadly accessible, without them having to go through all the specific details to build a picture. The level of conformance, whether WCAG 2 Level A or AA, also provides insight into the user groups that will benefit from the accessibility affordances provided.

Reporting conformance also directly benefits publishers as it establishes trust with their customers. When customers see that a publisher consistently does the work to make their content accessible, they are more likely to seek out content from that publisher.

Reporting accessibility conformance is also important at a regulatory level. Many jurisdictions now have laws around the provision of accessible content. Indicating that a publication is conforming and providing details about the evaluation is often not optional metadata.

Conformance claims

Conformance exemptions

In jurisdictions where accessibility conformance is mandated by law, it is also possible that some publishers are granted exemptions from full conformance. Exemptions may be granted, for example, for small and self-publishers who cannot afford the full costs of making their publications accessible or for content that cannot be made accessible without fundamentally altering its presentation.

The a11y:exemption property is used in these cases to indicate that an EPUB publication is exempt from a jurisdiction's accessibility requirements.

A publication can fail the minimum accessibility requirements for a jurisdiction while still meeting the minimum conformance requirements of the EPUB Accessibility standard. This is because conformance claims can be made when a publication meet WCAG 2 Level A while most legislations requires Level AA conformance. For this reason, the exemption is not linked to a conformance claim or an evaluator using the refines attribute.

At the time of writing, the European Accessibility Act (EAA) is the only legislation known to provide these types of exemptions. Publications must meet the minimum accessibility requirements of the Act or fall under one of the following three exemptions in order to be distributed within the bloc of member countries:

• disproportionate burden — the accessibility requirements of the Act shall apply only to the extent that compliance: … (b) does not result in the imposition of a disproportionate burden on the economic operators concerned. An exemption under this clause is declared using the value "eaa-disproportionate-burden".
• fundamental alteration — the accessibility requirements of the Act shall apply only to the extent that compliance: (a) does not require a significant change in a product or service that results in the fundamental alteration of its basic nature. An exemption under this clause is declared using the value "eaa-fundamental-alteration".
• microenterprise — the accessibility requirements of the Act do not apply to an enterprise which employs fewer than 10 persons and which has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million. An exemption under this clause is declared using the value "eaa-microenterprise".

Publishers should seek legal advice before claiming any exemption to EAA rules. Exemptions may also be time-limited and require a periodic reassessment to confirm that they still apply.

Adding contact info

Providing a contact email address for accessibility inquiries is another helpful way to establish trust with users. While conformance and discovery metadata provide a useful picture of the accessibility of a publication, it cannot cover every need. Before purchasing content, users may want to reach out to the publisher for more information.

A contact email is also a helpful way for publishers to gather feedback on the actual accessibility of their content. Sometimes inaccessible content will slip through quality assurance testing. And while user testing before release, is ideal, it is not always possible and cannot verify every user's needs are met.

The email address to use to contact the publisher is specified in an a11y:contactEmail property.

The contact email does not have to go to the publisher. If they use a third-party that is responsible for the accessibility of their products, that party's address can be used. The key point is that the email should go directly to someone who can handle accessibility requests. It should not be a general purpose feedback address unless there is no other option.