Ebook Accessibility: What You Might Be Missing
Ebook accessibility is top of mind for so many publishers these days, partly because of the European Accessibility Act, partly as a sign of a maturing digital publishing landscape. As book production folks, particularly those who outsource the actual conversion work to a third-party vendor, grapple with testing for accessibility, I get more and more questions and requests for consultation to double and triple check that work.
In the interest of making this work easier for everyone, here are a few common things that I’ve found.
Structural Hierarchy
The integrity of any content depends on the heading structure in place. This can be a tricky piece of the accessibility puzzle but one that I find people frequently get wrong. All headings should be marked up as such using h1-h6 tags. Please never mark up a heading with <p class=”h1”>. This feels very straightforward but what about the title of the book on the title page? How do you align all the headers of a series of sidebars? How do developers treat complex chapter headers with many parts? Some advice:
Chapter number and chapter title in simpler content can be in one <h1> using a <span> with a class to make the parts look different. Something like:
<h1 class=”ct”><span class=”cn”>Chapter One </span><br />Chapter Title</h1>
The title, subtitle, and author name should generally not be in header tags.
Use Ace by DAISY to check the structural hierarchy of any book. Ace will check that the headers cascade from one another properly, which is certainly useful. But it’s also an excellent snapshot of a book — both the built-in navigation, and the entire heading structure at a glance.
Screenshot from Ace by DAISY showing the EPUB Table of Contents and the Headings Outline from a complex non-fiction book.
Generic HTML
Avoid generic HTML. Only use <div> and <span> when there isn’t a better HTML tag for the job. Put chapters in a <section> tag, and sidebars in an <aside> tag. Using the right element for that part of the content means that assistive technology users will be able to make better decisions about what to read. Using <div> tags in either of those situations will leave print-disabled readers without enough information to make informed decisions about skipping content to focus on the linear narrative, for example.
Avoid generic HTML. Only use <div> and <span> when there isn’t a better HTML tag for the job.
Similarly, in the case of italicized or bolded words or phrases, make sure that you are using the right tag for the job:
<i> or <b> to italicize/bold content for style reasons only
<em> or <strong> for words or phrases that should be vocally stressed in a read aloud
<cite> for book, newspaper, journal or other citations
Use list markup for lists. Ordered and unordered lists should never have keyed in numbering or bullets. Those visual list markers should always come from the HTML markup. Coding a list properly means that list items get read by assistive technology in a meaningful way: literally, “list item” then the bullet point, for example. Any other treatment — like “• this is my point” — means that “bullet” will get announced, and that the entire list will read in one long, run-on sentence. As the Daisy Knowledge Base says, “Lists are often overlooked as an accessibility feature, but the ability to move quickly and effectively through long lists of data points is a key reading need.”
Glossaries
Related to the above, use the correct format for list of definition. Keyword lists and glossaries should be marked up using a description list, definition term, and definition description: <dl>, <dt>, and <dd>. Using this markup is especially helpful for users with learning or cognitive disabilities as there is clarity about what’s being defined and how to find it. Sample markup looks like this (although there are better explainers on the DAISY KB):
<dl><dt>Grand Slam</dt>
<dd><p>A grand slam occurs when a batter hits a home run with runners on first, second and third base. <i>See also</i> Vladimir Guerrero Jr. </p></dd>
…
</dl>
Images
Use the correct markup for images and captions will make your life as an ebook developer and publisher easier and will make the content easier for everyone to read. Instead of settling for the default markup that comes out of InDesign — an <img> wrapped in a <div> inside of a <div>, and with an extra <div>, just in case — manipulate the software you are using to get more semantic and simpler <figure>/<figcaption> markup. Developers can use object style from software like InDesign to map to these better HTML choices but the caption will not be nested inside the <figure> tag; some post-export HTML editing will be necessary.
More accessible markup that creates pages that are easier to control is a win-win!
Employing the figure–figcaption markup means that your captions will be glued to the images in most reading systems and are less likely to break over a page. More accessible markup that creates pages that are easier to control is a win-win!
Other Notes
A few other random things that defy easy categorization:
Avoid all caps — in headers, in the navigation, and in the text. Use CSS like text-transform:uppercase; to achieve all caps. Make sure that the text underneath is in title case, not lowercase, if that makes sense for the content.
Avoid using word space for styling purposes like letter spacing. A heading like “C H A P T E R O N E” with word spaces between each letter is an example of what I mean. Use CSS like letter-spacing:.05em; or similar to achieve the look you want without sacrificing accessibility.
Mark decorative images as such. Empty alt text and role=”presentation” on the image tag will signal to assistive technology that there is nothing to see here, keep on moving.
I hope this is useful. What am I missing? What questions would you like to see answered? Please feel free to reach out with corrections or queries.
Banner photo by Nick Fewings on Unsplash
