| Takeaway | Detail |
|---|---|
| Pass EPUBCheck before release. | A 2026 EPUB release is defensible only if it passes EPUBCheck. |
| Expose complete accessibility metadata. | The EPUB must include complete accessibility metadata. |
| Resolve every blocking defect. | After keyboard, navigation, semantics, and screen-reader checks, zero unresolved blocking defects may remain. |
| Require automated and manual validation. | Release only if machine validation and every mandatory manual accessibility check pass; otherwise, correct the file or ship a more accessible alternative. |
This guide defines a release gate requiring EPUBCheck success, complete accessibility metadata, and zero unresolved blocking defects. It also covers keyboard, navigation, semantics, and screen-reader checks, with correction or a more accessible alternative required whenever a mandatory check fails.

Validate the Publication Package
Run EPUBCheck 5.x against the final packaged EPUB file, not an earlier manuscript export or a working copy that has not yet been assembled. Packaging can change file locations, references, encodings, and metadata, so validation must reflect the exact artifact intended for release. Treat every error as release-blocking. Review every warning explicitly and record whether it is accepted, corrected, or escalated for investigation; a warning is not automatically harmless, but neither should it be confused with a machine-detected error. The release decision belongs to the validation of the final package, not to an earlier draft.
After validation, inspect the packaged publication as a complete system. Confirm that the OPF package document is present and correctly identifies the publication, that the navigation document is included and usable, and that every content document referenced by the package or navigation structure can be resolved. Check media resources as well: each file must exist at its referenced location, remain accessible to the reading system, and retain the format or encoding required by its declaration. Verify that the accessibility metadata is present in the final package rather than merely present in a source document that lost it during conversion.
Use the validation report to support, not replace, a manual inspection. Open the EPUB in supported reading systems and test navigation, link activation, document order, text reflow where supported, media behavior, and the availability of controls and labels. Check the content documents and navigation document for headings, lists, landmarks, tables, links, images, and other structures that automated tools cannot reliably judge. A clean EPUBCheck result establishes that machine-testable requirements passed; it does not establish that a reader can navigate the publication effectively with a keyboard or screen reader.
For an image-only publication, machine validation cannot support an accessible release until the content has been made available as structured text. Require OCR for the page images, establish a deliberate reading order, provide text alternatives for meaningful visual information, and add semantic structure for headings, paragraphs, lists, and other identifiable relationships. If the images are essential, ensure that their role and any accompanying text are clear to assistive technology. If OCR or semantic recovery is incomplete, correct the publication before release rather than treating the image layer as a substitute for an accessible document structure.
Use a release threshold with no ambiguity: the final EPUB may ship only when EPUBCheck 5.x reports zero errors, every warning has been reviewed, the packaged resources and metadata are confirmed in their referenced locations, and the mandatory keyboard, navigation, semantics, and screen-reader checks have no unresolved blocking defects. If any requirement remains unresolved, correct the file or provide a more accessible alternative. Keep the validation report, warning decisions, and manual check results with the release record so that the final package—not an earlier version—can be audited.

Make Accessibility Discoverable
Populate the EPUB package with publication-specific values for schema:accessMode, schema:accessibilityFeature, schema:accessibilitySummary, and schema:accessibilityHazard. The values must describe what this edition actually contains: identify the applicable access modes, name supported features, explain any known hazards, and avoid generic or aspirational claims. Before release, compare every statement with the final content and remove any feature that cannot be demonstrated during review. A claim such as “structured navigation” is useful only if the EPUB includes a meaningful navigation document; “alternative text” is not warranted if meaningful images lack equivalent text or an equally effective textual alternative.
The EPUB Accessibility 1.1 metadata block tells discovery systems how the publication presents content and what accessibility features it provides. Check the metadata independently of the visual appearance of the reader software. A polished interface cannot compensate for missing, malformed, or misleading accessibility metadata, and a well-described file still requires inspection of the publication itself. Validate the metadata structure, vocabulary terms, and relationships in the packaged file, then confirm that each declared value remains consistent with the content delivered in that same release.
Use schema:accessibilitySummary to give reviewers a practical map they can assess before downloading the EPUB. Describe the navigation structure, heading hierarchy, treatment of alternative text, and reading order in enough detail to distinguish a deliberate implementation from an unsupported label. For example, identify the principal navigation landmarks, explain how headings divide and nest sections, state how complex images are represented, and clarify whether sequential reading order follows the intended interpretation of the text. Do not use the summary as a substitute for those checks; it is evidence that helps reviewers understand the publication, not proof that the underlying implementation is complete.
Apply a simple release threshold: publish the 2026 EPUB only when machine validation passes, its accessibility metadata is complete, and every mandatory keyboard, navigation, semantics, and screen-reader check has been resolved. If the file fails any part of that sequence, correct the EPUB or ship a more accessible alternative. Do not waive a failure merely because the metadata looks credible or the publication renders correctly on one device.

Choose Reflowable EPUB Deliberately
For a 2026 publication, the best general-purpose delivery choice is a well-structured reflowable EPUB 3.3 publication, not a fixed-layout facsimile or an untagged PDF surrogate. Reflowable EPUB is preferable when semantic structure and cross-platform reading-system support are the primary requirements: the text can reflow for different screen sizes, while headings, lists, links, landmarks, tables, and other structural elements remain identifiable. HTML can offer strong semantics and broad browser support, but it does not by itself provide a portable, managed publication package for e-book distribution. Compare the formats by testing navigation, reflow, reading order, and the availability of structural semantics in the actual delivery environment rather than by assuming that visual polish equals accessibility.
Choose fixed-layout EPUB 3.3 only when the page design itself conveys essential meaning. A textbook diagram, map, or comic sequence may lose information if its text is separated from its spatial arrangement; in that case, preserve the spread relationships and provide complete text alternatives for every meaningful visual element. Check the logical reading order across every spread, including transitions between facing pages, and verify that navigation can move predictably through the publication. Do not use fixed layout merely to reproduce print appearance when the content can be expressed semantically and reflowed without losing meaning.
Select tagged PDF as a secondary channel when contractual, print-oriented, or reader-system requirements demand it. A PDF may be necessary for a workflow that requires a fixed page presentation, but it should carry appropriate tags, reading order, alternative text, language information, and document structure. Test the final PDF with keyboard navigation and assistive technology, and confirm that its links, annotations, tables, and form controls are both semantically identified and usable. If the PDF is only a convenience copy, ensure that the accessible EPUB remains the primary edition rather than allowing the PDF to substitute for an accessible reading experience.
Use HTML when the intended environment is a web browser or when a continuously updated web edition is part of the delivery plan. The check is practical: keyboard users must reach every interactive element, screen readers must announce meaningful names and states, and the reading order must remain sensible when stylesheets or content width change. HTML still needs deliberate testing; semantic markup is a foundation, not proof of a successful reading experience. Whichever format leads, keep the same editorial structure and meaning across editions, and remove contradictory instructions or inaccessible fallbacks before release.
Budget for Human Verification
Set the 2026 accessibility budget in staff-hours, separating required inspection from remediation, because automated validation does not perform a complete usability evaluation. For planning, reserve 8–16 hours for a short, text-first publication and 24–80 hours for a heavily illustrated, equation-rich, or fixed-layout publication. These are effort ranges, not quality guarantees: complexity, the accessibility maturity of the source files, and the number of content documents can move the work toward either end. Record the actual hours spent by task and role so the next release has a more reliable estimate.
Use the budget to schedule a complete manual pass, not merely a spot check. Inspect the table of contents and every navigation link with the keyboard; confirm that focus remains visible, follows the expected sequence, and does not become trapped. Review headings, landmarks, lists, tables, figures, equations, links, and control names in the reading interface. Then test representative sections with a screen reader, including the beginning, a dense middle section, and the end. Record each failure with its location, reproduction steps, affected format or reading system, and severity.
Track remediation labor as a separate line item. Repeated manual navigation failures usually consume more time than a clean machine-validation run, especially when the same heading, link, or reading-order problem appears throughout the publication. For each correction, rerun the affected manual check immediately rather than waiting until the entire review is finished. After all edits, regenerate the final package and perform another validation pass; an earlier result cannot certify the replacement file. Verify that required accessibility metadata remains present and accurate after repackaging.
Price the release decision by defect risk rather than by the number of automated checks passed. One missed heading level, inaccessible control, or broken reading-order sequence can block a reader at the point of use even when the package is technically valid. Treat any unresolved instance in required navigation, semantics, keyboard operation, or screen-reader communication as release-blocking. A lower-risk issue may receive a documented decision only when it does not prevent access to essential content or use of required functions; otherwise it must be corrected.
Before release, require both a completed manual checklist and a final report showing the exact publication tested, the validation result, the defects found, the remediation performed, and the hours recorded. If any blocking defect remains, do not release that EPUB. Correct and retest it, or ship a more accessible alternative. This creates a practical threshold for 2026: measured human effort, traceable findings, zero unresolved blocking defects, and a final package that reflects every approved change.

Bound What Passing Can Prove
Build the release test matrix around three distinct environments: at least one native mobile reading system, one desktop reading system, and one screen-reader workflow. In each environment, verify that the publication opens without repair prompts, that reading order follows the intended sequence, and that navigation, links, tables, lists, images, and control elements remain understandable. A successful test in the preferred reader is useful evidence, but it cannot establish consistent behavior across reading systems. Record the application, operating system, assistive technology, and version used so each result is reproducible.
Test interaction with zoom, reflow, high contrast, captions, transcripts, and motion preferences separately. Do not infer safety from a metadata declaration that lists no hazardous features. Change the relevant display or user settings and confirm that text remains readable, controls do not disappear, contrast remains distinguishable, captions and transcripts are available when the content requires them, and motion is reduced or disabled according to the reader’s preferences. A failure in any of these checks is a release blocker until corrected or the publication is replaced with a more accessible alternative.
For the screen-reader workflow, navigate the entire publication without relying on visual cues. Move forward and backward through the reading order, activate every interactive element, inspect headings and landmarks, and confirm that alternative text communicates the purpose of each image. Check that decorative material is not announced unnecessarily and that meaningful images are not skipped. For mathematical expressions, code, footnotes, and other specialized structures, compare the announced result with the visible source. Any unexplained loss of content, incorrect sequence, or inaccessible control prevents release.
Keep final spot checks on current stable reader versions because navigation behavior, font support, and assistive-technology interpretation can change independently of the publication file. Run the complete release gate again after replacing the EPUB package, changing fonts, revising navigation, or updating accessibility metadata. Preserve the validation report alongside the manual test notes, including failures resolved before release. The release criterion is exact: machine validation passes and every mandatory manual accessibility check passes.
Finally, state the evidence accurately. A clean validation report proves conformance to tested machine checks, not universal usability by every reader with every assistive technology combination. That distinction keeps the release claim precise: the EPUB has passed the specified technical and human checks, while continued testing across updated readers remains a maintenance responsibility.
Test a 120-Page Illustrated Book
For a representative 120-page illustrated book, establish a measurable release gate rather than relying on subjective assurance. A representative 120-page illustrated book can be gated with 120 page checks, 120 alternative-text decisions, and a sampled reading-order review rather than subjective assurance. The checklist should identify every page, image, figure, and sampled navigation sequence by stable location, so each result can be reproduced and tracked through revision.
Require all 120 pages to receive EPUBCheck review, all 120 figures to receive an accessibility decision, and 12 page-level samples to receive keyboard and screen-reader navigation checks. For each figure, the decision should record whether its purpose is conveyed in adjacent text, whether alternative text is concise and informative, or whether the image should be marked decorative. A blank decision is not a pass. Likewise, the 12 samples should cover the opening pages, major illustration sequences, section transitions, captions, lists, tables, links, and the final page rather than choosing adjacent pages that make navigation appear easier than it is.
Set the page-level threshold at zero unresolved blocking defects. If 118 of 120 pages pass, record page coverage as 98.3 percent: 118 ÷ 120 = 0.9833, which rounds to 98.3 percent at one decimal place. Even with that high coverage, block release if the two remaining pages contain unresolved figures or other blocking accessibility defects. High aggregate coverage cannot compensate for a known failure on a page that a reader may encounter.
Keep the review traceable. For every failed page, record the page location, affected element, check performed, observed behavior, responsible revision, and retest result. For the sampled navigation checks, document the keyboard path, visible focus order, expected reading order, announced name or description, and whether captions or figure labels remain associated with the correct image. A release candidate is eligible only when the final report contains no open blocking defect and confirms that all required accessibility metadata is present and complete.
Revise the test scope when the publication changes. If a revision changes 30 pages, rerun package validation and all 30 page-level checks rather than relying on results from the earlier candidate. Reassess every affected figure, rerun keyboard and screen-reader navigation through each changed sequence, and verify that cross-references, reading order, and metadata remain accurate in the final package. The 30 affected pages then rejoin the full release tally; previously completed checks may stand only when the revision demonstrably does not affect them.
Apply the Final Release Rules
The release decision is controlled by five binary gates, not by a weighted accessibility score. Those gates are package validation, accessibility-metadata completeness, keyboard operation, navigation and semantics, and screen-reader operation with text alternatives. Each must be marked pass or fail. A single failure blocks release, regardless of how well the EPUB performs in the other areas or how many minor observations remain. A numerical score cannot compensate for a failed mandatory check.
Begin the final gate with EPUBCheck. If it reports an error, correct the EPUB and rerun the check until no errors remain. If it reports a warning, do not dismiss it automatically: inspect the reported condition, determine whether it affects conformance or usability, and document its disposition. The release record should identify the final file checked and show that the results came from the assembled 2026 release package, not an earlier export or working copy.
Next, compare the package metadata with the accessibility information required for the publication. Required access information must be present and must accurately describe the edition being released. A missing, incomplete, placeholder, or misleading value fails the metadata gate. Correct the package, regenerate the final EPUB if necessary, and inspect the metadata again after rebuilding. The purpose is not merely to insert fields, but to ensure that discovery systems and readers receive complete information about the publication’s accessibility.
For the manual gates, test the final file from the beginning to the end. At the keyboard gate, reach every interactive element without a pointer, operate it with the expected keys, and confirm that focus remains visible and follows a usable sequence. At the navigation and semantics gate, verify heading order, reading order, landmarks, links, and controls. At the screen-reader and alternatives gate, confirm that controls are identified and operable, and that images, graphics, and other non-text content have appropriate text alternatives. A failure in heading order, reading order, landmarks, links, controls, or text alternatives is a blocking defect.
Do not release the EPUB while any blocking defect remains unresolved. If every automated check passes but a required manual check fails, treat the EPUB as blocked and correct it rather than issuing a warning or relying on a score. Whenever a correction changes the package, repeat EPUBCheck, inspect the affected metadata, and rerun every manual check that the change could affect. Release only when all five gates pass on the same final file; otherwise, correct the file or ship a more accessible alternative.
What to do next
| Step | Action | Why it matters |
|---|---|---|
| 1 | Run the release EPUB through EPUBCheck and resolve every reported error before proceeding. | EPUBCheck success is a required condition for release. |
| 2 | Review the EPUB package metadata and complete all required accessibility metadata fields. | Assistive technologies need complete metadata to identify the publication’s accessible features, modes, and limitations. |
| 3 | Test the entire EPUB using only keyboard navigation, including focus movement, activation, and access to all interactive content. | Every control and navigation feature must be operable without a pointing device. |
| 4 | Inspect the EPUB’s navigation, document structure, headings, lists, tables, links, images, and reading order. | Correct semantics and navigation must convey the publication’s structure without ambiguity or broken reading sequences. |
| 5 | Test the EPUB with supported screen readers and verify labels, roles, states, alternatives, and navigation cues. | Manual screen-reader checks can expose problems that machine validation cannot detect. |
| 6 | Approve release only when EPUBCheck passes, accessibility metadata is complete, and no blocking defects remain from the mandatory manual checks; otherwise, correct the EPUB or ship a more accessible alternative. | This is the definitive release gate for the EPUB. |
Frequently Asked Questions
What must be validated before an EPUB 3.3 release?
The final packaged EPUB file must pass EPUBCheck 5.x.
Which accessibility metadata must the EPUB include?
The EPUB must include complete accessibility metadata.
How many unresolved blocking defects may remain after accessibility checks?
Zero unresolved blocking defects may remain.
Which manual checks are required in addition to machine validation?
Keyboard, navigation, semantics, and screen-reader checks are required.
What should happen if a mandatory accessibility check fails?
The file must be corrected or a more accessible alternative must be shipped.
How should EPUBCheck warnings be handled?
Every warning must be explicitly reviewed and recorded as accepted, corrected, or escalated for investigation.
Quick answers
| What must happen before releasing a 2026 EPUB? | The final packaged EPUB file must pass EPUBCheck. |
| What accessibility metadata must the EPUB include? | It must include complete accessibility metadata. |
| Which defects may remain after accessibility checks? | Zero unresolved blocking defects may remain after keyboard, navigation, semantics, and screen-reader checks. |
| What should be done when a mandatory accessibility check fails? | Correct the file or ship a more accessible alternative. |
| Which EPUB artifact should be validated with EPUBCheck 5.x? | Validate the final packaged EPUB file intended for release, not an earlier export or an unassembled working copy. |
Also worth reading: Step-by-Step Guide Converting Word Documents to EPUB Format in 2024: Step-by-Step Guide Converting Word Documents · Pandoc Lua Filters: Why EPUB Conversion Time Isn't What It Seems: Pandoc Lua Filters: Why EPUB · 1,290-Word GOST Beat Card: 14-Hour Beats vs 47-Hour EPUB Repairs: 1,290-Word GOST Beat Card: 14-Hour