Ebook Accessibility: Here’s What You Might Be Missing

• Tweet
• Email
• Sumo

• Tweet
• Email

For the past month or so, I have been working on a series of accessibility audits for a number of Canadian publishers on behalf of NNELS. The content was broad and diverse, from children’s picture books and novels, to complex scholarly monographs and picture-heavy non-fiction. Some of the titles were typographically astute, some were born ready for consumer customization. It was so much fun to peek under the hood, to see what was working well and what wasn’t.

I want to point to some of the broad strokes of what people are missing in their ebooks when it comes to accessibility. There were a number of areas that came up consistently. Maybe a large chunk of us are misunderstanding some parts of what makes a good EPUB? Regardless, it might be useful to point to some of the common missteps.

There is no reason at this point in the digital publishing timeline to keep producing EPUB 2.

Leave EPUB 2 in the Dust

Fifty percent of the ebooks received were EPUB 2. Le deep sigh. The EPUB 3 standard offers a major breakthrough in terms of accessibility because it sees a bringing together in a single key format the features that were previously only part of a specialist, accessible format – such as the DAISY format – with a mainstream format for publishing ebooks.

There is no reason at this point in the digital publishing timeline to keep producing EPUB 2.

Use HTML 5 Tags

Here’s where I think a lot of ebook trouble comes from: book people (not web developers) are required to make ebooks. They don’t know HTML all that well and assume InDesign won’t betray them. Better to assume that InDesign is just one (imperfect) tool in your tool chain and to second guess every decision it makes on your behalf. InDesign isn’t actively trying to sabotage ebooks, but it’s not necessarily a smart tool.

InDesign will export generic HTML every time unless nudged, pushed, and bullied into doing better. An ebook built with accessibility as one of its priorities is built with more meaningful HTML 5 tags. Using the correct tags means that your content is skippable and machine-legible.

As Dave Cramer says, “Trust HTML.” It is a simple, elegant way to communicate structure and meaning. Wrapping an image + caption in a <figure> and <figcaption> tag leaves some of the layout concerns of those pieces up to the reading system. Marking marginalia as an <aside> signals to the reading system that this content is not part of the main narrative, that the reader can carry on and come back to this content later. A <blockquote> tag is machine legible where <p class="blockquote"> just isn’t.

As Dave Cramer says, “Trust HTML.”

Pay Attention to Structural Hierarchy

The hierarchy of the book should follow the hierarchy of the table of contents. So <h1> tags would be the top-level header in each HTML file. Some screen readers will announce the heading levels to readers to help them make sense of the content. If that’s not baked into the markup, it will be like a long run-on sentence to people using a screen reader, for example.

Using a sound structural hierarchy with headings that cascade from one another effectively will make your ebook easier for print-disabled readers to use.

In general, each HTML file should have a top-level <h1> from which other headers cascade sequentially: h1, h2, h3, h4 and so on (no skipping). Chapter number, dingbat, and title should be wrapped in one <h1> tag with a span tag to separate styling to any of those pieces.

Headings are one of the primary means of navigation for users of assistive technologies. Using a sound structural hierarchy with headings that cascade from one another effectively will make your ebook easier for print-disabled readers to use.

Layer Semantic Inflection onto Your Structure

Consider using an additional layer of semantic inflection in your content. For users of assistive technologies — which rely on an understanding of the underlying markup in order to facilitate navigation — the ARIA role attribute allows more precise meanings to be applied to basic HTML tags.

Sometimes the reading system will use that semantic inflection to prescribe a specific behaviour, like pop-up footnotes. Sometimes they add navigational depth as is the case with a page-list.

Use epub:type semantics to construct a set of landmarks. In much the same way that a pagelist can add to the richness of your ebook’s navigation, landmarks provide another way into the content by marking the bones of your book with semantic tags that make it machine readable — and so easier for reading systems to parse and therefore present in a broadly accessible way. Marking the landmarks makes your content easier to use, read, and comprehend. In addition, marking basic things like the start of content and the table of contents (epub:type="bodymatter", epub:type="toc") will make the conversion to MOBI a little easier.

In every case, epub:type semantic inflection should be complemented by ARIA roles. ARIA is a web standard that is used by assistive technologies. For an introduction to ARIA roles and how to use them, see: http://kb.daisy.org/publishing/docs/html/roles.html.

Include Image Descriptions

Deploying meaningful alt text in ebooks is not a common practice. At all. The descriptive text of alt="image" or alt="image name" is frequently used and is not useful. By allowing this default behaviour, you are missing a key part of your ebook’s accessibility. If the images are not described, that content is then completely unavailable to anyone reading your content in non-traditional ways.

The descriptive text of alt="image" is not useful.

The Diagram Center has an excellent tool for teaching one how to write image descriptions here: http://diagramcenter.org/poet.html. It should be an objective description of the image that takes audience and context into account, with neutral tone and language while describing the image generally and then with more specifics. Beware: the caption is not a description.

Make Decorative Images Skippable

Any images that are purely decorative – e.g., the curlicues at the start or end of chapters – should have empty alt text (alt="") and role="decoration" in the markup. So, for example:

<img class="dingbat" src="images/asterisks.png" 
alt="" role="presentation"/>

When tagged correctly, screen readers will skip right over the image; the role tells the assistive tech that there is nothing to see here, move along.

Mark Context Breaks Semantically

The semantically correct way of marking editorial spaces or context breaks is with an <hr/> tag. You can assign a class and some styling behaviour to that tag, i.e., in order to call a dingbat or other image; those definitions should come from the CSS.

The reason this is important to accessibility is this: without the <hr/> tag, a screen reader will read right through that context break without pause. The reader won’t know that there was a break at that point in the text and, as you might imagine, this will cause a confusing reading experience.

Mark Language Shifts

Be cautious to mark language shifts. By doing so, you ensure that content that is read aloud by assistive technology like screen readers will be read accurately. There is nothing worse than an English-speaking synthetic voice reading French or Spanish as though it is English.

The markup would look something like:

<i lang="FR">J'aime le chocolat.</i>

This is a tedious piece of the accessibility picture to plan for, but your non-traditional readers will thank you for it.

Also, the base language of the ebook should be declared in the OPF, a standard practice we are all likely familiar with, and also on the root HTML element at the top of each piece of HTML. InDesign will put in on the <body> tag erroneously.

Pay Attention to Colour Contrast

Pay attention to colour contrast, being careful to hit 4.5:1 ratio required by WCAG guidelines. Background colour and font colour need to be examined closely. Pay attention to the colour of headers and sidebars. Your readers come in all shapes and sizes and abilities. A faint, skinny header may look cool, but will be invisible to some readers.

Consider using both the WebAIM Color Contrast Checker when planning your ebook, and use the ACE Accessibility Checker to make sure you didn’t miss anything in this regard.

Links

Be cautious that links are live, and are delineated by a style designation that meets colour contrast rules. Hyperlinks should definitely be signalled by a colour shift and by an underline. The colour of the hyperlink should meet colour contrast guidelines. The colour of the hyperlinks is too light, for example. In general, if you use colour contrast to highlight information, you should also indicate its importance in at least one other way. This is a well understood piece of ebook UX.

HTML Page Title Should Be Meaningful

A frequently misunderstood piece of the ebook puzzle is how to treat the title at the top of each HTML file. It should not contain the name of the book but be descriptive of the content that single file contains; so, “chapter two” or similar. Some screen readers will announce the <title> before it starts to read the content.

For more information, see: http://kb.daisy.org/publishing/docs/html/title.html

Styling considerations

Avoid having base paragraph style with any sizing information at all. This could interfere with re-sizing text in some reading systems thus violating a foundational premise of accessibility. Avoid font-size:0.8em; or font-size: 12px;. Instead leave that field out altogether. The base body font size will default to 1em.

Emphasis and Strong

Continuing on the theme of semantically marked-up content, all emphasized content should be delineated with <i>/<em>, <b>/<strong> tags. The alternate tags of <em> and <strong> are meant to be used in a context where the words would be vocally emphasized in some way. These are frequently misused. For a more extensive conversation about this, see: http://epubsecrets.com/semantic-html5-as-she-is-wrote-an-exploration-of-i-em-b-and-strong.php.

Baby Steps

This might feel like a big list but I encourage all developers to take some steps toward a more comprehensive workflow. If it helps make the case to spend more time to to make better ebooks, consider the halo effect of better-built ebooks. An ebook that is structurally sound, with rich navigation, with semantic inflection, and good HTML practices is a better book for all readers. It functions better across the device spectrum, it is ready for new forms of use, including assistive technologies. Truly, it’s a win-win.