Kraetke, Martin. “E-Book Backlists in, Accessibility out? Migrating E-Book Back Catalogues with a Pragmatic
XProc-Based Approach.” Presented at Balisage: The Markup Conference 2026, Washington, DC, August 3 - 7, 2026. In Proceedings of Balisage: The Markup Conference 2026. Balisage Series on Markup Technologies, vol. 31 (2026). https://doi.org/10.4242/BalisageVol31.Kraetke01.
Balisage: The Markup Conference 2026 August 3 - 7, 2026
Balisage Paper: E-Book Backlists in, Accessibility out?
Migrating E-Book Back Catalogues with a Pragmatic XProc-Based Approach
Martin Kraetke
Lead Content Engineer
le-tex publishing services GmbH
Martin Kraetke is Lead Content Engineer at le-tex publishing services.
This work is published under the Creative Commons Attribution-NoDerivatives 4.0 License
(CC BY-ND 4.0).
Abstract
Since the ratification of the European Accessibility Act (EAA)[1] in several EU member states, including Germany, in 2024, many publishers have realized
they are sitting on a ticking time bomb: their e-book backlists.
Since the ratification of the European Accessibility Act (EAA)[2] in several EU member states, including Germany, in 2024, many publishers have realized
they are
sitting on a ticking time bomb: their e-book backlists. The core issue is the gap
between past production
standards and new legal requirements. For years, accessibility was treated as optional
or secondary, meaning that
a large portion of existing digital catalogs was never designed with inclusive reading
in mind.
Adding to the challenge is the sheer scale of publisher backlists. Large publishing
houses may have tens of thousands of titles, each requiring assessment and, potentially,
remediation. This creates significant operational and financial pressure, particularly
for smaller publishers with limited resources. At the same time, the EAA introduces
clear compliance deadlines and potential penalties, raising the stakes for inaction.
What once seemed like a manageable technical debt has evolved into a strategic and
legal risk. Publishers are
now forced to confront the reality that their historical content (once considered
a valuable asset) may instead
represent a substantial liability that could vanish from the market if not brought
up to modern accessibility
standards.
New Legal Requirements
The EAA fundamentally shifted accessibility from a best practice to a legal obligation.
Since June 28, 2025,
any e-book sold in the EU must be accessible to people with disabilities. This also
includes non-European
publishers that wish to sell their books within the EU. The EAA applies not only to
new titles, but also to
backlist titles that remain commercially available.
Crucially, the law does not define accessibility in abstract terms. It anchors compliance
in established technical standards. In practice, this means publishers must align
with specifications such as EPUB Accessibility 1.1 and WCAG 2.1 These frameworks translate
legal principles into concrete implementation requirements: content must be perceivable,
operable, understandable, and robust.
Technically, this results in a clear set of obligations: e-books must use structured,
semantic markup (e.g.,
proper headings and navigation), include alternative text for images, and support
flexible layouts. They must be
fully navigable via assistive technologies like screen readers and keyboards, and
include accessibility metadata
describing their features.
In short, the EAA turns accessibility into a measurable, testable property of digital
files. What was once a design consideration is now a compliance requirement, enforced
through specific file formats, coding practices, and metadata standards.
Production Standards in the Past
In the early days of e-book publishing, the common format was EPUB 2.0 which offers
very limited accessibility
support. Furthermore, many legacy e-books do not even meet these limited features,
lacking proper semantic
structuring, image descriptions, or a logical heading order. In many cases, files
were converted from print
layouts with minimal attention to digital usability, resulting in content that is
difficult or even impossible for
people with visual or cognitive impairments to access.
Source files were often PDFs or layout files created in software such as Adobe InDesign,
FrameMaker, QuarkXPress, or other DTP tools. PDFs are purely presentational, and even
the layout files required extensive preparation. These files typically came directly
from typesetters, whose focus was solely on print presentation. They rarely considered
creating a logical reading order or applying consistent paragraph styles. For example,
when a font lacked an accent; the typesetter would simply take the accent from another
font and place it manually above the letter.
These source files were then handed over to specialized companies that transform data,
documents, or media from one format to another, companies like mine. My colleagues
would first resolve many of the issues directly in the DTP software before exporting
the content to HTML. From there, they continued working in a text editor, which was
usually faster and more flexible thanks to macros and regex replace. Eventually, they
converted the data to EPUB.
Despite these workflows, the process remained highly manual. Preparing layout-intensive
books, such as textbooks or art books, was particularly challenging and costly. The
combination of complex layouts, inconsistent source files, and the need for meticulous
manual correction made early e-book production a labor-intensive endeavor.
Is XML the Answer?
High costs and manual work caused many publishers to rethink their typesetting workflows.
XML found its way into the typesetting, facilitated by new XML interfaces of DTP applications
and modern XML processing software. Either the entire typesetting started from an
XML source file (XML first) or the XML was created on the basis of clear layout conventions
and style catalogues afterwards (XML last). These XML workflows allowed to easily
change the configuration of the output format and reconvert the e-book whenever the
requirements changed.
However, the introduction of new XML workflows did not resolve the issue of outdated
e-book backlists. Titles produced prior to the XML era were rarely migrated, as doing
so typically required a complete re-typesetting process. Moreover, there was little
legal or commercial incentive to update these backlists to newer formats. If an older
e-book contained errors, they could simply be corrected in the existing file and redistributed.
Even when HTML files were available, converting them into XML was not straightforward.
HTML tended to prioritize presentation over semantic structure. Without CSS, an HTML
file often consisted largely of loosely consistent class names. For instance, it was
common practice to use paragraph elements styled to resemble lists, rather than employing
the appropriate semantic list elements provided by HTML.
Furthermore, e-book production was initially driven by layout requirements. Even though
the capabilities of e-book readers were limited, a common mantra among publishers
was, “it needs to look like the PDF.” As a result, the underlying code differed significantly
from one e-book to another, making any retrospective conversion to XML a time-consuming
and resource-intensive task. This challenge was further compounded by the fact that
XML schemas in the early 2010s were still relatively limited in functionality, lacking
support for many of the features and semantic structures that publishers would later
come to require. Consequently, updating legacy e-book to modern standards was both
technically complex and commercially unattractive.
repub: A pragmatic approach to EPUB migration
On my way back from the Declarative Amsterdam 2023[3] markup conference, I found myself reflecting on the problem and quickly realized
that transforming an EPUB 2.0 directly into EPUB 3.0 would be far easier than attempting
to use XML as transitional format. Still on the train, I began sketching out a plan
and experimenting with the first pipelines, which would later operate under the name
“repub”[4]. While I would later run into some limitations, XProc[5] and the XML framework transpect[6] initially struck me as the perfect tools to orchestrate the unpacking and repacking
of EPUBs, managing the mix of XML and binary files, file references, links, and all
the other components involved.
At the time, using LLMs or other machine learning models for this task wasn’t even
on the table. To be fair,
large language models (LLMs) were still relatively immature in 2023. But even with
today’s advances, LLMs are
inherently unable to guarantee fully reliable and predictable results. Their outputs
are probabilistic by nature,
meaning that the same input can produce different responses depending on context,
model state, or training
bias.
Several design constraints were clear from the outset:
The entire EPUB should be represented as a single XML document to facilitate transformations and queries.
Page breaks that occurred between individual HTML files should be preserved by inserting hidden
<div> containers with IDs.
The EPUB 3 navigation (the so-called toc nav) should be generated from the NCX, the EPUB 2.0 navigation that is XML-based and
was borrowed from Daisy’s Digital Talking Books[7] (DTB).
In addition to a fully automated conversion, a two-step process was required to allow
for manual interventions and corrections. The same applied to generating alternative text.
The conversion to EPUB 3 was to be handled by the transpect EPUB converter[8], which already included automatic transformations to improve accessibility.
The software should also be developed as a transpect module so it can be reused in other transpect projects.
Using the extensive archive from our EPUB production department also proved invaluable.
With the latest versions of the EPUB validation tool EPUBCheck[9] and the accessibility checker Ace[10], I discovered several EPUBs that contained issues which could not have been easily
resolved at the time of their original production:
EPUB 3 and its accessibility requirements are significantly stricter than those of
EPUB 2.0. For example, if the order of the navigation differs from the order of the
content, it is now considered an error.
Early versions of EPUBCheck contained bugs, and their validations did not cover the
full specification.
Standards such as HTML and CSS evolved over time, and some syntax elements were deprecated
in the process. Since EPUB 3 relies on the latest version of the HTML standard, this
“living standard” can outlive the EPUBs themselves.
These developments show that EPUB 3’s stricter standards and evolving validation tools
not only demand technical correctness but also emphasize accessibility as a key requirement.
The next challenge was to integrate accessibility into content that had originally
been created purely with design considerations in mind.
Garbage in, Accessibility out?
The digital accessibility of an e-book depends on several factors, which can be grouped
into the following areas:
Navigation: a list-based navigation is helping users of screenreaders to figure out
the structure of the
content. Older EPUBs sometimes contain HTML-based table of contents where the heading
level is just
perceivable by CSS formatting.
Semantic structure: The more semantic information is included, the better can a screenreader
convey this
information to the user. For example, if you tag the languages correctly, parts in
different languages are
read with the correct pronunciation.
Alternative descriptions: For a blind person, a digital image is a non-existing information.
In this
sense, for images, audio and video, you need to provide text-based alternatives such
as alternative texts and
subtitles. These are presented to the user instead of the original content.
Metadata: Visually impaired people rely on accurate information about an e-book's
accessibility. This
includes information about navigation, textual alternatives, or potential hazards
such as videos with
flickering lights.
Readability: Assistive features such as high-contrast modes, adjust font-size and
display scaling depend
on proper formatting. Binding colors, font sizes and other layout components to fixed
values could render
assistive features useless.
Navigation
As mentioned earlier, the HTML-based EPUB 3 navigation is transformed from the NCX:
Some older EPUBs already included HTML-based navigation, but this was primarily for
aesthetic purposes. EPUB 2 readers relied exclusively on the NCX for digital navigation.
The bright side: The NCX defines the book’s table of contents as a nested set of <navPoint> elements, which are inherently hierarchical and ordered. This enforces a list-based
navigation structure which could easily be converted to a EPUB 3 navigation.
Semantic Structure
Unfortunately, the HTML headings were often not in hierarchical order; for example,
a level 1 heading could be immediately followed by a level 3 heading. To address this
issue, I represented the heading levels as a sequence of integers and used a recursively
invoked XSLT function to correct the structural gaps in the hierarchy.
EPUB already offered a taxonomy via the so-called epub:type attributes to extend the limited HTML markup with book-specific semantic annotations.
The transpect EPUB converter makes use of this markup and automatically adds the appropriate
ARIA role for each epub:type attribute.
To resolve problems with outdated HTML, an XSLT was introduced to automatically transform
legacy elements and attributes into modern, standards-compliant markup. For example,
deprecated HTML such as <font size="12pt"> is converted into the corresponding CSS styling.
Alternative Descriptions
To allow the editing of alternative descriptions, I implemented a feature that my
colleague Maren Pufe originally developed for our transpect-based publishing process:
A DOCX file can be generated from the EPUB, featuring a table with a row for each
image and fields for a thumbnail, caption, and alternative text. I subsequently added
functionality to support AI-generated alternative texts. Finally, the alternative
texts from the DOCX can be incorporated back into the EPUB.
Figure 2
DOCX file with thumbnails and AI-generated alternative text proposals
Metadata
The metadata of an EPUB file is stored in the OPF document, an XML-based format that
contains title-specific information such as the book’s title, author, and publisher.
It also includes a manifest listing all files in the container, as well as the spine,
which defines the reading order of the content documents.
EPUB 3.3 offers the possibility of including more accessibility-specific metadata.
Fortunately, I was able to rely on existing features of the transpect EPUB converter,
which automatically generates metadata for accessibility modes (e.g., textual and
visual), accessibility warnings, and dedicated accessibility features.
Figure 3
<metadata>
<!-- (…) -->
<meta property="schema:accessibilitySummary">
This e-book has been optimized and reviewed for accessibility in
accordance with the W3C EPUB Accessibility Guidelines. If you encounter
any accessibility issues with this e-book, please contact the publisher.
</meta>
<meta property="dcterms:modified">2026-04-09T16:56:20Z</meta>
<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>
<meta property="schema:accessibilityHazard">none</meta>
<meta property="schema:accessModeSufficient">textual,visual</meta>
<meta property="schema:accessibilityFeature">none</meta>
<!-- (…) -->
</metadata>
Accessibility metadata in the OPF document
Even though the page size of an e-book is virtual and depends on the screen size of
the reading device, an EPUB could include page break markers that allow readers to
correlate the digital version with the original physical book. Assistive technologies
can use page break markers to help users navigate content in a structured way, especially
when working with materials tied to print-based contexts (e.g., textbooks). If page
markers are retained in EPUB 3.3, the print ISBN must be included in the metadata.
E-books typically only include the e-ISBN in their metadata. If page break markers
are to be retained during transformation to EPUB 3.3, a lookup mechanism from the
e-ISBN to the print ISBN is therefore required. In most cases, our clients provide
Excel spreadsheets or a web interface to their ERP system for this purpose.
Readability
Usually, one would expect an e-book to be readable at the moment it is sold in a digital
store. However, there are still issues that can negatively affect the reading experience.
For example, low contrast between text and background can make the content difficult
to read. Additionally, the use of fixed units such as px may interfere with font scaling in some reading systems. If colors are hard-coded
instead of using system colors where appropriate, this can make high-contrast modes
unusable.
At the moment, repub just fixes smaller issues automatically, e.g., removing fixed colors for hyperlinks
and background colors. Hard-coded units are transformed to relative units such as
em.
Currently, CSS corrections are based solely on text replacements. This makes it difficult
to verify which colors would actually be applied as foreground and background in a
given context. To address this issue, it is planned to integrate the transpect CSS
parser[11], which applies the corresponding CSS properties as XML attributes (CSSa) to the content.
This would make it possible to verify whether the contrast between foreground and
background colors is sufficient.
Limitations
Although this paper frequently discusses accessibility, in this context it primarily
refers to technical accessibility. For example, in the early days of e-book production,
it was common practice to rasterize a large table as image, because e-book readers
did not yet provide proper widgets for navigating complex tables. Currently, this
issue is not automatically detected or fixed by repub. With AI it would be possible to detect this and convert the table to HTML. Even
with AI, you would always need a human in the loop who verifies the results and checks
the content.
With XProc and XSLT, repub performs a static analysis of the document structure. repub does not evaluate the actual rendered DOM tree. Such an analysis would be useful
for identifying visibility-related issues (such as hidden elements, overlapping content,
or insufficient contrast), as well as for assessing keyboard focus order and ARIA
behavior. However, given the flat structure of the content and the limited support
for CSS and JavaScript in EPUB reading systems, the additional benefit does not justify
the required effort. Additionally, implementing the transpect CSS parser would likely
be sufficient to automatically resolve contrast issues. In my view, contrast issues
are one of the few problems that would still remain after a repub conversion.
Another issue that repub currently does not address is that, in EPUB 2.0, the order of elements in the navigation
and in the content was not required to be consistent. For accessible navigation, however,
the order of entries in the table of contents must match the reading order of the
content. Since we not permitted to alter the content, this can only be resolved based
on instructions from the publisher or author.
Final Thoughts
repub is a software library designed to address issues in e-book backlists. While it cannot
eliminate every barrier, it significantly improves standards compliance and increases
the likelihood that an e-book will pass accessibility validation. As a result, more
books become accessible to readers who rely on assistive technologies, while all users
benefit from the transition to modern technical standards.
Although I believe we are slowly reaching the limits of what can be addressed through
traditional programming,
certain types of content, such as rasterized tables or audio tracks, can be made accessible
using AI models. While
I remain sceptical that an LLM alone could reliably convert large volumes of e-books,
an LLM using
repub may be able to do so.
Over 10,000 e-books were converted with repub in the past few months, which I regard it
as success, given that we announced it at the end of 2024. My colleague Anna Schmalfuß
used
repub as a library for the development of another tool that bundles multiple e-books into
one. Since repub is Open Source, I hope that it will be adopted by others to create more
accessible versions of existing e-books.
