EPUB 3 Accessibility Guidelines

Overview

WCAG is the internationally recognized standard for creating accessible web content. By aligning EPUB 3 with the web stack, the IDPF has also aligned the creation of EPUB content with the best practices outlined in WCAG.

The primary advantage of this approach to accessibility is that it keeps EPUB aligned with the body of work that has already been done to make web content accessible. It also immediately makes web content accessibility specialists knowledgeable about the issues involved in ebook production. And, more generally, it means that content creators seeking to discover how to make their publications more accessible have a wealth of general resources available to them beyond just this site.

But EPUB is also its own unique format, and WCAG is not a simple blanket set of practices that all apply in every situation. This guide aims to bridge this gap for EPUB content by focusing on how to make rich publications that adhere to WCAG. Unlike the wild web, where each site's design often brings its own unique issues, books are generally composed of the same sets of building blocks, making accessibility mappings useful to a broad range of publishers.

Structure

The WCAG guidelines take a layered approach to accessibility, starting with four high-level principles that all content creators should strive to achieve. These principles are defined as follows:

1. Perceivable—Information and user interface components must be presentable to users in ways they can perceive.
2. Operable—User interface components and navigation must be operable.
3. Understandable—Information and the operation of user interface must be understandable.
4. Robust—Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

At the next level, each of these principles is broken down into a set of guidelines for achieving compliance.

Perceivable

1. 1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
2. 1.2 Provide alternatives for time-based media.
3. 1.3 Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
4. 1.4 Make it easier for users to see and hear content including separating foreground from background.

Operable

1. 2.1 Make all functionality available from a keyboard.
2. 2.2 Provide users enough time to read and use content.
3. 2.3 Do not design content in a way that is known to cause seizures.
4. 2.4 Provide ways to help users navigate, find content, and determine where they are.

Understandable

1. 3.1 Make text content readable and understandable.
2. 3.2 Make Web pages appear and operate in predictable ways.
3. 3.3 Help users avoid and correct mistakes.

Robust

1. 4.1 Maximize compatibility with current and future user agents, including assistive technologies.

A further level below the guidelines are the success criteria, which is the level where WCAG moves from a general outline for accessible content to how to practically achieve it. These criteria are quite extensive, so are not be reproduced here. For more information, refer to the WCAG guidelines.

After these three levels of progressive refinement of what it takes to create accessible content, you reach the sufficient and advisory techniques for testing compliance to the success criteria. These criteria provide the format-specific information you need to verify your content.

This guide focuses on the techniques, but understanding the higher-level concepts is also necessary to truly understand what makes content accessible. You will find links to the relevant techniques throughout this site, while the introductions to each section endeavour to explain why making these structures accessible is necessary (i.e., how they fit into the higher-level guidelines).

Conformance

WCAG defines three levels of conformance (from 'A' to 'AAA') to indicate the breadth of support a site provides, where an AA rating is typically required to meet most accessibility legislation.

These levels are useful when dealing with contractors, outsourcers and other parties where a baseline agreement on what constitutes an accessible EPUB 3 publication is needed. As WCAG 2.0 does not yet address HTML5, and because EPUB has its own unique features, no attempt is made in this guide to define a similar conformance ranking system or try to list exactly what is required to meet any given level at this time. Content creators are instead encouraged to strive for the highest degree of conformance to the success criteria.

Note that when evaluating an EPUB for conformance, the entire publication should be treated as though it constitutes a single document. Although individual documents within any publication may be conformant to WCAG, if the content is predominantly inaccessible it must not presented as though it adheres to any success level. For example, it would not accurate to portray a fixed-layout, image-based publication with no text alternatives as accessible because it contains an introduction with accessible text and a heading.

Overview

Scripting provides a greater challenge to accessible production in ebooks than does markup, as is true on the wider web. Where content structures are generally similar across the publishing industry, interactive widgets and dynamic content are typically unique to each publication, making it difficult to provide simple one-size-fits-all guidelines. Content creators must instead learn how to use ARIA roles, states and properties to enhance this kind of content.

Roles provide a means of indicating the nature an element plays in the document, similar to the structural semantics that the epub:type attribute provides, but aimed more specifically at relaying pertinent information to accessibility APIs.

States and properties are another means of conveying information, but about the nature of elements that are being used in non-standard ways (and sometimes to enhance normal usage). Creating dynamic controls and widgets using standard HTML elements coupled with JavaScripted events is a common practice, but one that leaves an information vacuum. For example, if an image is a button, is it currently pressed or not? States and properties enable someone using an assistive technology to interact with these controls by presenting the information in a way the AT can use.

This guide provides only a basic introduction to ARIA in the scripting section.

Conformance

Unlike WCAG, ARIA does not have a grading system for content compliance. Due to the dynamic nature of the content that benefits from ARIA roles, states and properties, and the range of needs that readers may have, the best approach to applying ARIA is to test your content for actual usability, or to have it tested by organizations that specialize in this content.