by Matt Garrish
Usability as defined here, however, is outside the realm of content production, and can’t be tackled by a guide whose focus is increasing the quality of your content. The EPUB specification bakes in some requirements on the reading system side to improve usability, but not every reading system is going to support every accessible feature, and usability is not just support for EPUB but extends into the design of reading systems themselves.
You can’t let usability influence your accessibility decision making, however. A typical practice is to target the industry-leading platform and build around its capabilities (and deficiencies), but what value does this bring you in the long term? Think of the cost that resulted from making Internet Explorer-only friendly websites when it held 90 plus percent of the market as an example of where following the leader can take you. Your books will hopefully be selling well for years to come, but unless you enjoy reformatting from scratch each time you look to upgrade or enhance, it pays to put the effort into doing them right up front.
But it’s time to roll up our sleeves and get our hands dirty…
Chapter 2. Building a Better EPUB: Fundamental Accessibility
This guide takes a slightly different approach to accessibility because of the feature-rich nature of EPUB 3. Instead of grouping all the practices together under a single rubric of essentiality, I’m going to instead take a two-tier approach to making your content accessible.
This first section deals with the core text and image EPUB basics, while the second ventures into the wilder areas, like scripting and the new accessible superstructures you can build on top.
I’m going to start with a section on the fundamentals of accessible content, naturally enough, because if you get your foundation wrong, everything else degrades along with it.
A Solid Foundation: Structure and Semantics
The way to begin a discussion on the importance of structure and semantics is not by jumping into a series of seemingly detached best practices for markup, but to stop for a moment to understand what these terms actually mean and why they’re so important to making data accessible. We’ll get to the guidelines soon enough, but if you don’t know why structure and semantics matter, you’re already on the fast track to falling into the kinds of bad habits that make digital data inaccessible, no matter the format.
Although the terms are fairly ubiquitous when it comes to discussing markup languages and data modeling generally—because they are so important to the quality of your data and your ability to do fantastic-seeming things with it—they are often bandied about in ways that make them sound geeky and inaccessible to all but data architects. I’m going to try and make them more accessible in showing how they facilitate reading for everyone, however.
Let’s start simple, though. You’re probably used to hearing the terms defined along these lines: structure is the elements you use to craft your EPUB content, and semantics is the additional meaning you can layer on top of those structures to better indicate what they represent.
But that’s undoubtedly a bit esoteric if you don’t go mucking around in your markup on a regular basis, so let’s take a more descriptive approach to their meaning. Another way to think about their importance and relationship is via a little reformulation of Plato’s allegory of the cave. In this dialogue, if you’ve forgotten your undergrad Greek philosophy, Socrates describes how the prisoners in the cave can only see shadows of the true forms of things on the walls as they pass in front of a fire, and only the philosopher kings will eventually break free of the chains that bind them in ignorance and come to see the reality of those forms.
As we reformulate Plato, the concept of generalized and specific forms is all that you need to take away from the original allegory, as getting from generalized to specific is the key to semantic markup. In the new content world view I’m proposing, the elements you use to mark up a document represent the generalized reflection of the reality you are trying to express. At the shadow level, so to speak, a chapter and a part and an introduction and an epilogue and many other structures in a book all function in the same way, like encapsulated containers of structurally significant content.
These general forms allow markup grammars, like HTML5, to be created without element counts in the thousands to address every possible need. A generalized element retains the form of greatest applicability at the expense of specifics, in other words. The HTML5 grammar, for example, solves the problem of a multitude of structural containers with only slightly differing purposes by introducing the section element.
But what help is generalized markup to a person, let alone a reading system, let alone to an assistive technology trying to use the markup to facilitate reading? Try making sense of a markup file by reading just the element names and see how far you get; a reading system isn’t going to fare any better despite a developer’s best efforts. HTML5 may now allow you to group related content in a section element, for example, but without reading the prose for clues all you know is that you’ve encountered a seemingly random group of content called section. This is structure without semantics.
You might think to make out the importance of the content by sneaking a peek ahead at the section’s heading—assuming it has one—but unless the heading contains some keyword like “part” or “chapter” you still won’t know why the section was added or how the content is important to the ebook as a whole. And cheating really isn’t fair, as making applications perform heuristic tests like looking at content can be no small challenge. This is both the power and failing of trying to process generalized markup languages and do meaningful things with what you find: you don’t have to account for a lot, but you also don’t often get a lot to work with.
Getting back to our analogy, though, it’s fair to say we’re all philosopher kings when it comes to the true nature of books; we aren’t typically interested in, and don’t typically notice, generalized forms when reading. But, whether we realize it or not, we rely on our reading systems being able to make sense of these structures to facilitate our reading, and much more so when deprived of sensory interactions with the device and content. When ebooks contain only generalized structures, reading systems are limited to presenting only the basic visual form of the book. Dumb data makes for dumb reading experiences, as reading systems cannot play the necessary role of facilitator when given little-to-nothing to work with. And that’s why not everyone can read all digital content.
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.
Data Integrity
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 (p-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 i, b, small, 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 cite 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 div and span tags around any content you don’t know how to handle. It’s a violation 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.
If you don’t discover an existing element that fits your need, the process of checking will typically reveal that you’re not alone in your problem, and that community-driven solutions have been developed. Standards and conventions are the friend of accessibility. And if you really don’t know and can’t find an answer, ask. The IDPF maintains discussion forums where you can seek assistance.
There are, of course, going to be many times when you have no choice but to use a generic tag, but when you do, always try to attach an epub:type attribute with a specific semantic (we’ll cover this attribute in more detail shortly). The more information you can provide, the more useful your data will be.
Take the converse situation into consideration when creating your content, too. You aren’t doing readers a service by finding more, and ever complex, ways to nest simple structures. The more layers you add the harder it can be to navigate, as I already mentioned. Over-analyzing your data can be as detrimental to navigation as under-analyzing.
For persons who cannot visually navigate your ebook, this basic effort to properly tag your data reduces many of the obstacles of the digital medium. The ability to skip structures and escape from them starts with meaningfully tagged data. The ability to move through a document without going to a table of contents starts with meaningfully tagged data.
Note
Skipping and escaping are terms that will come up repeatedly in this guide. Skipping, as you might expect, is the ability to ignore elements completely, to skip by them. Accessible reading systems typically provide the ability for the reader to specify the constructs they wish to ignore, such as sidebars, notes, and page numbers. Escapable content typically consists of deep-nested or repetitive structures—such as found in tables and lists—that a user may wish to move out from in order to continue reading at the next available item following the escaped content (a reading system’s user interface would normally provide quick access to the “escape” command, so that the operation can easily be called repetitively, if needed).
The integrity of your data is also a basic value proposition. Do you expect to throw away your content and start over every time you need to re-issue, or do you want to retain it and be able to easily upgrade it over time? Structurally meaningful data is critical to the long-term archivability of your ebooks, the ability to easily enhance and release new versions as technology progresses, as well as your ability to interchange your data and use it to create other outputs. Start making bad data now and expect to be paying for your mistakes later.
Separation of Style
Some old lessons have to be continuously relearned and reinforced, and not mixing content and style is a familiar friend to revisit whenever talking about accessible data.
To be clear, separating style does not mean avoiding the style attribute and putting all your CSS in a separate file, even if that is another good practice we’ll get back to. What separation of style refers to is not expecting the visual appearance of your content to convey meaning to readers. Style is just a layer between your markup and the device that renders it, not an intrinsic quality you can rely on to say anything about your content. Typographic conventions had to convey meaning in print because that was all that was available, and are still useful for sighted readers, but are the wrong place now to be carrying meaning.
Some reading systems will give you the full power of CSS, while others won’t even have a screen for reading. Some readers will visually read your content, while others will be using nonvisual methods. If only the visual rendering of your content conveys meaning to the reader, you’re failing a major accessibility test. Leave style in that in-between layer where it targets visual readers, and keep your focus on the quality of your markup so that everyone wins.
The most basic rule of thumb to remember is that if you remove the CSS from your ebook, you should still be able to extract the same meaning from it as though nothing had changed. Your markup is what should ultimately be conveying your meaning. If you rely solely on position or color or whatever other stylistic flair you might devise, you’re taking away the ability of a segment of your readers to understand the content.
But there is something to be said for cleanly separating content from style at the file level, too. The cascading nature of styles means that the declaration closest to the element to be rendered wins. If you tack style attributes all over your content you can interfere with the ability of a reader to apply an alternate style sheet to improve the contrast, for example, or to change the color scheme, as the local definition may override the problem the reader is attempting to fix. Consequently, suggesting that you avoid the style attribute like the plague is actually not an overstatement.
More realistically, though, you should be able to use CSS classes for your needs. If, for some reason, you do have to add a style attribute, though, avoid using it to apply general stylistic formatting. Keeping your style definitions in a separate file simplifies their maintenance and facilitates their re-use on the production side, anyway, and this simple standard practice nets you an accessibility benefit.
Semantic Inflection
I’m not going to rehash the reasons for semantic markup again, but I intentionally neglected getting into the specifics of how they’re added in EPUB 3 until now so as not to confuse the need with the technical details.
Adding semantic information to elements is actually quite simple to do; EPUB 3 includes the epub:type at
tribute for this purpose. You can attach this attribute to any HTML5 element so long as you declare the epub namespace. The following example uses the attribute to indicate that a dl element represents a glossary:
…
- Brimstone
- Sulphur; See Sulphur.
Whenever you use unprefixed values in the attribute (i.e., without a colon in the name), they must be defined in the EPUB 3 Structural Semantics Vocabulary. All other values require a defined prefix and are typically expected to be drawn from industry-standard vocabularies. In other words, you cannot add random values to this attribute, like you can with the class attribute.
You can create your own prefix, however, and use it to devise any semantics you want, but don’t create these kinds of custom semantics with the expectation they will have an effect on the accessibility or usability of your ebook. Reading systems ignore all semantics they don’t understand and don’t have built-in processing for. It would be better to work with the IDPF or other interested groups to create a vocabulary that meets your needs if you can’t locate the semantics you need, as you’re more likely to get reading system support that way.
The attribute is not limited to defining a single semantic, either. You can include a space-separated list of all the applicable semantics in the attribute.
A section, for example, often may have more than one semantic associated with it: