Accessible EPUB Checklist: What to Check, With Code Examples

An accessible EPUB checklist starts with the structure every book has (real headings, a working table of contents, a declared language), then adds checks only for what a book contains: images, notes, tables, verse, print page numbers, maths or media. Every EPUB also needs accessibility metadata, and a conformance claim needs testing behind it.

What Does “Accessible” Mean, and Who Has to Provide It?

An accessible EPUB, in the sense any conformance claim uses, is one that meets EPUB Accessibility 1.1 at a stated version and level of WCAG, the Web Content Accessibility Guidelines. EPUB Accessibility 1.1 has been a W3C Recommendation since 17 October 2024. It requires WCAG 2.0 Level A as a minimum and strongly recommends the latest WCAG 2 version at Level AA, which today means WCAG 2.2 AA. A file with some accessible features that has not been evaluated against the standard is still an improvement, but it cannot claim to conform.

The WCAG levels are cumulative. Level A covers the most basic requirements, such as text alternatives for images and structure that assistive technology can read. Level AA adds requirements such as a contrast ratio of at least 4.5:1 for body text and text that can be enlarged without loss. The strictest level, AAA, goes further again, and WCAG itself does not recommend requiring it as a general policy, because some content cannot meet it.

EPUB Accessibility 1.2 was published as a W3C Candidate Recommendation Draft on 12 September 2026. It is not yet a Recommendation, and its own status section says it is “inappropriate to cite this document as other than a work in progress.” DAISY already lists 1.2 conformance strings as valid, and Benetech’s certification programme evaluates against 1.1, so the practical rule is to claim the version the file was actually evaluated against. One change in 1.2 is worth building in already: it makes {c(‘accessModeSufficient’)} a required metadata property and accessMode a recommended one, the reverse of 1.1. Both are part of the package metadata covered near the end of this checklist, and a package that carries both is ready for either version on that point.

A regulation and a standard answer different questions. The European Accessibility Act (Directive (EU) 2019/882) sets out what an e-book service must achieve: accessible content and navigation, flexible presentation, compatibility with assistive technology, accessibility information in the metadata, and digital rights management that does not block any of these. EPUB Accessibility is the technical standard a publisher uses to show those outcomes have been met, and a W3C Group Note maps each of the Act’s e-book requirements to the EPUB standards. The note is a technical mapping, not a legal ruling.

The Act’s requirements have applied to e-books provided to consumers in the EU since 28 June 2025. Its definition of a service provider turns on offering the service to consumers in the Union and contains no test of where the provider is established; an opinion published by the International Publishers Association reads it the same way, while calling the position for publishers outside the EU “an unknown and a moving target” on enforcement. Each member state applies the Act through national law.

The Act exempts microenterprises providing services, and defines a microenterprise as employing fewer than 10 people and having either an annual turnover or an annual balance-sheet total of no more than €2 million. A self-publishing author working alone meets the staff test, so the exemption applies unless both turnover and balance sheet exceed €2 million. A small publisher with ten or more staff is not a microenterprise, whatever its turnover. This is general information, not legal advice.

In the US, the Department of Justice’s ADA Title II rule on web content and mobile apps applies to state and local government bodies, not to publishers as such, and adopts WCAG 2.1 AA as its standard. Its examples include public universities and public libraries. An institution that is itself a public body should take advice on how far the rule reaches what it publishes.

Accessibility is not yet a condition of sale at KDP or Google Play Books. KDP’s accessibility question at title setup defaults to “I don’t know”, and KDP says you can proceed with publishing with that selection. Google Play Books says it will keep titles on sale regardless of their accessibility details and displays missing values as “unspecified”.

Before You Start: Source Files, Markup and Scope

An EPUB’s structure is decided in the file it is exported from. In InDesign, every paragraph and character style carries an Export Tagging setting that maps it to an HTML element and class, set in the style’s options or for all styles at once through Edit All Export Tags. Nothing in a print workflow depends on it, and designers typically leave it unset. Without it, every paragraph exports as a <p> with a class named after its style, chapter titles included. The file looks right in a reading app and gives a screen reader no headings to navigate by.

<!-- Chapter title with no export tagging: a styled paragraph -->
<p class="Chapter-Title">Chapter 3: The Crossing</p>

<!-- The same style tagged as a heading -->
<h2 class="Chapter-Title">Chapter 3: The Crossing</h2>

An EPUB is a set of XHTML content documents plus a package file (the OPF), whose manifest lists every file, whose spine sets the reading order and whose metadata describes the book, and a navigation document that holds the table of contents.

Much of the checklist uses two kinds of semantic markup side by side. epub:type attributes drive features in reading systems (the apps and devices that display the EPUB), such as pop-up footnotes. ARIA roles (from Accessible Rich Internet Applications, the W3C vocabulary for describing elements to assistive technology), mostly the doc- roles from its Digital Publishing module, are what screen readers use. The W3C’s EPUB Accessibility Techniques state plainly that using epub:type “is not a means of satisfying requirements for ARIA roles in WCAG.” Where an element takes both, each example in the checklist shows both; where the DAISY guidance uses only one, the example follows it. DAISY is the not-for-profit consortium that maintains the Accessible Publishing Knowledge Base and the Ace and SMART checking tools.

Not every book needs every check. The first list applies to every EPUB, as do the final two sections on metadata and testing. Each list in between applies only if the book contains what it covers, so a novel with no images, notes or print page numbers needs only the first list and the last two sections. The checks are drawn from the W3C specifications and the DAISY Knowledge Base. They are not exhaustive, and almost every fault they describe can be fixed in the source file or the EPUB. Fixed layout is the partial exception, because a page that cannot reflow may never meet Level AA.

Accessible EPUB Checklist for Every Book: Structure and Styling

Every EPUB, including a novel with nothing in it but chapters of text, needs the twelve structure and styling checks that follow. Metadata and testing, which every EPUB also needs, have their own sections at the end of the checklist.

• Real headings, in a hierarchy that spans the book. Chapter and section titles are h1 to h6 elements, never styled paragraphs, and their levels reflect the whole publication rather than restarting in each file. A chapter file inside a part can open at h2; the Techniques document says a file need not begin with h1 unless its first heading is a top-level one. Keep a subtitle inside an hgroup so it is not announced as a heading of its own, and do not split one heading across several elements for visual effect (DAISY: headings).

  <!-- a chapter inside Part One, so h2 under the part's h1 -->
  <section role="doc-chapter" aria-labelledby="ch03">
    <hgroup>
      <h2 id="ch03">Chapter 3: The Crossing</h2>
      <p role="doc-subtitle">Autumn 1846</p>
    </hgroup>
    <p class="chapter-opening">...</p>
  </section>

• A reading order the spine defines. The spine lists content documents in the order they are read. Anything outside the main flow, such as an answer key or a pull-out map, takes linear="no", and EPUB 3.3 requires a link to it from the content or the navigation document.

  <spine>
    <itemref idref="cover"/>
    <itemref idref="ch01"/>
    <itemref idref="ch02"/>
    <itemref idref="answers" linear="no"/>
  </spine>

• A table of contents that reaches every file. The navigation document holds exactly one nav with epub:type="toc", built as an ordered list of links, with nested lists for the hierarchy. Each content document needs at least one link to it, and the order follows the spine. role="doc-toc" is only needed when the navigation document is also in the spine (DAISY: table of contents).

  <nav epub:type="toc" id="toc">
    <h2>Contents</h2>
    <ol>
      <!-- at least one link for every content document -->
      <li><a href="ch01.xhtml">Chapter 1: Arrival</a></li>
      <li><a href="ch02.xhtml">Chapter 2: The Harbour</a>
        <ol>
          <li><a href="ch02.xhtml#s2-1">The Customs House</a></li>
        </ol>
      </li>
    </ol>
  </nav>

• Landmarks for the start of the text and the major sections. A landmarks nav is a flat list that lets a reading system jump to the start of the body text, the index or the glossary. DAISY recommends it for every EPUB, and the type goes on each link, not on the list items (DAISY: landmarks).

  <nav epub:type="landmarks">
    <h2>Guide</h2>
    <ol>
      <li><a epub:type="toc" href="nav.xhtml#toc">Contents</a></li>
      <li><a epub:type="bodymatter" href="ch01.xhtml">Start of content</a></li>
      <li><a epub:type="glossary" href="glossary.xhtml">Glossary</a></li>
      <li><a epub:type="index" href="index.xhtml">Index</a></li>
    </ol>
  </nav>

• A title for every content document. Each XHTML file needs its own descriptive <title>; the book title in the package metadata does not stand in for it. The Techniques document notes that without one, assistive technologies “often will announce the name of the file”.

  <head>
    <title>Chapter 3: The Crossing | Salt and Iron</title>
  </head>

• Language, declared in the package and in every file. dc:language in the package names the publication’s language, but the Techniques document is explicit that package languages “have no effect on individual EPUB content documents.” Each file declares its own with both lang and xml:lang, because assistive technologies may recognise only one of them, and a passage in another language gets its own tag so text-to-speech switches pronunciation (DAISY: language).

  <!-- package.opf -->
  <dc:language>en</dc:language>
  
  <!-- every content document -->
  <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
  ...
  <p>She called it <span lang="fr" xml:lang="fr">un faux pas</span>.</p>

• Alt text on the cover image. The cover is an informative image. Where it appears as an image in the content, it needs alt text, and the title and author are what it contributes (DAISY: image descriptions).

  <img src="images/cover.jpg"
       alt="Salt and Iron, a novel by Mara Quill"/>

• Emphasis that carries meaning, and display type set in CSS. em marks stress, strong importance, and i a change of voice, a technical term or a foreign phrase. DAISY is direct that “CSS formatting carries no semantics” (DAISY: bolding and italics). InDesign character styles map to elements through the same Export Tagging setting, so an Emphasis style should export as em. Set small caps and display capitals in CSS over normally cased text, and set a drop cap in CSS on the first letter. Never split the letter into an image or its own element: a screen reader then announces something like “Image Cee all me Ishmael” (DAISY: drop caps).

  <p>The committee met <em>twice</em>, and the second vote was
  <strong>binding</strong>. The phrase <i lang="la" xml:lang="la">inter se</i>
  appears in the minutes.</p>
  
  /* CSS */
  .smallcaps { font-variant: small-caps; }
  p.chapter-opening::first-letter {
    float: left;
    font-size: 3em;
    line-height: 1;
    padding-right: 0.1em;
  }

• Scene breaks marked with hr. DAISY advises using the hr element “wherever a context break occurs”, because it lets assistive technologies tell the reader the context has changed; extra space alone tells them nothing. An ornament goes on top of it in CSS. The same page says the element “should not be used for purely decorative purposes”, so an ornament at the head of every chapter is a decorative image, not a break (DAISY: context breaks).

  <p>...and the door closed behind her.</p>
  <hr class="scene-break"/>
  <p>Three winters later, the letter arrived.</p>
  
  /* CSS: the ornament is decoration on a real break */
  hr.scene-break {
    border: none;
    height: 1.5em;
    background: url(../images/ornament.svg) no-repeat center;
    background-size: contain;
  }

• Lists marked up as lists. Numbered steps use ol, unordered items ul, and a sub-list sits inside its parent li. A list built from paragraphs with typed bullets or numbers is read as ordinary text.

  <ol>
    <li>Soak the beans overnight.</li>
    <li>Drain and rinse them.</li>
  </ol>

• Link text that names the destination. “Click here” and bare URLs tell a listener nothing when links are read out of context, and a link that differs from the text around it only by colour fails WCAG’s use-of-colour criterion.

  <p>See <a href="ch12.xhtml#plates">the colour plates in Chapter 12</a>.</p>
  
  /* CSS: keep links distinguishable without colour */
  a { text-decoration: underline; }

• CSS that yields to the reader’s settings, with adequate contrast. In a reflowable EPUB, where text rewraps to the screen, the reader chooses the font, size and theme. Use relative units, leave the body font size unset, avoid !important and forced backgrounds, and keep text at a contrast of at least 4.5:1 against its background, or 3:1 for large text (18 point, or 14 point bold) (DAISY: contrast).

  p  { margin: 0; text-indent: 1.2em; line-height: 1.4; }
  h2 { font-size: 1.5em; margin-top: 2em; }
  /* avoid: body { font-size: 11px; background: #fdf6e3 !important; } */

Checks for Books With Images

Books with images beyond the cover need five checks of their own. The decision that matters is which images need alt text at all: informative ones do, and decorative ones take an empty alt attribute so that nothing is read.

• Informative images: alt text that says what the image contributes. Describe what the reader needs from the image in its context, not everything visible in it, and do not repeat the caption, which is read as well. For Kindle books, KDP’s guidance caps alt text at 140 characters; WCAG sets no length limit, and anything longer than a sentence or two belongs in an extended description.

  <img src="images/fig-04.jpg"
       alt="The harbour in 1890, with the customs house on the left
            and the new rail spur running along the quay"/>

• Decorative images: an empty alt attribute. Ornaments, rules and background flourishes take alt="" so assistive technology skips them. Leaving the attribute off altogether is a different case: the image then has no text alternative at all, while an empty one tells assistive technology to skip it. DAISY treats role="presentation" as best practice but not required for WCAG conformance (DAISY: decorative images).

  <img src="images/fleuron.png" alt=""/>
  <!-- or, with the optional role -->
  <img src="images/fleuron.png" alt="" role="presentation"/>

• Complex images: a short alt plus an extended description. Charts, maps and diagrams carry more than a sentence can hold. Keep the alt short and link to a fuller description. DAISY notes that “plain old hyperlinks are the most widely accessible way to direct users to a description”; aria-details associates the link with the image (DAISY: image descriptions).

  <figure id="fig-07">
    <img src="images/visitors.png"
         alt="Line chart of annual visitors, rising each year from
              2015 to 2025 except for a fall in 2020"
         aria-details="fig-07-desc"/>
    <figcaption>Figure 7. Visitor numbers since the museum reopened.
      <a id="fig-07-desc" href="descriptions.xhtml#fig-07">Description</a>
    </figcaption>
  </figure>

• Images of text: real text wherever CSS can do the job. A heading set as a picture, a quoted letter scanned in place of its text, or a table saved as an image cannot be resized, searched or read aloud as text. Where an image of text is essential, a facsimile for example, the full wording goes in the alt text if it is short, or in an extended description if it is not.

  <!-- prefer -->
  <h2 class="display-heading">Canto XL</h2>
  
  <!-- if the image itself is the point -->
  <img src="images/letter-1916.jpg"
       alt="Handwritten note: Arrived safely. Tell Mother. Tom."/>

• Figures and captions grouped with figure. figure with figcaption ties a caption to its image. The caption does not replace the alt text, and the alt text should not copy the caption.

  <figure>
    <img src="images/plate-12.jpg"
         alt="Blue-glazed jug with a pinched spout and a single loop handle"/>
    <figcaption>Plate 12. Jug, Delft, about 1680.</figcaption>
  </figure>

Checks for Notes, Quotations and Verse

Books with notes, quoted matter, epigraphs or poetry need four checks of their own. In each, print typography does a structural job that the EPUB has to state in markup.

• Footnotes and endnotes linked both ways. The reference links to the note and the note links back. Both the EPUB type and the ARIA role belong on each: the type gives pop-up notes in reading systems, and the role is what a screen reader reads. The doc-endnote role is deprecated and breaks a list when put on its items. DAISY also notes that wrapping the reference in sup adds verbosity for screen-reader users, and prefers CSS styling in the longer term (DAISY: notes).

  <!-- reference in the text -->
  <p>...the harvest failed that year.<a id="ref2" href="#fn2"
     role="doc-noteref" epub:type="noteref">2</a></p>
  
  <!-- footnote -->
  <aside id="fn2" role="doc-footnote" epub:type="footnote">
    <p><a href="#ref2" role="doc-backlink">2.</a>
       Parish records from 1846 describe the failure in detail.</p>
  </aside>
  
  <!-- endnotes gathered at the end -->
  <section role="doc-endnotes" epub:type="endnotes">
    <h2>Notes</h2>
    <ol>
      <li id="en14"><p>...</p></li>
    </ol>
  </section>

• Block quotations in blockquote, with the attribution outside. blockquote marks an extract and q an inline quotation from another source; q is not for ordinary dialogue in fiction. cite marks the title of a work, never a person’s name, and the HTML specification puts the attribution outside the blockquote (DAISY: quotations).

  <blockquote>
    <p>Towards thee I roll, thou all-destroying but unconquering whale.</p>
  </blockquote>
  <p>Ahab, in <cite>Moby-Dick</cite></p>

• Epigraphs, letters and diary entries. DAISY describes role="doc-epigraph" as typically used on a blockquote or a section (DAISY: doc-epigraph). Putting it on a section lets the source sit outside the quotation, as the blockquote rule above requires. There is no equivalent role for a letter or diary entry, so those take ordinary headings and paragraphs.

  <section role="doc-epigraph">
    <blockquote>
      <p>One generation passeth away, and another generation cometh:
         but the earth abideth for ever.</p>
    </blockquote>
    <p>Ecclesiastes 1:4</p>
  </section>

• Verse with real line breaks and stanzas. One p per stanza, br at each line end, and indentation in CSS rather than spaces or tabs. Leave at least one whitespace character next to each br, or text-to-speech can run the last word of one line into the first of the next (DAISY: poetry).

  <p class="stanza">Tyger Tyger, burning bright, <br/>
  In the forests of the night; <br/>
  <span class="indent">What immortal hand or eye,</span> <br/>
  Could frame thy fearful symmetry?</p>
  
  /* CSS */
  .indent { display: inline-block; padding-left: 2em; }

Checks for Tables and Glossaries

Non-fiction with tabular data or a glossary needs three checks of its own. Reports, monographs, catalogues and textbooks are examples.

• Data tables as real tables, with a caption and header scope. Use table, th and td, with scope on each header and a caption stating what the table shows. DAISY puts it bluntly: images of tables take “the content away from anyone who cannot see it” (DAISY: tables). Our post on why tables break in ebooks covers the layout side of the same problem. Tables used only to position text are a separate fault, and DAISY notes that validation tools such as EPUBCheck “cannot detect layout tables”, so that check is manual (DAISY: layout tables).

  <table>
    <caption>Visitors by gallery, 2025</caption>
    <thead>
      <tr><th scope="col">Gallery</th><th scope="col">Visitors</th></tr>
    </thead>
    <tbody>
      <tr><th scope="row">North</th><td>41,200</td></tr>
      <tr><th scope="row">South</th><td>28,950</td></tr>
    </tbody>
  </table>

• Complex headers with id and headers, only when the table cannot be simplified. Where a cell depends on headers that scope cannot express, such as a row header spanning several rows, give each header an id and list the relevant ones on the cell. DAISY treats needing this as a signal that the table may be better restructured.

  <thead>
    <tr><th id="gal">Gallery</th><th id="yr">Year</th><th id="vis">Visitors</th></tr>
  </thead>
  <tbody>
    <tr>
      <th id="north" rowspan="2" headers="gal">North</th>
      <th id="n24" headers="yr">2024</th>
      <td headers="north n24 vis">38,100</td>
    </tr>
    <tr>
      <th id="n25" headers="yr">2025</th>
      <td headers="north n25 vis">41,200</td>
    </tr>
  </tbody>

• Glossaries as definition lists, linked from the first use in each chapter or section. A dl of terms and definitions in a section with role="doc-glossary". DAISY advises linking only the first use of a term in a new section of the book, because linking every instance clutters navigation for assistive-technology users, and notes that the epub:type glossary semantics “provide no accessibility” (DAISY: glossaries).

  <!-- glossary.xhtml -->
  <section role="doc-glossary">
    <h2>Glossary</h2>
    <dl>
      <dt id="gl-slipware">Slipware</dt>
      <dd><p>Earthenware decorated with liquid clay before firing.</p></dd>
    </dl>
  </section>
  
  <!-- first use in a chapter -->
  <p>The earliest <a href="glossary.xhtml#gl-slipware">slipware</a> in the
  collection dates from the 1680s.</p>

Checks for Print Page Numbers and Indexes

An EPUB that carries the page numbers of a print edition, or that has an index, needs four checks of its own. EPUB Accessibility 1.1 says an EPUB should include page navigation when it and a print edition are generated “from a workflow that allows the retention of page break locations across formats”, which describes an EPUB exported from the same InDesign file as the printed book.

• Page-break markers at the start of each print page’s content. Mark each print page with role="doc-pagebreak" and an aria-label giving the page number. DAISY notes that the label “is currently required even when the number is visible”, and that markers go at the start of the page’s content regardless of whether the number was printed at the top or the foot of the page (DAISY: page breaks).

  <span role="doc-pagebreak" id="pg24" aria-label="24"/>

• A page list in the navigation document. A page-list nav links every marker, which is what lets a reader jump to the page a lecturer or book group has named (DAISY: page list).

  <nav epub:type="page-list" hidden="hidden">
    <ol>
      <li><a href="ch02.xhtml#pg23">23</a></li>
      <li><a href="ch02.xhtml#pg24">24</a></li>
    </ol>
  </nav>

• The pagination source named in the package. EPUB Accessibility 1.1 requires the source of the page numbers to be identified. The Techniques document now recommends the pageBreakSource property with the print ISBN, in place of the older dc:source method; the value none marks page numbers that exist only in the ebook. The source matters because, as the specification notes, hardback and paperback editions of the same book have different pagination.

  <meta property="pageBreakSource">urn:isbn:9780375704024</meta>

• Index entries linked to their locations. The index is a nav with role="doc-index", grouped in sections with lists of entries. Where the locators are page numbers, each links to its page marker, and a range links to its first page with a spoken label (DAISY: indexes).

  <nav role="doc-index">
    <h2>Index</h2>
    <section aria-label="S">
      <ul>
        <li>slipware, <a href="ch02.xhtml#pg24">24</a>,
          <a href="ch05.xhtml#pg49" aria-label="49 to 51">49&#8211;51</a></li>
      </ul>
    </section>
  </nav>

Checks for Maths, Media, Fixed Layout and Read-Aloud

Mathematics, audio and video, fixed layout and read-aloud narration are the least common features a book can contain, and each brings requirements of its own.

• Maths in MathML, not images. Use MathML in its own namespace, without a prefix such as m:, and declare mathml on the manifest item of every file that contains it. An equation as an image cannot be read aloud as mathematics or navigated (DAISY: MathML).

  <!-- content document -->
  <math xmlns="http://www.w3.org/1998/Math/MathML">
    <mfrac><msqrt><mi>a</mi></msqrt><mi>b</mi></mfrac>
  </math>
  
  <!-- package.opf -->
  <item id="ch04" href="ch04.xhtml"
        media-type="application/xhtml+xml" properties="mathml"/>

• Audio and video with captions, transcripts and, at AA, audio description. Captions cover speech and meaningful sound, and a transcript covers audio-only content. For video with audio, DAISY states that transcripts “are not sufficient” at Level AA and that an audio description track is (DAISY: video). Check each retailer as well: KDP says Kindle books do not currently support closed captions in audio or video.

  <video src="video/kiln-firing.mp4" controls="controls"
         aria-label="Firing the anagama kiln">
    <track kind="captions" src="video/kiln-firing.en.vtt"
           srclang="en" label="English"/>
  </video>
  <p><a href="transcripts.xhtml#kiln">Transcript: Firing the anagama kiln</a></p>
  <!-- For Level AA, also provide an audio description track. -->

• Fixed layout only where the design depends on it. The DAISY Knowledge Base notes that WCAG 2.1’s reflow criterion (kept in WCAG 2.2) “will make it difficult for most fixed layout publications” to conform at AA, and recommends reflowable content “when a publication has to be broadly accessible.” Its page on WCAG conformance adds that WCAG 2.0 may be achievable (DAISY: fixed layout and WCAG). Where fixed layout is used, build the pages in HTML rather than as page images, and the text stays real text in a logical reading order, and each page’s images carry alt text.

  <!-- package.opf -->
  <meta property="rendition:layout">pre-paginated</meta>
  
  <!-- each page document -->
  <meta name="viewport" content="width=1200, height=1600"/>
  ...
  <body>
    <img src="images/p12-art.jpg" alt="A fox asleep under an oak tree in snow"/>
    <p class="p12-text">The fox slept all winter.</p>
  </body>

• Read-aloud through media overlays. Synchronised narration uses a SMIL file (the timing file that pairs each text fragment with its audio clip) linked from the manifest. The package gives each overlay’s duration and the total, and the Techniques document identifies the feature as synchronizedAudioText (DAISY: media overlays).

  <!-- package.opf -->
  <item id="ch01" href="ch01.xhtml"
        media-type="application/xhtml+xml" media-overlay="ch01-mo"/>
  <item id="ch01-mo" href="ch01.smil" media-type="application/smil+xml"/>
  <meta property="media:duration" refines="#ch01-mo">0:12:30</meta>
  <meta property="media:duration">1:45:00</meta>
  <meta property="schema:accessibilityFeature">synchronizedAudioText</meta>
  
  <!-- ch01.smil (inside body > seq) -->
  <par>
    <text src="ch01.xhtml#s1"/>
    <audio src="audio/ch01.mp3" clipBegin="0s" clipEnd="4.2s"/>
  </par>

Metadata and Conformance Claims: the Package and the ONIX Feed

Every EPUB needs accessibility metadata in its package, whether or not it claims to conform, and a title distributed through ONIX needs matching codes in the feed. Three checks cover the package and the feed, and the four options for a conformance claim follow them.

• Discovery metadata, which tells retailers and readers what the file supports, in every package. EPUB Accessibility 1.1 requires accessMode (the senses the content uses), accessibilityFeature (what the file provides) and accessibilityHazard (flashing, motion or sound hazards, or none) in every EPUB, whether or not it claims to conform. It recommends accessModeSufficient (the combination of senses that is enough to read it) and accessibilitySummary. The values describe this file, not a template, and the summary says what a reader can expect, including anything the file does not do. Each value takes its own meta element; DAISY says not to merge values “using spaces, commas, or other delimiters” (DAISY: accessibilityFeature). The example is for a book with images that all have text alternatives.

  <meta property="schema:accessMode">textual</meta>
  <meta property="schema:accessMode">visual</meta>
  <meta property="schema:accessModeSufficient">textual</meta>
  <meta property="schema:accessibilityFeature">structuralNavigation</meta>
  <meta property="schema:accessibilityFeature">tableOfContents</meta>
  <meta property="schema:accessibilityFeature">alternativeText</meta>
  <meta property="schema:accessibilityHazard">none</meta>
  <meta property="schema:accessibilitySummary">All images have text
    alternatives. Navigation by chapter and section headings.</meta>

• A conformance claim, when one is made, in the exact form the standard sets. The claim goes in dcterms:conformsTo as a string that matches the pattern “EPUB Accessibility [version] – WCAG [version] Level [level]” exactly, in case and spacing, and a11y:certifiedBy (who evaluated the file) is required. DAISY reads the specification as requiring that property “even when the publication does not meet accessibility requirements”. {c(‘a11y:certifierCredential’)} and a11y:certifierReport are optional (DAISY: evaluation metadata). An EPUB evaluated against EPUB Accessibility 1.0 carries a link to a URL at the IDPF (the International Digital Publishing Forum, which maintained EPUB before the W3C) instead. DAISY’s evaluation page maps each 1.0 identifier to its 1.1 string, and notes that a file that conformed to 1.0 cannot automatically declare conformance to 1.2 or above.

  <package ... prefix="a11y: http://www.idpf.org/epub/vocab/package/a11y/#">
  ...
  <meta property="dcterms:conformsTo">EPUB Accessibility 1.1 - WCAG 2.2 Level AA</meta>
  <meta property="a11y:certifiedBy">Example Press</meta>
  <link rel="a11y:certifierReport" href="https://example.org/a11y/salt-and-iron.html"/>

• ONIX accessibility codes that match the file. In ONIX, accessibility is carried in ProductFormFeature entries with type 09 and values from Code List 196: 04 for EPUB Accessibility Specification 1.1, 82 for WCAG v2.2, 85 for WCAG level AA, and feature codes for what the file provides, such as 11 for table of contents navigation. A file with no conformance claim still carries its feature codes, and can add 08 (unknown accessibility) or 09 (inaccessible, or known limited accessibility) where either describes it honestly. The list also has 75 for a publisher relying on the Act’s microenterprise exemption. Hazards go in entries of type 12 with values from List 143. The DAISY copy of List 196 has no code for EPUB Accessibility 1.2, so check EDItEUR’s current issue before sending a 1.2 claim through ONIX. Google Play Books says it does not read accessibility metadata from the EPUB itself and takes it from the feed or its own settings, while EPUB Accessibility 1.1 still requires it in the package, so both need to be right.

  <ProductFormFeature>
    <ProductFormFeatureType>09</ProductFormFeatureType>
    <ProductFormFeatureValue>04</ProductFormFeatureValue>
  </ProductFormFeature>
  <ProductFormFeature>
    <ProductFormFeatureType>09</ProductFormFeatureType>
    <ProductFormFeatureValue>82</ProductFormFeatureValue>
  </ProductFormFeature>
  <ProductFormFeature>
    <ProductFormFeatureType>09</ProductFormFeatureType>
    <ProductFormFeatureValue>85</ProductFormFeatureValue>
  </ProductFormFeature>
  <ProductFormFeature>
    <ProductFormFeatureType>09</ProductFormFeatureType>
    <ProductFormFeatureValue>11</ProductFormFeatureValue>
  </ProductFormFeature>

A publisher has four realistic options for the conformance claim itself.

• No claim. The package carries the discovery metadata, an honest summary and the name of whoever assessed it in certifiedBy, and dcterms:conformsTo can take the value none. A publisher relying on the European Accessibility Act’s microenterprise exemption can say so with the a11y:exemption property described in a W3C Group Note, the package counterpart of ONIX code 75:

  <meta property="dcterms:conformsTo">none</meta>
  <meta property="a11y:exemption">eaa-microenterprise</meta>

• A self-declared claim. The publisher evaluates the file and names itself in certifiedBy. DAISY confirms that a publisher “can identify themself as the evaluator of their own work”, adding that they “should be confident in the evaluation when doing so.”
• A claim evaluated by a third party. An accessibility specialist evaluates the file and is named in certifiedBy, with certifierReport linking the report if it is public.
• A certified workflow. Some programmes certify a production workflow rather than single titles. Benetech’s Global Certified Accessible programme certifies the workflows of publishers and of conversion vendors against EPUB Accessibility 1.1 and WCAG 2.2 AA; certification follows when three EPUBs from the same workflow pass Benetech’s evaluation, and it is renewed each year. Titles from a certified workflow carry Benetech-certified metadata.

In any claim, the WCAG version and level are the ones actually tested. “EPUB Accessibility 1.1 – WCAG 2.2 Level AA” and “EPUB Accessibility 1.1 – WCAG 2.0 Level A” are both valid claims; only the file decides which is true.

How Do You Test an Accessible EPUB?

Testing an accessible EPUB is layered, and no single tool is enough to support a conformance claim. The first three layers use checking tools; the fourth is reading the book the way its readers will.

• EPUBCheck for validity. EPUBCheck confirms the file is a valid EPUB. DAISY notes that it “does not include many accessibility-related checks”, so a pass says little about accessibility.

  java -jar epubcheck.jar salt-and-iron.epub

• Ace by DAISY for the automated accessibility checks. Ace reports violations such as missing alt text, skipped heading levels and missing metadata. DAISY is clear about its limits: “a clean report only means the issues Ace can check for have passed” (DAISY: Ace).

  ace salt-and-iron.epub --outdir ace-report

• SMART for the manual review. DAISY’s SMART tool takes the Ace report and guides the manual checks a machine cannot make, such as whether alt text says anything useful or whether the reading order makes sense, and produces a report of the evaluation.
• A reading app, with text-to-speech or a screen reader. Open the file, enlarge the text, switch themes, follow the table of contents and the page list, open a footnote and return, and listen to a chapter with an image and a table in it. This is where faults that automated checks cannot see, such as alt text that says nothing, show up.

The markup examples above are short. The time goes on the judgements behind them (what each image contributes, whether a table can be simplified, which level the file can honestly claim) and on building the production file so that the export carries the structure in the first place. For the same subject written for authors, see our guide to making an accessible ebook.

Frequently Asked Questions

Does the European Accessibility Act apply to small publishers?

The European Accessibility Act applies to e-books offered to consumers in the EU, and has done since 28 June 2025. Microenterprises providing services are exempt: those employing fewer than 10 people and with either turnover or balance-sheet total of no more than €2 million. A publisher with ten or more staff is not exempt, and the Directive has no test of where the provider is based. The text of the Directive sets out the definitions; take legal advice on your own position.

Should a publisher claim EPUB Accessibility 1.1 or 1.2?

A publisher should claim the version the file was evaluated against. EPUB Accessibility 1.1 is the W3C Recommendation; EPUB Accessibility 1.2 was published as a Candidate Recommendation Draft on 12 September 2026 and asks not to be cited as other than a work in progress. Carrying both accessMode and accessModeSufficient in the package covers the one change 1.2 makes to which of those properties is required.

Which images need alt text in an accessible EPUB?

Every image in an EPUB that carries information needs alt text, including the cover where it appears as an image in the book. Decorative images such as ornaments and rules take an empty alt attribute so assistive technology skips them, and complex images such as charts and maps need an extended description as well, as the DAISY image descriptions guidance explains.

Can a fixed-layout EPUB be accessible?

A fixed-layout EPUB still needs real text, a logical reading order and alt text, and the DAISY Knowledge Base says WCAG 2.1’s reflow criterion makes Level AA difficult for most fixed-layout publications, and recommends reflowable content when a publication has to be broadly accessible.

Is a clean Ace by DAISY report enough to claim conformance?

A clean Ace by DAISY report is not enough on its own. DAISY says it only means the issues Ace can check for have passed. A conformance claim also needs a manual review of things only a person can judge, such as whether alt text is meaningful and whether the reading order makes sense.

Do retailers read the accessibility metadata inside the EPUB?

Not all retailers read accessibility metadata from the EPUB. Google Play Books says it does not, and takes it from ONIX, Partner Center or a CSV upload instead. KDP asks for accessibility information during title setup. The metadata in the package and in the ONIX feed both need to be right.