WCAG EPUB compliance means applying the WCAG principles inside a packaged ebook and meeting the EPUB Accessibility requirements on top of them. Start with a semantic source file, add the required accessibility metadata (conformsTo, accessibilityFeature and xml:lang), then validate with EPUBCheck, run an accessibility checker and finish with manual tests in a real reading system.
Key Takeaways
Meeting WCAG standards within EPUB involves proper packaging, metadata, and manual testing to ensure accessibility features are correctly implemented and verified.
| Point | Details |
|---|---|
| Metadata accuracy | Include exact conformTo values, truthful accessibility features, and correct language tags on all content. |
| Content structure | Use semantic headings, lists, alt text, and meaningful titles to improve accessibility for all readers. |
| Preflight checks | Validate EPUB with EPUBCheck and ACE before distribution to catch structural errors early. |
| Manual testing importance | Test with keyboard navigation and screen reader in typical reading systems to verify real-world accessibility. |
| Alhora's solution | Alhora offers an accessible EPUB export tool that integrates validation during formatting, reducing last-minute fixes. |
Table of Contents
- How WCAG maps to EPUB: shared foundations and EPUB-specific additions
- Which EPUB elements and metadata affect WCAG conformance?
- How do you build accessibility in from the start?
- What testing sequence catches the most problems?
- How do you report results and claim conformance correctly?
- The case for treating compliance as part of the craft
- Can Alhora give you a validated accessible EPUB without the last-minute scramble?
- FAQ
- Sources
How WCAG maps to EPUB: shared foundations and EPUB-specific additions
WCAG rests on four principles: content must be perceivable, operable, understandable and robust. The W3C's EPUB Accessibility 1.2 specification builds directly on those principles. An EPUB is a zipped bundle of HTML, CSS and sometimes ARIA, so most WCAG techniques you already know for web pages apply to your chapters without translation. A heading hierarchy that helps a screen reader user on a website helps the same person in your novel.
What the web does not have is a package. An EPUB carries a manifest, a spine, a navigation document and a block of metadata that describes the whole publication. That package layer is why the EPUB specification adds rules WCAG alone never mentions: discoverability metadata that tells a store or library what accessibility features the book contains, and package-level conformance claims that tell a reader how far the publication goes.
Several differences trip up authors most often.
Package metadata versus page metadata. On a website, each page declares its own title and language in its own head. In an EPUB, the package document holds the publication-wide title and language, while every content document still needs its own. Both layers matter, and one does not cover the other. The Accessible Publishing Knowledge Base from DAISY flags this as a common reason attempted compliance fails.
ARIA role versus epub:type. EPUB inherited a semantic vocabulary, epub:type, from its early days. It still has uses, but assistive technology understands ARIA roles far more reliably. Where a matching role exists (a doc-chapter, a doc-footnote, a navigation landmark), add the role attribute as well. That keeps the structure readable for the tools your audience actually uses.
Multiple renditions. An EPUB can package more than one rendition of the same book, for example a reflowable text version and a fixed-layout version. Each rendition is its own reading experience, so an accessibility claim has to say which rendition it covers. A claim that quietly describes only the best-behaved rendition overstates what readers get.
Not every WCAG success criterion fits a book. Some criteria assume search boxes, multiple ways to reach a page or time-limited sessions. The EPUB Accessibility 1.2 Explainer walks through which criteria apply to EPUBs and how to record those that do not, which we cover in the testing and reporting sections below.
The practical takeaway: do not treat WCAG and the EPUB specification as competing checklists. WCAG tells you what accessible content looks like. The EPUB specification tells you how to package it, describe it and prove it. You need both, and the next section covers the concrete fields that connect them.
Which EPUB elements and metadata affect WCAG conformance?
Several areas of an EPUB decide whether a conformance claim holds up. Work through them in the package document first, then in the content files.
The conformsTo declaration
To claim conformance with the EPUB Accessibility specification, the package metadata must include a conformsTo property. The specification requires the value to match the pattern for the version you claim exactly, so a claim to version 1.2 uses the string defined for that version, not a paraphrase. A near miss is not a weaker claim. It is an invalid one, and validators and distributors may ignore it.
The conformsTo value also carries a WCAG level in the published pattern, so decide which level you have actually tested before you write it. Do not copy the value from a template without checking it against what you verified.
accessibilityFeature values
Discoverability metadata tells stores and libraries what a reader can expect. The Explainer lists values such as pageBreakMarkers, pageNavigation and textual features, and ties them to what the book really contains. Declare only what is true:
- If you mark print page breaks in the text, say so with the page break markers value, and provide a page list in the navigation document.
- If readers can jump to print page numbers, declare the page navigation feature.
- If the content is real text throughout, with no flattened images of words, the textual feature is accurate.
Metadata that promises more than the book delivers is worse than no metadata. It misleads the people most reliant on it.
Language, at both levels
Set xml:lang on the package and on each content document. That satisfies the WCAG requirement that the language of a page can be determined, and it lets a screen reader pick the right pronunciation engine. When a passage switches language, say a French epigraph in an English memoir, wrap it in an element with its own lang attribute. Without that, speech software reads French with English rules, and the result is unintelligible.
Images, alt text and extended descriptions
WCAG 1.1.1 asks for text alternatives for non-text content. Every meaningful image needs alt text that conveys its purpose, and purely decorative images need empty alt text so assistive technology skips them. Short alt text works for a headshot or a simple icon. A chart, map or diagram needs more: put a concise alt value on the image and an extended description in the text or in a linked, structured block, so a non-visual reader gets the full information.
WCAG 1.4.5, images of text, matters because of how ebooks get made. A decorative chapter title baked into a PNG, or a scanned page, fails readers who rely on text-to-speech or who enlarge and restyle text. Keep real text as text and use CSS for the styling. Where an image of text is unavoidable, such as a logo, the text alternative must carry the same words.
Titles
WCAG 2.4.2 expects each page to have a descriptive title. The EPUB package title does not satisfy that for your individual content documents. Give every XHTML file a meaningful title element, ideally one that names the chapter or section, and keep the package title for the publication as a whole. This is the DAISY knowledge base's headline example of a domain-specific pitfall, and it is an easy one to fix in bulk if your export tool lets you set titles per file.
Scripting, media overlays and renditions
Some features change which criteria apply and what you must flag.
Scripting. If your EPUB includes JavaScript, for an interactive quiz or a dynamic element, keyboard operability, focus management and status messages all come into play. If it has no scripting, those criteria can often be recorded as not applicable, with the reason stated. Reading systems also vary in how much scripting they allow, so never make essential content depend on a script.
Media overlays. Synchronized narration, where highlighted text follows audio, is valuable for many readers, but it has to stay in step with the text. If you include it, declare it in the metadata and test the synchronization in an actual reading system.
Multiple renditions. Each rendition needs its own accessibility treatment, and your metadata and any report must say which rendition they describe.
The pattern across these areas is the same: be specific, be accurate and put the right information at the right level, package or content, so that both machines and people can rely on it.
How do you build accessibility in from the start?
Experts at the University of Michigan recommend a "born accessible" workflow: use authoring tools that create semantic structure natively, because retrofitting accessibility at the end is frequently more costly and time-consuming. We agree, and it matches what we see when authors bring finished files to us late in the process. A book written with real headings and lists needs a short check. A book built from manual formatting needs a rebuild.
The upstream habits that matter most are small and repeatable:
- Use true heading styles in a logical order, never bold text standing in for a heading.
- Use real lists, not typed dashes or numbers.
- Keep text as text. Avoid images of text, including decorative chapter titles.
- Add alt text to every meaningful image and mark decorative ones as such.
- Give data tables proper header cells so a screen reader can announce row and column context.
- Mark every language change, including short foreign phrases.
- Write link text that makes sense out of context, so "read the chapter notes" beats "click here."
Export and packaging checks
Many accessibility failures come from the package, not the prose. At export, verify the manifest lists every file the book uses and the spine puts content in reading order. Confirm xml:lang is present on the package and every content document. Make sure the accessibility metadata is filled in and truthful, and that role attributes appear where your structure calls for them, such as on landmarks and notes.
Reading order deserves its own look. A book whose spine lists the copyright page after the last chapter may technically validate and still confuse a listener who navigates linearly. Read the spine as a screen reader user would encounter it.
Fonts, color and layout
Reflowable text is the default for good reason: readers resize, change fonts and switch to high-contrast themes. Do not lock font sizes in absolute units, and do not use color as the only way to convey meaning, such as marking a correction in red with no other cue. Decorative elements like drop caps are a frequent culprit, since a careless implementation can split a word so a screen reader announces a stray letter. Our guide to making drop caps work in EPUB shows how to keep the effect and the semantics. Books with equations need the same care, and our overview of MathML in EPUB explains how to keep formulas readable to assistive technology.
When to bring in a validation-enabled formatter
Clean semantic source files are the best starting point. Word processors with real styles and structured HTML both work. If your manuscript was built with manual spacing, pasted images of text or inconsistent styles, a formatter that validates as it exports will save more time than a hand-edit of the finished EPUB. We built our formatting studio around that idea, so structural problems surface during export, not after a store rejects the file.
Quick-reference authoring checklist
- Semantic headings and lists throughout
- No images of text
- Alt text on meaningful images, empty alt on decorative ones
- Table header cells in place
- xml:lang on the package and every content document
- Unique, descriptive title on every content document
- Truthful accessibility metadata in the package
- Role attributes on landmarks and notes
- Spine order matches intended reading order
For a longer version you can keep beside you while you work, see our EPUB accessibility checklist built on WCAG and EPUB 1.2. If InDesign is part of your pipeline, our guide to exporting accessible EPUBs from InDesign covers the settings that matter.
The same discipline holds outside trade publishing. Institutional publishers producing digital editions, such as the school yearbook teams described in this digital yearbook workflow guide, face the same choice: build structure in at the start, or pay to add it at the end.
What testing sequence catches the most problems?
Run testing in a fixed order: structural validation, automated accessibility checks, then manual functional testing. Each layer catches problems the others miss, and skipping one leaves a gap.
Layer one: EPUBCheck. EPUBCheck validates the package against the EPUB specification. If the manifest is wrong or a file is malformed, reading systems may interpret the book unpredictably, and accessibility checkers may not run cleanly. The University of Michigan's Test EPUB Files how-to lists running EPUBCheck and ACE as the primary steps. If EPUBCheck reports errors, fix those first. Our guide to fixing EPUBCheck errors and passing store validation covers the usual offenders.
Layer two: automated accessibility checks. ACE by DAISY is built for EPUB and reports structure, metadata and content issues mapped to WCAG. The university's accessibility testing tools page also references web tooling such as axe and Accessibility Insights for Web. Use them, but know their scope. Automated checks can flag a missing alt attribute. They cannot tell whether the alt text you wrote is meaningful.
Automated tools help but have limited scope and should be combined with manual testing, according to the University of Michigan's testing tools guidance. A clean automated report is a starting point, not a verdict.
Layer three: manual functional testing. This is where you confirm real people can read the book. Open it in the reading systems your audience uses and work through it with the tools they use.
- Run EPUBCheck and resolve every error before moving on.
- Run ACE and review every flagged item, noting which are real problems and which need judgment.
- Navigate the whole book by keyboard alone, confirming every link, control and note is reachable and has a visible focus indicator.
- Read through a section with a screen reader, listening for heading structure, list announcements, table headers and landmark navigation.
- Check language announcements, especially on passages in a second language.
- Verify every meaningful image has useful alt text and every complex image has an extended description.
- If the book has page markers, confirm the page list works and matches the print edition.
- If there is audio, video or media overlay, play it, check captions and transcripts, and confirm text and audio stay synchronized.
- Resize text, change fonts and switch to a high-contrast theme to confirm the layout holds.
- Repeat the key checks on a second reading system, because behavior differs between them.
Recording results honestly
When you test, record the outcome for each success criterion: pass, fail or not applicable. The Explainer clarifies how EPUBs record criteria that do not apply. A book with no scripting can note that script-dependent criteria are not applicable. A book with no video can say the same for caption criteria. What you must not do is mark a criterion not applicable because it is inconvenient. Every not-applicable entry needs a reason a reviewer would accept, such as "this publication contains no audio or video content."
Accurate reporting prevents false passes. A false pass costs you when a distributor, library or reader finds the gap, and it costs readers who bought on the strength of your claim.
Multimedia
If your book includes audio or video, the testing load grows. Captions are needed for synchronized media with speech, transcripts help for audio-only content and controls must work from the keyboard. Where you embed media in a reflowable EPUB, remember that reading system support varies, so provide a fallback and never lock essential information behind playback. Keep a log of what you tested and in which reading system, since that log becomes the backbone of your accessibility report.
How do you report results and claim conformance correctly?
The conformsTo property is your formal claim. As the EPUB Accessibility 1.2 specification states, the value must match the pattern for the version you claim exactly. Treat it as a statement you have earned through testing, not a default to paste in.
Alongside the formal claim, write an accessibility summary in plain language that readers, librarians and distributors can use. A good one covers:
- Scope. Which rendition and which parts of the book the claim covers.
- Reading system requirements. Any dependency, such as a feature that needs a particular reading system or assistive technology.
- Testing date and method. When you tested, and with which tools and reading systems.
- Criteria and results. What you checked and what you found, including known issues.
- Not-applicable notes. Which criteria you excluded and why.
- Evaluation report link. Where a reader can find the full detail.
Distribution matters as much as the file. The Explainer notes that package metadata such as accessibilityFeature values and page lists supports discoverability. Stores and libraries use the same information to help readers find books they can use, so make sure the metadata in your distribution records matches the metadata in the file. A mismatch between the two erodes trust quickly.
Be transparent about limits. If a rendition behaves differently, or a feature depends on the reading system, say so. A claim that names its edges earns more trust than one that sounds flawless, and it protects you if someone tests a case you did not.
Accessibility also does not end at publication. When you update the book, re-run the three layers of testing, because a late edit can quietly remove an alt attribute or break a heading level. Refresh the summary and the conformsTo claim to match the revised file, and republish the updated metadata to your distributors.
The case for treating compliance as part of the craft
My view, after watching formatters and publishers wrestle with this: the checklist is the easy part. The hard part is believing accessibility belongs to production, not to a final audit. The titles I see struggle are rarely the ones with exotic problems. They are ones where nobody owned structure until the last week, so a missing language tag and a flattened chapter heading surfaced at the worst possible moment.
The born-accessible workflow fixes that by making structure a daily habit. When headings are real from the first draft, and metadata is filled in as you go, the final audit confirms work already done instead of discovering work undone.
Here is the short preflight I would run before any export:
- Do headings run in logical order, with no skipped levels?
- Does every content document have its own title and language?
- Does every meaningful image have alt text, and every complex one a description?
- Are the accessibility metadata values true to the book?
- Did EPUBCheck and ACE both run clean, or are the leftovers explained?
- Did a human test it with a keyboard and a screen reader?
The kind of tooling that helps most is whatever moves checks earlier. A formatting studio that validates during export saves the late scramble, which is where deadlines and quality usually collide. Do not skip the human pass, though. No tool can listen to your book the way a reader will.
— James
Can Alhora give you a validated accessible EPUB without the last-minute scramble?
Yes. We built Alhora so the checks you just read about happen while you format, not after a store rejects your file. Fixing structure at export is faster than reopening a finished book, and that is the time saving our authors notice most.
Here is how our features map to what accessible EPUB production needs:
- Audit-gated accessible EPUB export: the export runs an accessibility audit first, so problems surface before you distribute, not after.
- Preflight validation during export: structural checks run as part of the same step, which cuts the back-and-forth with store validators.
- A typesetting engine: format your book with Alhora’s typesetting tools.
- Metadata and ISBN management in one place: your publication details stay consistent from file to distribution record.
- Built for your platform: we run on Mac, Windows, Linux and ChromeOS, and each platform has its own page, such as our book formatting software for Mac.
Alhora is available as a one-off license at £99, listed on our site. To see how EPUB export works across stores, read about our ebook formatting software for every store, or start a free look around at Alhora and preview your manuscript.
FAQ
What does WCAG EPUB compliance actually require?
It requires applying WCAG principles inside the EPUB's content and meeting the EPUB Accessibility specification's package-level rules. In practice that means semantic structure, accessible images and language markup, plus accurate accessibility metadata. The EPUB Accessibility 1.2 specification defines the full set of requirements.
Which metadata is needed to claim EPUB accessibility conformance?
The package must include a conformsTo property whose value exactly matches the pattern for the version you claim, as the specification requires. You should also add accessibilityFeature values and set xml:lang on the package and every content document.
Does the EPUB package title satisfy WCAG page title requirements?
No. The package title names the whole publication, while WCAG expects each content document to have its own descriptive title. The DAISY knowledge base identifies this as a common cause of failed compliance attempts, so give every file a title.
Can automated tools alone prove an EPUB is accessible?
No. Tools such as EPUBCheck and ACE catch structural and many technical issues, but they cannot judge whether alt text is meaningful or whether the reading experience works. Combine them with keyboard and screen reader testing.
When can a WCAG criterion be marked not applicable for an EPUB?
When the publication genuinely lacks the content the criterion addresses, such as video or scripting. The Explainer describes how to record these results, and each one needs a stated reason.