Use EpubBit
Professional EPUB tools for indie authors worldwide.
EpubBit guides/Accessibility
Accessibility

Accessibility Foundations for Indie Authors: Headings, Reading Order, Language, and Contrast

Make your EPUB accessible with proper headings, logical reading order, correct language tags, and sufficient contrast. Step-by-step checks for indie authors.

12 min read · EpubBit Editorial Team

Accessibility is not a niche concern. It is a core quality attribute of any ebook. When you get accessibility right, you improve the reading experience for everyone: screen reader users, people with low vision, readers with cognitive differences, and anyone reading on a small phone in bright sunlight. For indie authors, accessibility is also increasingly a practical requirement: retailers and libraries may flag or reject ebooks that fail basic checks, and institutional buyers often require accessibility metadata. This guide covers four foundational areas you can control directly in your manuscript and EPUB: headings, reading order, language, and contrast. These are not abstract ideals; they are concrete, testable properties. We will walk through what each one means, why it matters, and how to verify and fix it in your own files.

Why these four basics matter more than advanced tricks

Accessibility guidelines for ebooks, such as the W3C's EPUB Accessibility specification and WCAG (Web Content Accessibility Guidelines), cover many topics: alt text, table markup, media overlays, and more. But in practice, the majority of real-world accessibility failures in indie ebooks come from a small set of structural issues. Headings that are fake (bold paragraphs instead of real heading tags) break navigation. A reading order that jumps around the page confuses screen readers. Missing or incorrect language tags cause pronunciation errors. Low contrast makes text unreadable for people with low vision. Fixing these four areas will resolve most of the problems that automated checkers and human reviewers find. They are also the areas where authors have the most direct control, because they originate in the manuscript structure, not in the conversion tool.

Headings: use real heading levels, not styled paragraphs

Headings serve two purposes: visual hierarchy and structural navigation. Screen readers and other assistive technologies rely on heading tags (h1, h2, h3, etc.) to build an outline of the document. If you create a heading by making a paragraph bold and large, it looks like a heading but is invisible to assistive technology. The same problem occurs if you use a heading style in Word but the style is not mapped to a proper HTML heading during conversion.

What to check

  • Every chapter title should be an h1 or h2, depending on your book's structure. Most ebooks use h1 for chapter titles and h2 for subsections.
  • Do not skip heading levels. If you have an h1, the next level down should be h2, not h3. Skipping levels makes the outline confusing.
  • Do not use headings for visual effect. If you want large bold text that is not a section title, use a paragraph with a custom class, not a heading tag.
  • Keep heading text concise. Long headings are harder to navigate in a list.

How to verify in EPUB

Unzip your EPUB (or open it in an EPUB editor) and inspect the XHTML content files. Search for <h1, <h2, etc. Confirm that each chapter starts with a heading and that the sequence is logical. You can also use an accessibility checker such as Ace by DAISY, which reports heading structure issues. If you use EpubBit, its validation and inspection tools can surface heading-level warnings before you publish; treat those warnings as a prompt to review the source manuscript.

Fixing headings at the source

The most reliable fix is to apply proper heading styles in your word processor before conversion. In Microsoft Word, use the built-in Heading 1, Heading 2, etc. styles. In Google Docs, use the heading styles from the format menu. Then, when you convert to EPUB, ensure your conversion tool maps those styles to HTML headings. If you are exporting to EPUB via a tool like EpubBit, check the conversion settings for style mapping. If you are hand-coding, use the correct tags directly.

Reading order: make the logical flow match the visual flow

Reading order is the sequence in which assistive technology reads the content. In a well-structured EPUB, the reading order should match the visual order: title page, copyright, dedication, table of contents, chapters in sequence, back matter. Problems arise when content is placed in text boxes, sidebars, or floating elements that are visually positioned in one place but appear elsewhere in the underlying markup. Screen reader users then hear content out of context.

Common reading-order pitfalls

  • Text boxes and sidebars that are anchored to a page but not in the main flow. In reflowable EPUB, these often end up at the end of the chapter or in an unexpected position.
  • Multi-column layouts that are converted to a single column but with content interleaved incorrectly.
  • Images with text that are placed before or after the related paragraph in the markup, so the reading order does not match the visual association.
  • Footnotes that are placed at the end of the document instead of near the reference, or that are not linked properly.

How to verify reading order

The simplest check is to open your EPUB in a reader that supports text-to-speech or a screen reader (such as NVDA or VoiceOver) and listen to the beginning of each chapter. Does the content make sense in the order it is read? Alternatively, inspect the XHTML source: the order of elements in the file is the reading order. For a quick structural check, use the EPUB's navigation document (nav.xhtml) and spine order in the OPF file to confirm that chapters are in the intended sequence. Tools like EpubBit can help you inspect the spine and navigation order, but the ultimate test is listening.

Fixing reading order

In your manuscript, avoid using text boxes for important content. If you must use them, ensure they are placed in the flow where they belong. During conversion, check that the tool preserves the order. For complex layouts, consider simplifying to a single-column flow. If you are hand-coding, place elements in the XHTML in the order you want them read.

Language: tag the document and any language changes

The language attribute tells assistive technology which language to use for pronunciation and braille translation. If the language is missing or wrong, a screen reader may pronounce words using the wrong phonetic rules, making the text unintelligible. For example, an English book read with a French synthesizer will be garbled. The primary language is declared in the OPF package document and can also be set on the root <html> element in each XHTML file.

What to check

  • The package document must have a dc:language element with a valid BCP 47 language tag, such as en for English, en-US for American English, fr for French.
  • Each XHTML content document should have a lang attribute on the <html> element, matching the primary language.
  • Any passage in a different language should have its own lang attribute on the containing element (e.g., a <span lang="fr"> for a French phrase).

How to verify

Open the OPF file (usually content.opf) and look for <dc:language>. Then open a few XHTML files and check the <html> tag for a lang attribute. You can also use an EPUB validation tool; EPUBCheck will report missing or invalid language tags. EpubBit's validation reports include language checks, which can save you from hunting through files manually.

Fixing language tags

In most word processors, you can set the document language in the document properties. When converting, ensure the tool carries that through. For multilingual passages, you may need to add the lang attribute manually in the XHTML after conversion, or use a conversion tool that supports language marking. If you are hand-coding, add the attributes directly.

Contrast: ensure text is readable against its background

Contrast is the difference in luminance between text and its background. Low contrast makes text hard to read for people with low vision, color blindness, or anyone reading in poor lighting. The Web Content Accessibility Guidelines (WCAG) define minimum contrast ratios: 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). These ratios are calculated using relative luminance, a formula that accounts for the way human eyes perceive brightness. You do not need to compute it by hand; many free contrast checkers exist online. But you do need to check every color combination in your book.

What to check

  • Body text against background: typically black on white, which has a contrast ratio of 21:1 and passes easily.
  • Headings and subheadings: if you use colored headings, check the contrast against the page background.
  • Links and emphasized text: colored links must meet the same ratios.
  • Text over images: if you place text over a background image, ensure sufficient contrast, or add a solid background behind the text.
  • Decorative elements: purely decorative text (like a faint watermark) may be exempt, but if it conveys meaning, it must meet contrast requirements.

How to calculate and verify

Use a contrast checker tool. Enter the foreground and background colors (hex codes). The tool will report the contrast ratio and whether it passes WCAG AA (4.5:1 for normal text) or AAA (7:1). For example, dark gray (#333333) on white (#FFFFFF) has a ratio of about 12.6:1, which passes AAA. Light gray (#CCCCCC) on white has a ratio of about 1.6:1, which fails. If you are designing a cover or interior with colored elements, test each combination.

Fixing contrast

Adjust the foreground or background color until the ratio meets the threshold. Darken the text or lighten the background (or vice versa). Avoid using color alone to convey meaning; pair it with text or symbols. In EPUB, you can set colors via CSS. Ensure your CSS does not override user preferences for high-contrast modes; use relative units and avoid fixed colors where possible, or provide a high-contrast alternative.

Step-by-step accessibility check for your EPUB

Follow these steps before publishing. You can do them in any order, but a logical sequence helps.

  1. Check headings in the source manuscript. Apply proper heading styles. Do not use bold paragraphs as headings.
  2. Convert to EPUB. Use a conversion tool that preserves heading structure. EpubBit's conversion pipeline maps heading styles to HTML headings; review the output.
  3. Validate the EPUB. Run EPUBCheck to catch structural errors, including missing language tags and heading issues. EpubBit's validation report includes accessibility-related warnings.
  4. Inspect the navigation document. Open the nav.xhtml (or toc.ncx for EPUB 2) and confirm the table of contents reflects your heading structure.
  5. Test reading order. Use a screen reader or text-to-speech to listen to the first few minutes of each chapter. Alternatively, inspect the XHTML source to confirm the order of elements.
  6. Verify language tags. Check the OPF for dc:language and each XHTML file for the lang attribute. Add lang attributes to foreign-language passages.
  7. Check contrast. List every text color and background color combination. Use a contrast checker to confirm ratios of at least 4.5:1 for normal text and 3:1 for large text.
  8. Run an accessibility checker. Tools like Ace by DAISY can scan your EPUB and report issues. Address any findings.

Going further: metadata and testing with real users

Once the four basics are in place, consider adding accessibility metadata to your EPUB. The EPUB Accessibility specification defines metadata properties such as schema:accessMode, schema:accessibilityFeature, and schema:accessibilitySummary. These help retailers and libraries understand the accessibility of your book. For example, you can declare that your book has structural navigation and alternative text. You can add this metadata in the OPF package document. EpubBit's metadata editor supports adding accessibility metadata fields, which can streamline the process.

Finally, test with real users if possible. Nothing beats feedback from a screen reader user. If you cannot do that, at least test with multiple reading systems (Apple Books, Google Play Books, Kindle Previewer, Thorium Reader) because accessibility support varies. Remember that retailer requirements change; always verify current official documentation for accessibility guidelines from each platform you publish to.

Conclusion

Accessibility is a craft skill, not a checkbox. By using real headings, preserving logical reading order, tagging language correctly, and ensuring sufficient contrast, you make your ebook usable by more people and more robust across reading systems. These four areas are within your control as an indie author, and they are the ones most likely to be flagged by automated checkers. Build them into your workflow from the start: apply heading styles in your manuscript, check language settings, test contrast in your CSS, and listen to your book with a screen reader. With practice, these checks become second nature, and your readers—all of them—will benefit.