The Accessibility Metadata Hidden Inside Every EPUB

Note: This is part of a series:

Part 1: Do Your Ebooks Fail Millions of Readers?
Part 2: Headings Give Screen Readers a Map of Your Book
Part 3: Images Without Descriptions Leave Some Readers in the Dark
Part 4: The Accessibility Metadata Hidden Inside Every EPUB

EPUB files contain metadata — structured information about the book that reading systems, libraries, and distribution platforms use to understand and present the title. Most publishers know the basics: title, author, ISBN, publication date, and language. These appear in the EPUB’s content.opf file and flow into store listings and library catalogs.

What most publishers don’t know is that the EPUB specification supports a much richer set of accessibility metadata, and that metadata is becoming a standard part of how accessible books are identified, cataloged, and sold.

This metadata doesn’t make a book accessible on its own. It describes what accessibility features the book already has, or doesn’t have. Think of it as a nutritional label for accessibility. Readers who depend on accessible books need to know before they purchase whether a book will work for them. Accessibility metadata is how they find out.

The EPUB specification supports the following fields. Most of them never appear in standard publishing workflows:

• schema:accessibilitySummary is a free-text field that provides a human-readable summary of the accessibility features and limitations of the book. This is written for readers, not machines. A well-written accessibility summary might read: “This book includes alt text for all images, a fully navigable heading structure, and has been tested with NVDA on Windows. Tables include header row markup. The cover image includes alt text. The book does not include audio descriptions for video content.” That summary tells a prospective reader whether the book will work for them before they purchase it. Very few publishers include this. Most readers who need it have learned not to expect it.
• schema:accessMode describes the sensory modes required to consume the content. Common values include textual (the book can be read as text), visual (the book contains content that requires sight to understand), and auditory (the book contains content that requires hearing). A novel with no images is textual. A photography book is both textual and visual. This field helps reading systems and libraries match books to readers.
• schema:accessModeSufficient takes this further by specifying which combinations of access modes are sufficient to consume all the content. If your non-fiction book contains charts, but those charts also have full text equivalents, then textual alone is sufficient — a reader who cannot perceive visual content still has access to all the information. If the charts don’t have text equivalents, then textual alone is not sufficient. This field is what makes that distinction explicit.
• schema:accessibilityFeature is a list of specific features present in the book. The vocabulary is standardized and includes values like alternativeText (alt text is present), structuralNavigation (the book has a proper heading structure), readingOrder (the logical reading order is defined), tableOfContents (a navigable TOC exists), MathML (mathematical notation is marked up in an accessible format), and largePrint, among others. Reading systems and accessibility-aware distributors use this list to filter and recommend books.
• schema:accessibilityHazard flags content that may be harmful for some readers. The most common value is noFlashingHazard, which confirms that the book does not contain content that could trigger seizures in people with photosensitive epilepsy. Other values include noSoundHazard and noMotionSimulationHazard. For most static ebooks, none of these hazards apply, and you can state that explicitly.
• schema:accessibilityAPI indicates compatibility with specific operating system accessibility APIs. For EPUB content, this is less commonly specified than the other fields, but it’s worth knowing it exists.
• schema:certifiedBy and schema:certifierCredential are fields that allow a publisher to declare who assessed the accessibility of the book and what credentials they hold. These fields support a growing ecosystem of third-party accessibility auditing. If a book has been reviewed by a certified accessibility professional, that can be stated here, giving readers additional confidence in the metadata.

These fields belong in the content.opf metadata section of your EPUB, formatted as <meta> elements using the schema.org vocabulary. Platforms like Bookshare, JSTOR, and an increasing number of library vendors are beginning to surface this metadata to end users. The more publishers include it, the more useful it becomes — both for readers trying to find books that work for them, and for publishers whose accessible books deserve to be recognized and found.

Accessibility in publishing isn’t a finishing step. It’s a production consideration, which means it needs to be built into workflows from the beginning rather than applied at the end. Most of what’s described here — proper heading structure, thoughtful alt text, and complete metadata — doesn’t require expensive tools or extensive technical knowledge. It requires attention and intention.

The readers who need these features have been waiting a long time. Many of them have built workarounds into their daily lives because the publishing industry didn’t bother to build the books correctly. They’ve learned which authors and publishers to trust. Becoming one of those publishers is a choice, and it’s one that the tools, the standards, and the moment we’re in make easier than it has ever been.

Start with headings. Check your alt text survives your export. Fill in your accessibility metadata. Then test the file with an accessibility checker, and if you have access to a screen reader, test it with that too.

Originally published at https://wickedlanternstudio.com/accessible-ebooks-publishing-guide/ in February 2026.