Skip to main content
WCAG Auditor · EAA Resource Center

E-books

E-books and the software made to read them. This includes reading apps and how they handle navigation, reflow and text-to-speech.

This overview is informational, not legal advice. Whether a given product or service is in scope is a legal call for your organization to make.

What the EAA covers here

Annex I groups e-books with “the dedicated software” used to read them, which is a deliberate pairing: an e-book’s accessibility depends on both halves at once. A well-structured file opened in a reading app that ignores that structure is no more usable than a flat scan opened in a well-built one. Neither half is reviewed in isolation here.

That reach extends to what publishers and retailers make available to consumers — trade e-books sold or lent for consumer reading — rather than every digital document a publishing house produces internally.

The book and the reader, together

The file itself carries structure: headings, a table of contents, reading order, alternative text for images and diagrams, and language markup. The reading software carries the controls that act on that structure: whether the reader can resize or reflow text without losing content off the edge of the screen, whether navigation (jumping to a chapter, a bookmark, a specific page) is exposed as real controls rather than only a swipe gesture, and whether a built-in read-aloud or text-to-speech feature actually uses the file’s structure instead of just reading a flat stream of characters.

Reflow, navigation, and text-to-speech

These three are where most of the practical work concentrates. Reflow is what lets a reader with low vision increase text size without resorting to pinch-zooming a fixed page image. Navigation is what lets a screen reader or switch-access user move by chapter or heading instead of paging through one screen at a time. Text-to-speech support — whether built into the app or handed off to the platform’s own screen reader — depends entirely on the file exposing real text and structure for it to read from; a scanned page image defeats all three at once, however sharp the scan looks.

What auditors look at first

A review typically opens the file’s underlying structure before touching the reading app: is there a genuine text layer, are headings marked as headings rather than just styled to look like them, and is the table of contents a real navigable list. It then moves to the app itself — resize and reflow behaviour, whether every navigation control has a keyboard equivalent, and whether alternative text written into the file actually reaches the read-aloud feature rather than being silently dropped.

What typically fails here

Recurring accessibility failures in this area. Illustrative — an audit reports what your own surfaces actually do.

  • E-books published as scanned page images with no underlying text layer at all.
  • Reading apps that lock font size and line spacing to a single fixed value.
  • A table of contents that isn't exposed as a navigable landmark or list.
  • Read-aloud features that skip captions on embedded images and diagrams entirely.
  • Footnotes and cross-references that can't be reached by keyboard or screen reader.

EN 301 549 clauses this maps to

Clauses from our v3.2.1 report catalog — a curated subset of the standard, not the complete list of clauses that may apply to you.

  • 10.1.1.1 Non-text Content (non-web documents)
  • 10.1.3.1 Info and Relationships (non-web documents)
  • 10.1.3.2 Meaningful Sequence (non-web documents)
  • 11.1.3.2 Meaningful Sequence (software)
  • 11.1.4.4 Resize Text (software)
  • 11.2.1.1 Keyboard (software)
  • 5.1.3.2 Auditory output delivery including speech

Next: what a conformance report contains, or run the 2-minute readiness check.

Check your EAA readiness

A 2-minute, browser-only questionnaire. No answers are sent anywhere.