EPUB Accessibility: Beyond Validation

Somewhere at Frankfurt this October, a production manager will hand over an EPUB with a validation report showing zero errors and call the job done. It's an understandable instinct. A clean report feels like proof. It has numbers, a pass/fail state, something concrete to point to when a buyer asks whether a file is accessible.

It's also not proof of much. A validation report tells you a file passed a specific, narrow set of automated checks. It says nothing about whether a person using a screen reader can actually make sense of the book.

Two tools, two different jobs

Start with what these tools actually do, because the confusion usually starts here. EPUBCheck validates structure. It confirms the file is a well-formed EPUB according to the specification: valid ZIP packaging, correct OPF metadata, no broken internal references. It has nothing to do with accessibility. A perfectly valid EPUB can be completely unusable for a screen reader, and EPUBCheck will still call it clean.

Ace by DAISY is the tool that actually targets accessibility. Built on the axe engine, it runs automated checks against WCAG success criteria and EPUB-specific accessibility rules: missing alt attributes, absent metadata, structural issues a machine can detect reliably. Ace's own documentation is blunt about its limits. It does not claim to be a yes/no validator. It will not issue a conformance score. It exists to flag what can be caught automatically and hand the rest to a human.

The DAISY Consortium built Ace and EPUBCheck, and gave both away free to the entire industry. That single decision did more to raise the baseline of EPUB accessibility than any commercial tool has managed. Ace is the closest thing publishing has to a trusted, shared standard for automated checking, and the honesty in its own documentation about what it can't catch is exactly why it deserves that trust. That's the part too many workflows skip.

The 30 percent problem

Accessibility experts who work on EPUB testing daily put a number on this: automated checking covers roughly a third of what a full accessibility evaluation actually requires. The remaining two-thirds needs a person looking at the file with real judgment, not a script scanning for the presence of an attribute.

Here's what that missing two-thirds looks like in practice. Ace can confirm an alt attribute exists on an image. It cannot tell you if the text inside that attribute means anything. "IMG_4471.jpg" and "Bar chart showing Q3 revenue rising 18 percent across three regions" both satisfy the same automated check. Only one of them helps a reader.

Ace can confirm a heading structure exists. It cannot confirm that structure reflects how the content is actually organized, or that a screen reader user moving through headings gets a coherent outline of the book rather than a technically valid but confusing jump between unrelated sections. Color contrast on plain text gets flagged reliably. Contrast inside a complex infographic, table, or fixed-layout spread often needs a human eye to judge correctly. Reading order can validate as technically present while still routing a reader through captions before body text or footnotes before the sentence that calls them.

None of this shows up in an automated report with zero errors. All of it shows up the moment a real reader opens the file.

What a validation report can't tell a buyer

This gap matters more at Frankfurt than it used to, because procurement teams have gotten more specific about what they ask for. A distributor asking "is this accessible" two years ago might have accepted a clean Ace report as the whole answer. Increasingly, they're asking what testing happened beyond the automated pass, because they've been burned by files that validated clean and still generated complaints from actual users.

A publisher who can only point to an automated report is one hard question away from an awkward silence. A publisher who can describe the full evaluation, automated checks plus manual review plus a documented conformance claim, walks into that conversation with an actual answer.

Consider two catalogues sitting side by side at a rights meeting. Both carry a validation report showing zero Ace errors. One has also been through manual reading-order testing and alt text review by someone who actually looked at the images. The other hasn't. Nothing in either report shows that difference. The buyer only finds out which one is which when a reader complains, or when their own compliance team runs a deeper check before signing. By then the gap has already cost the weaker file the deal, or worse, cost it after the deal closed.

What the full process actually looks like

The sequence that holds up starts with EPUBCheck for structural validity, moves to Ace for automated accessibility flags, and then adds manual verification against the parts no script can judge: alt text quality, reading order logic, navigation coherence, and genuine usability with assistive technology. DAISY's own Ace SMART framework exists specifically for this manual layer, because the organization that built the automated tool is the first to say the automated tool isn't sufficient on its own.

Skipping that manual layer doesn't just risk a bad reader experience. It risks a false conformance claim. EPUB Accessibility 1.1 metadata asks publishers to declare a WCAG conformance level. Declaring AA conformance based on an automated report alone, when a third of the requirements were never actually checked, is a claim that won't survive a real audit.

Why this is the right conversation for Frankfurt

Publishers walking the fair this year are past debating whether accessibility matters. The conversation has moved to how rigorously it's being verified, because that's what separates a file that merely passes a scan from one that actually works for the reader it's meant to serve.

That distinction is the foundation of how S4Carlisle handles every file. The NINJA AI Ecosystem runs the automated layer, structural validation, WCAG and EPUB-specific checks, flagging everything a script can catch. From there, trained accessibility reviewers take over for exactly the two-thirds automation can't touch: alt text that actually describes, reading order that actually makes sense, navigation that actually works with a screen reader in hand. Every file carries Benetech GCA certification behind it, which means the claim on the metadata matches what an auditor would find if they opened the file themselves.

A clean automated report is a good start. It was never meant to be the finish line.

S4Carlisle is Benetech GCA certified and combines automated detection with human accessibility review through the NINJA AI Ecosystem. Visit us at Frankfurt to see what full verification actually looks like.