epubjs

Version:

Render ePub documents in the browser, across many devices

75 lines (72 loc) • 6.25 kB

HTML

<?xml version="1.0" encoding="UTF-8" ?><!DOCTYPE html><html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Chapter 2. Building a Better EPUB: Fundamental Accessibility</title> <link rel="stylesheet" type="text/css" href="css/epub.css" /> <meta name="dat-origPath" value="/html/body/section/section" /><link rel="prev" href="./ch02_1.html" /><link rel="next" href="./ch02_3.html" /></head><body> It’s not always obvious to sighted readers at this point why semantics are important for them, though, as they just expect to see the visual presentation the forms provide and to navigate around with fingers and eyes. But that’s also because no one yet expects more from their digital reading experience than what they were accustomed to in print. Knowing whether a section is a chapter or a part as you skip forward through your ebook can make it so you don’t always have to rely on opening the table of contents. Knowing where the body matter section begins can allow a reading system to jump you immediately to the beginning of the story instead of the first page of front matter. Knowing where the body ends and back matter begins could allow the reading system to provide the option to close the ebook and go back to your bookshelf; it might also allow links to related titles you might be interested in reading next to be displayed. Without semantically rich data, only the most rudimentary actions are possible. With it, the possibilities for all readers are endless. So, to wrap up the analogy, while some of us can read in the shadow world of generalized markup, all we get when we aim that low is an experience that pales to what it could be, and one that needlessly introduces barriers to access. If I’ve succeeded in bringing these terms into relief, you can hopefully now appreciate better why semantics and structure have to be applied in harmony to get the most value from your data. The accessibility of your ebook is very much a reflection of the effort you put into it. The reading system may be where the magic unfolds for the reader, but all data magic starts with the quality of the source. With that bit of high-level knowledge under our belts, let’s now turn to how the two work together in practice in EPUB 3 to make content richer and more accessible. <h3 class="title" id="_data_integrity" data-origPath="/html/body/section/section/section[1]/h3">Data Integrity</h3> The most important rule to remember when structuring your content is to use the right element for the right job. It seems like an obvious statement, but too often people settle for the quick solution without thinking about its impact; look no further than the Web for examples of markup run amok. Print to digital exports are also notorious for taking the path of least complexity (<code class="literal">p</code>-soup, as I like to call the output that wraps most everything in paragraph tags). In fairness, though, print layout programs typically lack the information necessary for the export to be anything more than rudimentary. When present, however, reading systems and assistive technologies are able to take advantage of specialized tags to do the right thing for you, but there’s little they can do if you don’t give them any sense of what they’re encountering. When it comes to EPUB 3, if you don’t know what’s changed in the new HTML specification, go and read the element definitions through; it’s worth the time. EPUB 3 uses the XHTML flavor of HTML5 for expressing text content documents, so knowledge of the specification is critical to creating good data. Don’t assume knowledge from HTML4, as the purpose of many elements has changed, and elements you thought you knew might have different semantic meanings now (especially the old inline formatting elements like <code class="literal">i</code>, <code class="literal">b</code>, <code class="literal">small</code>, etc.). And remember that structure is not about what you want an element to mean. The changes to the HTML5 element definitions may not always make the most sense (see the human restriction on the <code class="literal">cite</code> element as one commonly cited example), but twisting definitions and uses to fit your own desires isn’t going to make you a friend of accessibility, either. Reading systems and assistive technologies are developed around the common conventions. And whatever you do, don’t perpetuate the sin of immediately wrapping <code class="literal">div</code> and <code class="literal">span</code> tags around any content you don’t know how to handle. It’s <a class="ulink" href="http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-xhtml-content-type-attribute" target="_top">a violation</a> of the EPUB 3 specification to create content that uses generic elements in place of more specific ones, and it doesn’t take long to check if there really is no other alternative first. When you make up your own structures using generic tags, you push the logical navigation and comprehension of those custom structures onto the reader (and potentially mess up the HTML5 outline used for navigation). Sighted readers may not notice anything, but when reading flows through the markup, convoluted structures can frustrate the reader and interfere with their ability to effectively follow the narrative flow. </body> </html>