What a year, right? With the approach of the EAA, decisions publishers are making about WCAG compliance, Title II, and Amazon changing its deliverable epub formats (again), the Westchester staff have been hearing quite a lot from our clients. To help address our clients’ questions, and also share information more widely, we put together this brief blog post about some key topics related to digital content and workflows, to help share our perspective and institutional knowledge.
Language Tagging Manuscripts
The goal of language tagging is to ensure that assistive technology can correctly interpret phrases, passages, and certain individual words presented in other than the document’s primary language. It is a requirement for meeting WCAG 2.x Level AA. It is worth noting, at this point the EAA does not explicitly require WCAG 2.x Level AA, but some publishers are more actively pursuing this higher level of standard to stay ahead of the game in case clarifications or new requirements force this requirement over time.
Language tagging is not necessarily needed on every publication. The stated exclusions to this rule are “proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular.”
The proper names exclusion is taken to apply to “people, places, organizations” (and the like) per CMOS Shoptalk, the Random House Guide to Good Writing (Ivers 1991, which specifically adds “churches, streets”), and DAISY (which helpfully renders this simply as “names”). Titles of works are not part of this exclusion; see, for instance, the article “Declaring language in HTML” where the W3C uses a book title for their example. Technical Terms This exclusion applies to terms which have a technical meaning across languages. WCAG gives the examples of Homo sapiens, Alpha Centauri, hertz, and habeas corpus. In practice, especially within academic publishing and if the tagging is handled by a non-specialist, such terms can be harder to identify. Generally, any jargon falls into this category, but an understanding of the intended audience may also factor into whether to tag or not. Indeterminate Language Gibberish and most constructed languages belong to this category, but Esperanto has an ISO language code, as do Tolkien’s Elvish languages of Quenya and Sindarin, and Star Trek’s Klingon, so all those can be tagged. Part of the Vernacular Foreign words or phrases that find themselves in the English dictionary (to take this from the English perspective) may be excluded from tagging. WCAG gives “rendezvous” as an example. A perhaps better example would be “sine qua non.” If the text in question is italicized, and it’s not to show emphasis or to state the word as a word, that may be a good indication that it should be tagged. WCAG advises, “If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.”
Amazon no longer supporting MOBI Fixed Layout files
As of March 18, 2025, Amazon no longer supports MOBI fixed-layout files. This is similar to when Amazon stopped supporting MOBI files for reflowable books on August 1, 2021. One difference is that besides EPUB, there is an alternate Amazon-specific format which may be more appropriate for some content, Kindle Package Format (KPF). If you are an Ingram CoreSource customer, they are setup to accept this format, and so digital asset management on their platform will be a seamless transition from FXL MOBI to FXL KPF. If you already have content posted to Amazon in the older format, you are not required to update it for it to remain on sale. But if you do update an existing file (e.g. to handle reprint corrections, replace back ads, etc.) you will be required to upload the new file in the KPF format.
Metadata
Rich accessibility metadata in EPUB and ONIX goes beyond ticking a standards box. It actively improves discovery and usability for readers, unlocks new markets, aids institutional buyers (libraries/education), and bolsters a publisher’s social responsibility image. Accessibility metadata within EPUBs makes them self-descriptive about their accessible features, helping users and systems find suitable titles. ONIX metadata allows distributors to “present this information to potential purchasers and readers” ahead of time, so they can make informed choices. Industry groups like DAISY and Accessible Publishing Learning Network (APLN) provide guidance on how to implement this metadata (see DAISY’s Inclusive Publishing “Metadata” page, which provided the preceding quote, and APLN’s “Accessibility Metadata Best Practices for Ebooks”), so that every accessible feature is documented and visible and may benefit users and publishers alike.
To comply with the EAA, metadata should be provided for the relevant accessibility items, particularly those from Codelist 196 and Codelist 143, though other metadata may apply as well (e.g., Codelist 81).
Whatever database or title management system you use to manage your metadata should have fields that correspond to the ONIX codes.
If you’re unsure of which accessibility features are included in your EPUB, you may get most of those details from an Ace report.
Probably the best resource (with explanations and examples of both EPUB and ONIX metadata) is the DAISY Accessible Publishing Knowledge Base metadata page. It still requires some technical understanding though.
The accessibility metadata in a typical EPUB for a non-fiction book with images, and which has been produced with the intent to be accessible, would look something like the following:
<meta property=”schema:accessibilityFeature”>ARIA</meta>
<meta property=”schema:accessibilityFeature”>displayTransformability</meta>
<meta property=”schema:accessibilityFeature”>pageBreakMarkers</meta>
<meta property=”schema:accessibilityFeature”>pageNavigation</meta>
<meta property=”schema:accessibilityFeature”>readingOrder</meta>
<meta property=”schema:accessibilityFeature”>structuralNavigation</meta>
<meta property=”schema:accessibilityFeature”>tableOfContents</meta>
<meta property=”schema:accessibilityFeature”>index</meta>
<meta property=”schema:accessibilityFeature”>alternativeText</meta>
<meta property=”schema:accessMode”>textual</meta>
<meta property=”schema:accessMode”>visual</meta>
<meta property=”schema:accessModeSufficient”>textual,visual</meta>
<meta property=”schema:accessModeSufficient”>textual</meta>
<meta property=”schema:accessibilityHazard”>none</meta>
This is not an exhaustive list. Other features may be present (MathML or long descriptions, for example), conformance level may be identified, and a summary (no longer required) should be included with other relevant info, especially if any shortcomings. And these accessibility metadata items are of course to be included in addition to standard metadata such title, author, and source ISBN.
One important note is that the accessibility summary for ONIX does not have the same guidelines as the summary for EPUB. So, while mapping to ONIX based on the Ace report generally works well, it is not necessarily advisable to copy that for the ONIX summary.
The Westchester team has the expertise you can rely on to make sense of the updated standards and guide you through changes you may need to make to your content to ensure it remains accessible and discoverable for your readers. Contact us to learn how we can help your publication program.
