Bring order to your workflow on the way to accessible EPUBs
Here are some reasons to make ebooks accessible: increased market share, the law, international treaties, libraries, classrooms, book groups, inclusiveness, common sense.
Lots of bits and bytes have been spilled enumerating the why’s, but here’s what could use some explanation: “How do we get there?”
As Sarah Hilderley and I described at ebookcraft 2017, it takes a team to build accessible ebooks. Editorial, production, art, and marketing all need to be in on it.
But what if they’re not? What if editors don’t have time to write alt text, designers aren’t inclined to develop a high-contrast colour program just for the ebook, or typesetters don’t follow best practices in file setup?
That last item is where building InDesign documents that create accessible EPUBs comes in. The tools are there: mapped style sheets, image anchoring, navigation, scripts, and GREP.
So, even if alt tags aren’t provided and the chapter opener is set in a thin grey font on top of a slightly darker grey background, we can build an EPUB3 document that has a real foundation of accessibility. Once that’s built, we can focus on coaching our team and adding accessibility features.
What can InDesign do?
I’ll look at lots of features in my session at ebookcraft 2018, including style sheets, document structure, and best CSS practices with the new CC2018 mapping possibilities, but for now I want to talk about an overriding principle: how to proceed with intent.
In a PDF world, no one knows my mechanical is a mess.
Everyone has made a sloppy mechanical. Jobs come in late and have to go out early, images are missing, and the captions are twice as long as in the sample chapter. What do you do? You hack, you fudge, you save to PDF, and you walk away. The printer prints and no one knows what horrors lurk behind the scenes.
Making ebooks helped me eliminate those bad practices. I was using a tool I thought I knew well to create a whole new format, with different needs and a very different end product. So, I decided that the only way to attack a job was from large to small issues, then from the first page to the last. No more laying out the end matter before the title page, or the title page before the table of contents just because I felt like it that morning.
Now I open an InDesign mechanical (most often one that someone else has made), address the larger issues, then go to page i and work til the very end.
What larger issues?
I start small, with character styles. Are there character stylesheets? Are they assigned thoroughly? I do a search-and-replace to assign an italic style sheet as needed; bold, too. I look for super- and subscripts, and small caps and drop caps.
Do paragraph styles use GREP to govern short last lines? I delete them before export so I don’t have unwanted <spans> cluttering the HTML.
Are there overrides? I turn on the handy override detector and see what’s highlighted. Here, someone unpleasantly skewed text instead of applying an italic character style.
You get the idea. I sweep a document for the types of issues that add junk code to an EPUB export. Junk makes an ebook less streamlined and less accessible. Besides, it’s better to be careful now than to have the editor tell you — post export — that half of the italicized words are missing because they forgot to assign character styles consistently.
What’s does all this have to do with accessibility?
Lots. I’m not a native HTML speaker, so my brain was already bursting as I dealt with the over-enthusiastic markup that InDesign generates. I cringed when I first started hearing about adding epub:type, <section>, and role=”presentation.”
As it turns out it’s not so difficult. I’ve already used character and paragraph style sheets. So, mapping to specific tags and classes was pretty simple. I came to know object styles really well, so mapping those to <figure> instead of the default <div> was straightforward too. I added epub:type in the object exports dialog box.
Since I had a solid, clean workflow, getting into the nitty gritty of accessibility helped tremendously. I already did x, so doing x+1 wasn’t too bad.
How proceeding with intent helps build an accessible EPUB
You’ll generate reliable output. If you develop and follow a straightforward workflow, you’ll know what to expect every time. Use the same names for your style sheets, every time. And if it’s a unique style, it deserves a style sheet. Don’t just add space above that one paragraph because it’ll be fine in the PDF. That space will disappear in the EPUB unless you give it a style and assign it a class.
It makes life easier. You still get that extra, extraneous, additional junk out of InDesign’s export, but the semantic markup — your accessible foundation — will be there as well. Your sections in place, your asides assigned, your <i>s distinguished from your <em>s.
You will get cleaner export. InDesign CC2018 has some excellent features in the style mapping department that give much cleaner markup. Cleaner HTML means easier access for the software and a longer shelf life for your EPUB as standards change.
The future is here. EPUB is based on web technology. It’s now being developed by Publishing@W3C, the publishing initiative within the World Wide Web Consortium. At some point, browser and book will meet and blend in some way. If you want your EPUB to remain viable, build it clean and build it accessible. (Read more about EPUB-web convergence here.)
We may not be able to get participation from everyone right now. But we can export EPUBs that take a big step towards accessibility, that are well made, and that will be usable for years to come.
If you’d like to hear more from Kevin Callahan about accessible ebooks, register for ebookcraft, March 21, 2018 in Toronto. You can find more details about the conference here, or sign up for our mailing list to get all of the conference updates.