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.