How to Make an Accessible Ebook: What to Fix in the EPUB Package

An accessible ebook is one that works for every reader, including people who rely on software that reads books aloud or benefit from very large text. You make an EPUB (the standard ebook file format) accessible with real heading structure, described images, properly built tables, complete navigation, and accessibility metadata, then check it with a free checking tool.

Why Accessible Ebooks Matter (and Who They Help)

Accessible ebooks are digital books built so that people with print disabilities can read them. A print disability is any condition that makes standard printed text hard to use, such as blindness, low vision, or dyslexia. Some readers use a screen reader: software that reads the book aloud or sends it to a braille display, a device that raises braille dots under the reader’s fingertips. Others rely on a custom font or extra line spacing. And others have tremors or limited mobility and navigate by keyboard or voice rather than by tapping a screen.

Accessibility also helps readers with temporary or situational disability: a reader recovering from eye surgery, a parent listening to a book while driving, or anyone whose eyesight has simply aged into needing larger print. The same features serve all of them. Text that can be resized and remain legible, a table of contents that actually works, and images with descriptions benefit every reader, not just those who depend on them.

There is now a legal and commercial push behind this. The European Accessibility Act (EAA), in force since 28 June 2025, requires ebooks sold into the EU to be accessible, wherever the author lives. The Alliance of Independent Authors (ALLi) guide to the EAA explains the details, including an exemption for micro-enterprises (under 10 employees and under €2 million turnover), which covers most indie authors. The exemption is not the whole story, though: the stores that sell your book are not exempt, so retailers increasingly ask for accessibility information and promote books that provide it. An accessible file is becoming a sales asset rather than a nice-to-have.

What Makes an Ebook Accessible?

Under the surface, an ebook is a set of web pages. An EPUB file is a compressed folder of HTML files (the same language websites are written in), plus a package file that lists what is inside. Screen readers and reading apps understand HTML very well, which is why EPUB 3, the current version of the format, is the standard for accessible books. A reflowable EPUB 3 (one where text resizes and rewraps freely, rather than being locked to a fixed page) is the right foundation for the kinds of books this article covers: novels, memoirs, self-help, and other text-led books.

Accessibility work happens in two places. A little of it belongs to you as the author: describing your images and keeping tables simple. The rest belongs to whoever builds the EPUB (you, a tool, or a formatter): correct HTML structure, a complete navigation file, and the right metadata. In our own formatting work at ebookpbook, that tagging is our responsibility, not the author’s: we build the heading structure, image markup, and metadata into the EPUB whatever state the manuscript arrives in. What only you can supply is knowledge of the book itself, and the sections below flag the few places where that input matters.

Each section below covers one type of content and shows a small example of the HTML inside an accessible EPUB. You do not need to write this code yourself. The examples are there so you can recognise good structure, check your own file, or ask your formatter the right questions.

Headings: Build Real Structure, Not Big Bold Text

Chapter and section titles must be real headings in the HTML of the ebook file, not ordinary paragraphs made to look big. HTML has six heading levels, <h1> down to <h6>, and screen readers use them as a skeleton of the book: any reader can pull up a list of headings and jump between chapters in seconds. Bold text carries none of that meaning. To a screen reader, a bolded chapter title is just another paragraph.

Here is the difference in code. This looks like a chapter title but is invisible to a screen reader’s heading list:

<p><strong>Chapter 3: The Long Road Home</strong></p>

This is a real heading that every screen reader recognises:

<h1>Chapter 3: The Long Road Home</h1>

Two rules keep the structure sound. First, do not skip levels: a section inside a chapter takes the next level down (an <h2> under an <h1>), never a jump from <h1> to <h4> because the smaller size looked nicer. Second, if you are converting the manuscript yourself, this starts in your word processor. Every mainstream word processor has built-in heading styles (Heading 1 and Heading 2 in Word, for example), and conversion tools carry them straight into correct HTML. If a formatter builds your EPUB, this tagging is their job, not yours.

Images: Write Alt Text for Pictures That Matter

Alt text (alternative text) is a short written description attached to an image, which a screen reader speaks aloud in place of the picture. Every image that carries meaning needs it: the photographs in a memoir, a map, a chart in a self-help book. Without alt text, a screen reader announces something like “image” and the reader gets nothing.

Good alt text is short, specific, and focused on why the image is there. Skip openers like “image of” (the reader already knows it is an image) and describe what matters in context:

<img src="wedding-photo.jpg"
     alt="The author's parents outside a small stone church
          on their wedding day in 1962"/>

Purely decorative images work differently. An ornamental border or a chapter-head flourish adds nothing a listener needs, so it is marked with empty alt text and a presentation role, which tells screen readers to skip it silently:

<img src="ornament.png" alt="" role="presentation"/>

Leaving the alt attribute off entirely is not the same thing: some screen readers then read out the file name, which is worse than silence.

Scene breaks look decorative but are not. The row of asterisks between scenes marks a real shift in time or place, and someone listening to the book needs that signal as much as someone looking at the page. The DAISY accessibility knowledge base recommends marking these breaks with the HTML rule element (<hr/>), which screen readers announce as a break in the text; the ornament can then be applied as pure styling on top. The principle runs through all of this markup: convey the function (a scene break), never the appearance (a row of asterisks).

Writing the descriptions is a shared job. When we build ebooks with photographs, we ask you for a description of each image up front, because only you know that the woman in the doorway is your grandmother. And although we can describe a chart or graph based on its visual appearance alone, you know for sure which data points are most important in the context of your argument.

One caution if your images have printed captions: the caption should not simply be copied into the alt text, because screen readers read both, and the listener hears the same words twice. The alt text describes what is in the picture; the caption keeps doing its own job alongside it.

Tables: Use Real Rows and Columns, Not Screenshots

A table pasted in as a picture is unreadable to a screen reader and turns blurry when text is enlarged. An accessible table is built from real HTML rows and cells, so a screen reader can walk through it cell by cell and announce which column and row each value belongs to.

The key detail is the header cell. Column headings use <th> (table header) instead of <td> (table data), with a scope attribute saying what the header applies to:

<table>
  <tr>
    <th scope="col">Year</th>
    <th scope="col">Copies sold</th>
  </tr>
  <tr>
    <td>2024</td>
    <td>1,200</td>
  </tr>
</table>

With those header cells in place, a screen reader reads “Copies sold: 1,200” rather than a bare “1,200” floating without context. Keep tables simple: one header row, no merged cells where you can avoid them, and no tables used purely to position text on the page. If the information would read naturally as a sentence or a list, use a sentence or a list instead.

Links, Lists, Footnotes, and Language

Link text should say where the link goes. Screen reader users often pull up a list of all the links in a chapter and hear them out of context, so a list of “click here, click here, click here” is useless. “See the publisher’s large-print guidelines” works on its own.

Lists need real markup too. When items are tagged as a bulleted list (<ul>) or a numbered list (<ol>), a screen reader announces “list, three items”, reads each entry separately, and lets the reader skip the whole list in one move. Hyphens or numbers typed at the start of ordinary paragraphs give none of that. Use a numbered list when the order matters (steps to follow, chapters in sequence) and a bulleted list when it does not:

<ul>
  <li>Trim size</li>
  <li>Page count</li>
  <li>Paper colour</li>
</ul>

Footnotes and endnotes need to link both ways: from the marker in the text to the note, and from the note back to the reading position. EPUB 3 has purpose-built labels for this, so reading apps can show the note as a pop-up instead of yanking the reader to the back of the book:

<p>...the harvest failed that year.<a epub:type="noteref"
   role="doc-noteref" href="#fn2">2</a></p>

<aside epub:type="footnote" role="doc-footnote" id="fn2">
  <p>2. Parish records from 1846 describe the failure in detail.</p>
</aside>

Language tagging is the quietest fix on this list and one of the easiest. The book declares its main language once, and any passage in another language gets its own tag. Without it, text-to-speech reads French dialogue with English pronunciation rules and produces gibberish:

<html lang="en" xml:lang="en">
...
<p>She smiled and whispered, <span lang="fr"
   xml:lang="fr">bonne chance</span>.</p>

Navigation: Help Readers Jump Straight to Any Chapter

Every accessible ebook needs a machine-readable table of contents: a dedicated navigation file that reading apps use to power their chapter menus. In EPUB 3 this is the navigation document, an ordinary HTML file with a special role. It replaced the older NCX file that EPUB 2 used for navigation, and unlike the NCX it can also be shown to the reader as a styled contents page.

A minimal navigation document looks like this:

<nav epub:type="toc" role="doc-toc">
  <h2>Contents</h2>
  <ol>
    <li><a href="chapter1.xhtml">Chapter 1</a></li>
    <li><a href="chapter2.xhtml">Chapter 2</a></li>
  </ol>
</nav>

The contents list must be complete: every chapter and every major section, not just the parts that fit a design. The same file can carry two optional extras. Landmarks give one-tap access to key points such as the start of the text. A page list maps locations in the ebook to the page numbers of a print edition, so a book club with mixed print and ebook copies can all find “page 148”; if your book has a print edition, it is worth asking your formatter for a page list to be included in the ebook.

Accessibility Metadata: Tell Stores What Your Ebook Supports

Metadata is information about a book rather than the book itself: its title, its author, and now its accessibility. Accessibility metadata is a set of statements inside the EPUB’s package file that declares what the book supports, in a standard vocabulary that stores and reading apps understand. This is the step most guides skip, and it matters because an accessible book without metadata cannot be found or labelled as accessible. The EPUB Accessibility 1.1 specification from the W3C (the World Wide Web Consortium, the body that sets web standards) requires three fields as a minimum: access mode, accessibility features, and any hazards, such as flashing content. It also recommends a human-readable summary alongside them.

In the package file, the entries look like this for a simple text-led book:

<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessModeSufficient">textual</meta>
<meta property="schema:accessibilityFeature">alternativeText</meta>
<meta property="schema:accessibilityFeature">structuralNavigation</meta>
<meta property="schema:accessibilityFeature">tableOfContents</meta>
<meta property="schema:accessibilityHazard">none</meta>
<meta property="schema:accessibilitySummary">This publication
  has complete structural navigation, alt text on all
  informative images, and no hazards.</meta>

In plain English: the book’s content is text (so it can be read visually, spoken aloud, or sent to braille), it has alt text and a full navigation structure, and it contains nothing hazardous. A separate conformance declaration can state which standard the book meets, naming EPUB Accessibility 1.1 and a WCAG level (the Web Content Accessibility Guidelines, the same standard websites are measured against).

Stores have started acting on this information. Amazon KDP now asks about accessibility features during eBook title setup and shows readers an accessibility section on the book’s detail page, covering visual adjustments, nonvisual reading, and hazards. Other major ebook stores now display accessibility details on book pages too, and some let readers filter search results to accessible books only. Metadata is how your book gets counted in those filters.

Tools That Create and Check Accessible Ebooks

Nobody builds an accessible ebook by typing HTML line by line. Free tools exist for both halves of the job: creating an accessible EPUB from a manuscript, and checking one you already have.

For creation, WordToEPUB, a free Windows tool from the DAISY Consortium (the international non-profit behind most accessible-reading standards), converts a Word manuscript into an accessible EPUB 3 from a button inside Word itself, and also accepts documents exported from Google Docs, LibreOffice Writer, and Apple Pages. It rewards the manuscript preparation described earlier: heading styles and alt text written at the manuscript stage carry straight through. The same principle holds outside Word and Windows: professional layout software and most modern formatting tools can produce accessible EPUB 3 files, and a formatter can build the accessibility in for you. In our own InDesign builds, the alt text and heading structure are attached during the build so the exported EPUB starts accessible rather than being repaired later.

For checking, Ace by DAISY is the most widely used accessibility checker. Point it at your EPUB and it produces a readable report listing violations (missing alt text, skipped heading levels, missing metadata) with links to guidance for fixing each one. It checks accessibility specifically, so run it alongside EPUBCheck, the format validator that confirms your EPUB is correctly built before you upload it: EPUBCheck asks “is this a valid EPUB?”, Ace asks “is it accessible?”.

Finally, test like a reader. Thorium Reader, a free desktop reading app built with accessibility as its focus, lets you open your finished EPUB, try the read-aloud feature, enlarge the text, and step through the navigation. Ten minutes of that reveals problems no automated checker reports, such as alt text that is technically present but says nothing useful.

Accessibility is mostly good bookmaking under a newer name: clear structure, described images, honest navigation, and a file that says what it contains. Fix the headings, alt text, tables, links, navigation, and metadata described above, run Ace by DAISY and EPUBCheck over the result, and spend ten minutes reading your own book the way a screen-reader user would. Most text-led books are much closer to accessible than their authors expect.

Frequently Asked Questions

What is an accessible ebook?

An accessible ebook is a digital book built so people using screen readers, text-to-speech, braille displays, or large text can read it fully. In practice that means a reflowable EPUB 3 file with real heading structure, alt text on meaningful images, a complete navigation file, and accessibility metadata.

Do self-published authors have to comply with the European Accessibility Act?

Most indie authors fall under the European Accessibility Act’s micro-enterprise exemption (fewer than 10 employees and under €2 million turnover), so the EAA does not apply to them directly. Retailers selling into the EU are not exempt, however, so stores increasingly expect accessibility information, and accessible files travel better across all sales channels.

How do I check whether my EPUB is accessible?

To check an EPUB’s accessibility, run the free Ace by DAISY checker for a full accessibility report, run EPUBCheck to confirm the EPUB is correctly built, and then open the book in a reading app such as Thorium Reader to test read-aloud, text enlargement, and chapter navigation yourself.

Does a novel with no pictures need accessibility work?

A text-only novel still needs accessibility work, though less than an illustrated book. It needs real HTML headings for each chapter, a complete navigation file, a declared language, descriptive link text, and accessibility metadata in the package file. With those in place, a plain novel is one of the easiest books to make fully accessible.

Are fixed-layout ebooks accessible?

Fixed-layout EPUBs lock the page design, so readers cannot enlarge or reflow the text, which defeats a core accessibility feature. They exist for heavily visual books such as children’s picture books and comics. For text-led books like novels, memoirs, and self-help, a reflowable EPUB 3 is the accessible choice.