The European Union recently took a significant step to require e-books to be born accessible, which means they will have to include for print-disabled users all the features and functionality that those of us without print disabilities enjoy. Not a special e-book edition—the same e-book.
This new directive actually applies to a broad range of products, systems, and services: e-books are included, as are e-readers and the systems by which users find, obtain, and consume e-books. But it is important to focus on the e-books themselves. The reason is a potential unfortunate consequence of the E.U. directive. The requirements take effect in 2025. That’s because it will take three years for this to get incorporated into the laws of all the E.U. countries, and the E.U. then allows three years for products and systems to get updated. Lots of products and systems, not just e-books.
There is an excellent article by F.J. Martinez Calvo on the directive from the library perspective, titled, “Do You Want an Accessible E-book? Come Back in 2025.” That sends a horrible message (the directive, not the article). Publishers should be making books born accessible now, not years from now. And for most publishers, that’s attainable.
The reason, as I pointed out in a PW Digital Perspectives column earlier this year, is that the ePub 3.2 standard is designed to enable e-books to be fully accessible. Many publishers already produce ePubs that conform to that standard, and most of the vendors who create those ePubs know how to make them accessible.
Assuming a house already publishes in ePub 3.2, what else does it need to do to make them born accessible?
This is not an exhaustive list, but it covers all the main things that aren’t always in those standard ePubs. Remember: accessibility is not binary. Don’t think it’s all or nothing. The more accessibility features a publisher provides, the more accessible its e-books will be. (I won’t get into coding details; vendors should know how to do most of these things.)
So here, in the order I think will make the most sense for the most publishers, is what’s needed to make ePubs work with assistive technology (AT).
1. Make sure the HTML tagging in the content is proper. This means having a logical reading order, using proper heading tags, and using HTML elements—sections, tables, etc.—the way they’re designed to be used. Your ePub vendor should be doing this anyway. If it can’t, you need a different vendor.
2. Provide good navigation features. This includes things you’re already doing, such as providing a linkable table of contents, as well as something you should be doing: putting in markers that indicate where the corresponding print pages break, along with what ePub calls a pagelist, which enables users to go straight to particular pages.
3. Provide image descriptions. Many books don’t have illustrations, but the cover is an image; that image needs alt text saying something like alt="cover: [title] by [author]". Here’s another nuance many people don’t realize: alt text should only be provided for meaningful images. Decorative images get what’s called the null alt: alt="". For the meaningful images, the descriptions should convey what the image conveys to a sighted user. Don’t just repeat the caption; AT already read that. And don’t just say “image” or use the filename of the image! Imagine how useless that is. You may be doing that without knowing it. Just stop it!
4. Provide accessibility metadata. This can be embedded in your ePubs and on your website (it’s in schema.org) as well as in the ONIX feed you provide to retailers. It informs customers or users what accessibility features the ePub contains and how they can be accessed. This is not commonly done, but it should be. It’s pretty simple. Once publishers start doing this, the aggregators and retailers should start using it.
5. Add ARIA markup. Now we’re getting into things that aren’t usually there. But this is tremendously helpful, because AT is programmed to recognize this markup. It’s not hard. It provides things like role="presentation" on those decorative images, or identifying a as a chapter. Again, your vendor should know how to do this.
6. If you’ve got math, use MathML. Most vendors use MathML in their workflows, or else a tool such as MathType that can provide MathML. The reason it’s not usually included in ePubs is that ePub reading systems have used it badly or not at all. But that’s about to change. DAISY can provide your vendor with guidance on how to include both the image and the MathML in a way that works.
That’s pretty much it for most books. Synchronized text and audio is great (the E.U. might require it), but it’s rarely done, and tools such as iPhones and screen readers do a decent job of text-to-speech. When e-books have audiovisual content, there’s a lot more to do. For example, videos need closed captioning and transcripts, but that’s most common in higher ed; all the big higher-ed publishers are already doing this. One last thing: there’s a free, easy-to-use automated tool to analyze ePubs for accessibility: Ace by DAISY. So there’s no reason to think you just got a pass to not make your e-books accessible until 2025. Do it now!
