EPUB Accessibility 1.2 Explainer: What It Means for Readers

The EPUB Accessibility 1.2 Explainer draft runs to several thousand words. The word "reader" appears in the title of the standard it explains. The word "conformance" appears throughout the document. That gap — between the technical machinery of conformance and the human act of reading — is exactly what this explainer is meant to close.

On July 30, 2026, the Publishing Maintenance Working Group (opens in new window) published the first draft of the EPUB Accessibility 1.2 Explainer (opens in new window), a companion document designed to help publishers, developers, and evaluators understand and apply the conformance requirements of EPUB Accessibility 1.2 to reflowable EPUB publications. This is a Group Note — not a normative standard — but its practical significance for disabled readers is substantial.

What the Explainer Actually Does

EPUB Accessibility 1.2 itself builds on WCAG 2 success criteria (opens in new window) and extends them specifically to the ebook context. Reflowable EPUB — the format where text adapts to screen size and user settings — is the dominant format for trade books, educational texts, and library ebooks. It's also the format most likely to be broken for screen reader users, people with low vision, and readers with cognitive disabilities when publishers don't understand what accessibility conformance actually requires.

The Explainer's purpose is translation. Technical conformance requirements, written for specification authors, don't always communicate clearly to the production editors, ebook conversion vendors, and accessibility coordinators who are actually responsible for making books accessible. A Group Note that bridges that gap has real value — if it reaches the people who need it.

For the compliance officer or accessibility coordinator working in educational publishing, the Explainer represents a practical audit framework. It maps what EPUB Accessibility 1.2 requires against what reflowable publications actually need to do. That's the kind of operational clarity that multi-standard compliance environments routinely fail to provide.

The Reflowable EPUB Reader's Reality

Consider what a screen reader user encounters with a non-conformant ebook. Navigation landmarks missing. Reading order scrambled when content is converted from print PDF. Math rendered as images with no alt text. Tables that collapse into unstructured text strings. Footnotes that interrupt the reading flow without return links. These aren't edge cases — they're documented patterns across commercial ebook catalogs.

The Daisy Consortium (opens in new window), which has been central to accessible publishing standards for decades, has consistently documented that the majority of commercially available ebooks fail basic accessibility requirements. Students with print disabilities — a population that includes people with dyslexia, low vision, and physical disabilities affecting page-turning — depend on ebook accessibility not as a convenience but as their primary means of reading.

For a screen reader user encountering a non-conformant reflowable EPUB, the experience isn't just inconvenient. It can mean being unable to complete coursework, access a library book, or read a professional text that sighted colleagues take for granted. That's the civil rights dimension underneath the technical specification.

What Publishers and Developers Need to Understand Now

The Explainer is a draft — public comment is part of the Working Group process, and this is the moment for disability advocacy organizations, assistive technology developers, and disabled readers themselves to engage. The W3C's public comment process (opens in new window) is the mechanism for community input to shape how these requirements are interpreted.

For publishers currently working toward EPUB Accessibility 1.2 conformance, the Explainer draft signals what evaluators will be looking for. The conformance requirements it explains aren't new — they're the existing standard — but the Explainer clarifies how to evaluate them. That distinction matters operationally.

| EPUB Accessibility 1.2 Requirement | WCAG Foundation | Practical Evaluation Focus | Common Failure Pattern | |---|---|---|---| | Reading order | WCAG 1.3.2 Meaningful Sequence | Logical content flow in spine and within documents | PDF-to-EPUB conversion scrambling order | | Images of text | WCAG 1.4.5 Images of Text | Alt text on all meaningful images | Math, charts, decorative vs. informative not distinguished | | Navigation | WCAG 2.4.1 Bypass Blocks | Landmarks, TOC, page list | Missing NCX/nav document structure | | Language declaration | WCAG 3.1.1 Language of Page | xml:lang on root element | Absent or incorrect language attributes | | Metadata discovery | EPUB Accessibility 1.2 §4 | Accessibility metadata in OPF | Missing schema:accessibilityFeature declarations |

This table reflects requirements documented in EPUB Accessibility 1.2 (opens in new window) and the underlying WCAG 2 specification (opens in new window). The Explainer's role is to clarify how these map to actual publication evaluation.

The Metadata Problem Nobody Talks About

One dimension of EPUB Accessibility 1.2 that the Explainer addresses — and that deserves more attention — is accessibility metadata. Publishers are required to declare what accessibility features their ebooks contain, and what hazards they may present. This metadata is what allows library systems, bookstores, and reading apps to surface accessibility information to readers before they purchase or borrow a book.

When that metadata is absent or inaccurate, a blind reader can't know whether a book will work with their screen reader before they download it. A reader with photosensitive epilepsy can't know whether a book contains flashing content. The metadata requirement isn't bureaucratic overhead — it's the mechanism that gives disabled readers the same ability to make informed choices that sighted readers take for granted.

This connects directly to what our research on standards fragmentation documents: when organizations treat accessibility metadata as a compliance checkbox rather than a reader-facing tool, the technical requirement is met while the human need goes unserved.

What the Southeast ADA Center's Framework Tells Us

The Southeast ADA Center (opens in new window) has long emphasized that community input must precede technical solutions. Applied to publishing accessibility, that principle means the people who evaluate whether the EPUB Accessibility 1.2 Explainer actually works are disabled readers — not just accessibility auditors running automated checks.

Automated testing tools can verify the presence of xml:lang attributes and check that images have alt text strings. They cannot tell you whether those alt text strings are meaningful, whether the reading order makes sense, or whether the navigation structure reflects how a screen reader user actually moves through a book. Research on the limits of automated testing puts the detection ceiling for automated tools at 37% of actual accessibility barriers. For ebooks, where the barriers are often structural and semantic rather than purely technical, that ceiling may be lower.

The Explainer draft is an opportunity. Publishers who engage with it seriously — who test their conformance evaluation processes against real assistive technology users, not just automated validators — will produce ebooks that actually work. Publishers who treat it as a checklist will produce ebooks that pass evaluation and still fail readers.

Immediate Steps for Publishing Accessibility Professionals

The draft is available now. The Working Group is in a comment period. Here's what matters in the next 30-60 days:

• Read the draft against your current production workflow. Where does your process produce the failure patterns documented in the table above?
• Test with real assistive technology — NVDA, JAWS, VoiceOver, and TalkBack — not just automated validators like Ace by DAISY
• Engage with the comment process through the W3C's public participation channels (opens in new window) if you have documented evidence of how specific requirements play out in production
• Connect with disability-led organizations — the Daisy Consortium, Bookshare, and library accessibility programs have documented what actually fails for their users
• Audit your accessibility metadata — not for presence, but for accuracy. Does your declared accessibilityFeature metadata reflect what's actually in the file?

The EPUB Accessibility 1.2 Explainer is a technical document. But the question it exists to answer is fundamentally human: can a disabled reader actually use this book? That's the question every publisher, developer, and evaluator should be asking — before the Explainer tells them how to document the answer.