Publishing has a problem that we don’t talk about much: accessible ebooks.

Millions of readers open an ebook and can’t read it. Not because the writing is bad or the subject is uninteresting, but because the file itself was built in a way that excludes them.

According to the World Health Organization, over 2.2 billion people worldwide live with some form of vision impairment. In the United States alone, roughly 7 million people have a visual disability significant enough to affect daily reading.

Add readers who rely on screen readers due to dyslexia, cognitive differences, or motor impairments that make physical page-turning difficult, and the number of people who need accessible books grows fast. These readers are not edge cases. They are your audience.

And publishing, largely, is failing them.

The industry’s track record is not good

The publishing world has operated on the assumption that accessibility is someone else’s problem. Large traditional publishers outsource EPUB conversion to vendors who use automated tools, check a few boxes, and ship files that technically open but function poorly for screen reader users. Indie authors and small publishers inherit those same broken workflows, often without knowing it.

According to the World Blind Union, fewer than 10% of all published materials can be read by people who are blind or have low vision — a figure the Accessible Books Consortium has cited as a core driver of its work. That statistic is more than a decade old, and while it’s improving, it’s doing so slowly — largely due to external pressure, including European Union legislation, legal complaints in the United States, and advocacy from organizations like Bookshare and the National Federation of the Blind.

The problem isn’t a lack of solutions. The tools to build accessible ebooks exist. The knowledge to use them exists. What has been missing is the expectation that publishers, at any scale, should use them — and that expectation is no longer optional. The European Accessibility Act, which came into force in June 2025, requires ebooks sold in EU member states to meet accessibility standards. In the U.S., the Americans with Disabilities Act has been applied to digital content in court cases going back years. If you publish and distribute ebooks, you are operating in a legal landscape that increasingly treats accessibility as an expectation — and in some markets, a requirement.

But compliance is the floor, not the ceiling.

Simply put: accessible books are better books — for everyone. They’re more discoverable, more broadly usable, and built with a structural integrity that benefits every reader, not only those using assistive technology. Build it well for one reader, and you’ve built it well for all of them.

Headings give screen readers a map of your book

Headings aren’t styling; they’re structure. When you mark a chapter title as Heading 1 in your word processor, you’re not just making it big and bold. You’re telling the file that this is a top-level landmark in the document hierarchy. Screen readers use that information to build a navigation map, allowing users to jump directly to any chapter, section, or subsection without scrolling through the entire book.

If your chapter titles are formatted as large, bold text rather than properly tagged headings, they may look identical on screen, but they function completely differently in an accessible reading environment. A screen reader encounters these non-heading “headings” as ordinary paragraphs. There’s no navigation. There’s no way to jump. There’s no map. The reader must start at the beginning and move through the file linearly, every time.

For a novel, this is frustrating. For a non-fiction book with twenty chapters and three appendices, it’s close to unusable.

The heading hierarchy matters too. Your chapter titles should be Heading 1. Sections within chapters should be Heading 2. Skipping levels — jumping from Heading 1 to Heading 3 because you like how Heading 3 looks — breaks the logical structure of the document. Screen readers and other assistive technologies interpret that as a structural error, which creates confusion about how the content is organized.

Heading levels also need to make semantic sense. Don’t use Heading 2 for a sidebar title if that sidebar isn’t a subsection of the preceding Heading 1 content. The heading hierarchy should reflect the structure of the ideas in the book, because that’s what assistive technology reads it as.

The table of contents a reading system presents to the user is built directly from your heading structure. Get the headings right, and the navigation is right. Get them wrong, and no amount of manual TOC editing will fully compensate.

The navigation document in an EPUB should include every heading level that appears in the book, not just chapters. A user who wants to jump to a specific subsection of chapter seven should be able to do that. Limiting the navigation to top-level chapters only is a common shortcut that makes the file significantly harder to use.

Images without descriptions leave some readers in the dark

Every image in your book contains information — or mood, or context — that a sighted reader absorbs at a glance. For a screen reader user, that same image is either announced as “image” with no further detail, or it’s skipped entirely. Either way, whatever it was communicating is gone.

Alt text — short for alternative text — is the fix. It’s a written description embedded in the image itself, which a screen reader reads aloud in place of the image. Without it, the reader gets nothing.

Writing good alt text is a skill worth developing. The general principle is to describe what the image communicates, not just what it contains.

For non-fiction books, alt text should prioritize the informational content of the image. “Diagram of the human nervous system” tells a screen reader user that an image exists. “Diagram showing the central and peripheral nervous system, with the brain and spinal cord highlighted as the central system and branching nerves extending to the limbs and organs as the peripheral system” tells them what it means. If a chart is complex enough that a meaningful description would run very long, the recommended approach is to provide a brief alt text description and then include a longer text description in the body of the book, near the image, or in an appendix. Some EPUB specifications support a separate longdesc attribute for this purpose, though reading system support is inconsistent; a nearby text block is more reliable.

Maps present a specific challenge. A map of Civil War troop movements contains spatial information that doesn’t translate easily into a linear text description. The goal is to convey the meaning and key details: what the map shows, what the significant patterns are, and what the reader should take away. You won’t replicate the full experience, but you can ensure the information isn’t simply absent.

For fiction books, alt text works differently, and this is where many authors get stuck. If your novel includes chapter header illustrations or atmospheric images, you’re not conveying data. You’re conveying mood, tone, or visual storytelling. The alt text should serve the same purpose.

Consider a gothic novel with a chapter header image depicting a crumbling stone archway covered in ivy, with a crow perched on top and storm clouds in the background. Describing it as “a stone archway with ivy and a crow” is technically accurate and mostly useless. Better alt text might be: “A weathered stone archway, half-collapsed, with ivy pulling at the mortar. A crow sits at the peak, and the sky behind it is heavy with approaching storm.” That description places the reader in the same emotional register that the image creates. It serves the story.

Character portraits, maps of fictional worlds, and illustrations that reveal plot-relevant details all need alt text that accounts for what a sighted reader would understand from seeing them. A map of a fantasy world labeled with kingdoms and trade routes needs those details in the alt text, because those names may appear in the text, and a reader who can’t parse the image is missing context they need.

When not to write alt text: decorative images deserve silence

Not every image needs alt text. Some images exist purely as decoration. A horizontal rule made from ornamental flourishes, a subtle texture behind a chapter title, a small graphical divider between scenes — these carry no information. They create a visual atmosphere, and that atmosphere doesn’t need a text equivalent.

For these images, the correct approach is to use an empty alt attribute: alt=””. This is not an accident or an omission. It’s an explicit instruction to assistive technology to skip the image entirely. Screen readers, upon encountering alt=””, move on without announcing anything. The image is treated as invisible, which is correct, because for the purposes of the content, it is.

Where this gets complicated is images that are decorative for some readers and meaningful for others. A stylized author signature used as a sign-off at the end of a foreword might seem decorative, but if the text doesn’t otherwise identify the author in that location, the signature is carrying information. In that case, alt text is appropriate.

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.

Building accessible ebooks: what comes next

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.