Accessible EPUB

Apple Books rejects EPUB files where any img element is missing an alt attribute — one omission causes the entire submission to fail. Beyond that single hard requirement, accessible EPUBs have a correct language declaration, a logical heading structure, meaningful epub:type annotations, and a spine that matches the intended reading order. These are the requirements this page covers: what they are, how to implement them, and how to validate them.

Alt text on images

Every <img> element in your EPUB content files must have an alt attribute. Apple Books enforces this and rejects files where any img element is missing the attribute. The attribute serves two roles: it describes images to screen reader users, and it tells automated validators that you have considered each image's accessibility:

<!-- Image that conveys content — describe what it shows -->
<img src="../Images/world-map.jpg"
     alt="Map showing the three expedition routes across the continent"/>

<!-- Decorative image — empty alt tells screen readers to skip it -->
<img src="../Images/chapter-divider.png" alt=""/>

A missing alt attribute and an empty alt="" are different things. Missing alt is an error that triggers Apple Books rejection. Empty alt is a valid signal that the image is decorative. For image format reference, manifest declarations, and cover image requirements, see images in EPUB files.

Language declaration

The dc:language element in the OPF package document declares the primary language of the publication. Screen readers use this declaration to select the correct text-to-speech engine and pronunciation rules. An incorrect or missing language declaration causes mispronunciation:

<!-- In content.opf, inside <metadata> -->
<dc:language>en</dc:language>

<!-- For regional variants -->
<dc:language>en-US</dc:language>
<dc:language>en-GB</dc:language>
<dc:language>fr-CA</dc:language>

Use IETF BCP 47 language tags: "en" for English, "fr" for French, "de" for German, "es" for Spanish. For the full metadata reference including dc:language, see the EPUB metadata guide.

Heading structure

Headings in EPUB content files function as navigation landmarks. Screen readers and e-reader navigation panels let users jump between headings, so a correct heading hierarchy is as important as a correct table of contents. Use headings in sequence — don't skip from h1 to h3, don't use a heading tag for visual styling when the content isn't a structural heading:

<!-- Each chapter file typically has one h1 -->
<h1>Chapter 3: The Journey North</h1>

<!-- Sections within a chapter use h2 -->
<h2>Crossing the Border</h2>

<!-- Sub-sections use h3 -->
<h3>The First Night</h3>

The heading structure in content files should match the TOC structure in nav.xhtml. A chapter that appears in the TOC should have a heading in the content file at the corresponding level. For how EPUB TOC structure works — nav.xhtml and toc.ncx formats — see the EPUB TOC guide.

epub:type semantic annotations

The epub:type attribute adds semantic meaning to structural elements. Reading systems that support EPUB semantics use these annotations to improve navigation — for example, allowing users to jump directly to the table of contents or skip to the beginning of body content. These annotations assist reading systems and assistive technology that recognize EPUB semantics; their rendering effect varies by platform and is not guaranteed:

<!-- Navigation document — the toc nav element -->
<nav epub:type="toc" id="toc">
  <ol>...</ol>
</nav>

<!-- Landmarks nav — links to structural divisions -->
<nav epub:type="landmarks">
  <ol>
    <li><a epub:type="toc" href="nav.xhtml#toc">Table of Contents</a></li>
    <li><a epub:type="bodymatter" href="chapter01.xhtml">Start of Content</a></li>
  </ol>
</nav>

<!-- In chapter content files -->
<section epub:type="chapter">
  <h1>Chapter 1</h1>
  ...
</section>

Common epub:type values include: toc (navigation document), chapter (chapter section), cover (cover page), frontmatter / bodymatter / backmatter (structural divisions), copyright-page, dedication.

Reading order and the spine

The <spine> element in the OPF package document defines the logical reading order — the sequence in which content files should be read from beginning to end. Screen readers and reading apps that follow the EPUB specification present content in spine order. If spine order differs from intended reading order, the book reads incorrectly for these users:

<!-- In content.opf -->
<spine toc="ncx">
  <itemref idref="cover-page"/>
  <itemref idref="title-page"/>
  <itemref idref="copyright-page"/>
  <itemref idref="dedication"/>
  <itemref idref="toc-page"/>
  <itemref idref="chapter01"/>
  <itemref idref="chapter02"/>
  <itemref idref="chapter03"/>
  <itemref idref="about-author"/>
</spine>

Every content file in the spine must also be declared in the manifest. Files present in the manifest but absent from the spine are valid (for example, image files, CSS files) but content XHTML files that should be readable must appear in the spine. For how spine ordering relates to chapter structure, see the chapter breaks in EPUB guide.

Frequently asked questions

For EPUB validation that checks alt text, missing manifest resources, and structural issues, see the EPUB error reference. For the image-specific requirements — format support, cover image manifest declaration, and alt text — see images in EPUB files.

For the full EPUB build workflow — TOC, metadata, CSS, chapter structure, and platform submission — see the EPUB formatting guide.