Reading order in an EPUB is defined by the spine in the package document, not by filenames and not by the table of contents. Structure comes from HTML headings used in an unbroken hierarchy, and from sectioning elements that separate the main narrative from asides.
One widely repeated belief is worth correcting immediately: the epub:type attribute does not help assistive technology.
The Spine Defines Reading Order
EPUB 3.3 is unambiguous: "The spine element defines an ordered list of manifest item references that represent the default reading order."
It has to be complete. The spec requires that creators "MUST list in the spine all EPUB and foreign content documents that are hyperlinked to from publication resources in the spine", and adds that "The requirement to list hyperlinked resources applies recursively." A file you link to but forget to add to the spine is a conformance failure, and at some retailers an import failure.
EPUB Accessibility 1.1 gives the canonical example of how this breaks a book even when every individual file is perfect: "it is not sufficient for EPUB creators to order the content within individual EPUB content documents if they list the documents in the wrong order in the spine."
Linear and Non-Linear Content
The spine can mark items as auxiliary. The spec defines the distinction precisely:
"The linear attribute indicates whether the referenced item contains content that contributes to the primary reading order and that reading systems must read sequentially ("yes"), or auxiliary content that enhances or augments the primary content that reading systems can access out of sequence ("no"). Examples of auxiliary content include notes, descriptions, and answer keys."
Two cautions. It is only a hint: "Specifying that content is non-linear does not require reading systems to present it in a specific way", and a system may show it in place or defer it to the end. And you remain responsible for access: "EPUB creators MUST provide a means of accessing all non-linear content." Marking something non-linear does not excuse leaving it unreachable.
Endnote pages and long image descriptions are the natural candidates. Chapters never are.
Headings Carry the Structure
Assistive technology navigates by heading level, so the hierarchy is a navigation interface rather than a styling choice.
DAISY's guidance: "Headings should reflect the hierarchy of the publication, so an h2 should always be used for secondary level headings, h3 for tertiary, and so on", and "Avoid gaps in numbering whenever possible (e.g., using h3 for headings below an h1)". The reason is concrete: screen readers offer shortcut keys to jump by heading number, so a skipped level makes a section unreachable by that route.
One rule that catches people out: do not put heading elements inside figure, blockquote or other sectioning roots. A caption is not a heading.
Never choose a heading level for its size. Size is CSS. The level is structure.
Reading Order Versus Visual Order
WCAG 2.2 success criterion 1.3.2, Meaningful Sequence, at Level A: "When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined."
The divergence happens when content is positioned visually rather than ordered logically. A pull quote placed mid-paragraph in the markup interrupts the sentence for a listener even though it sits neatly in the margin for a viewer. A sidebar that visually follows a section but precedes it in the file is read early.
DAISY's remedy is structural: use <section> for primary content and <aside> for secondary, so that "Separating secondary content from the primary allows users of assistive technologies to more easily follow the main narrative." The reader then gets "a logical path that excludes the secondary material and orders the primary".
The check is simple. Read the markup top to bottom, ignoring all styling. If it makes sense in that order, the reading order is right.
The Navigation Document Is Mandatory
Every EPUB "MUST contain an EPUB navigation document", and that document "MUST include exactly one toc nav element". This is the real table of contents, and it is required whether or not you want a visible contents page. That is why even a novel needs one.
The spec also asks that its order match the book: creators "SHOULD order the references in the toc nav element such that they reflect both: the order of the referenced EPUB content documents in the spine; and the order of the targeted elements within their respective EPUB content documents."
Two Corrections Worth Carrying
epub:type does not improve accessibility. DAISY states it directly: the attribute "can enhance the user experience in EPUB reading systems but does not improve the accessibility in assistive technologies." Where semantics need to reach a screen reader, pair it with an ARIA role.
Accessibility metadata applies to every EPUB version, and to publications making no conformance claim. EPUB Accessibility 1.1 states: "All EPUB publications MUST include accessibility metadata in the package document that exposes their accessible properties, regardless of whether the publications also meet the accessibility or optimization requirements." The required properties are accessMode, accessibilityFeature and accessibilityHazard, with accessibilitySummary and accessModeSufficient recommended.
Two clarifications, because both are easy to get wrong. The specification is deliberately version-agnostic: "This specification does not target a single version of EPUB. It is applicable to EPUB publications that conform to any version or profile, including future versions of the standard." And the requirement lives in the accessibility specification rather than in the base EPUB format, so a file without accessMode is not a malformed EPUB, it is a file that does not conform to EPUB Accessibility 1.1. That is why this is a commercial question rather than a validation one. See ebook metadata explained.
What Deckle Does
Deckle builds the package document itself, so the spine is generated from your Binder order rather than assembled by hand. Every content document it writes is listed, which satisfies the completeness requirement above, and the reading order matches the order you see in the app.
Headings follow your document structure: chapter titles become the top level and subheadings the next, so the hierarchy is inherited from how you organised the manuscript rather than chosen per document.
The navigation document is generated, with one thing to watch: it is only written when the Include table of contents option is on. Since the specification requires it, exporting with that option off produces a file that fails validation and is rejected by Apple. Leave it on for EPUB export.
Deckle writes the required accessibility metadata, and every value is derived from the book rather than asserted. accessMode is textual, gaining visual only when the manuscript actually contains body images. accessibilityFeature always claims structuralNavigation and readingOrder, adds tableOfContents when the navigation document is written, and adds alternativeText only when every body image carries a text alternative. A single undescribed image withdraws that claim, because a partial one tells a reader relying on assistive technology that the book is usable when it is not. accessibilityHazard is none, since the export contains no scripting, audio or video.
The optional accessibilitySummary is not written, and deliberately so. The specification asks that it "complement, but does not duplicate, the other discoverability metadata" and describe "any known deficiencies", which is author-written prose about the book's shortcomings. A generated one would be worse than none.
See European EPUB requirements for why this matters commercially.
For the image side of conformance, see alt text for ebook images, and for the language attributes that assistive technology depends on, how to add language metadata to an EPUB.
Common Mistakes
- Skipping heading levels for visual reasons. Size is CSS; the level is navigation.
- Leaving a linked file out of the spine. The requirement is recursive and a common import failure.
- Marking chapters non-linear. That is for notes and descriptions, not narrative.
- Trusting
epub:typeto convey semantics to a screen reader. It does not. - Ordering content visually. Read the markup top to bottom and check it still makes sense.
- Exporting without the navigation document. It is required, and Apple gates on validation.
FAQ
Q: What actually determines the order chapters are read in? A: The spine in the package document. Filenames and the visible contents page do not.
Q: Does the table of contents have to match the spine? A: The spec says it should, in both document order and within-document order.
Q: Can I hide the endnotes from the main flow? A: Mark them non-linear in the spine, but you must still provide a way to reach them.
Q: Is an NCX needed for accessibility? A: No. It is EPUB 2 legacy. The navigation document is the required one.
Q: Does accessibility metadata apply if I make no conformance claim? A: Yes. The specification requires it of all EPUB publications regardless.