There’s also no reason why this functionality can’t be equally useful to sighted readers, except that it’s rarely made available. We just talked about the problem of visually rendering table data on small screens, and there’s an obvious solution here to the problem a sighted reader will have of seeing perhaps only a few cells at a time and not having the visual context of what they’re looking at. But whether mainstream devices begin taking advantage of this information to solve these problems remains to be seen.
It’s also good practice to provide a summary of complex tables to orient readers to their structure and purpose in advance, but the summary attribute has been dropped from HTML5. This loss is slightly less objectionable than the longdesc attribute removal we’ll touch on when we get to images, as prose attributes have many limitations—from expressivity to international language support.
The problem is that HTML5 doesn’t replace these removals with any mechanism(s) to allow the discovery of the same information, instead deferring to the aria-describedby attribute to point to the information (see the scripting section for more on WAI-ARIA). This attribute, however, may make the information even less generally discoverable to the broader accessibility community, as only persons using accessible technologies will easily find it.
The proposed HTML5 solutions for adding summaries, like using the caption element, also don’t take into account the need to predictably find this information before presenting the table. The information can’t be in any of a number of different places with the onus on the person reading the content to find it.
But throwing our collective hands up in the air isn’t a viable solution, either. The details element could work as a non-intrusive mechanism for including descriptions, at least until a better solution comes along. This element functions like a declarative show/hide box. Unfortunately, it suffers from a lack of semantic information that the epub:type attribute cannot currently remedy (i.e., there are no terms available for identifying whether the element contains a summary or description or something else). We instead have to use a child summary element to carry a prose title, as in the following example:
Summary
…
(The value of the summary element represents the clickable text used to expand/close the field and can be whatever you choose.)
If we then take a small liberty with the meaning of the aria-describedby attribute to also include summary descriptions, we could reformulate the HTML5 specification example to include an explicit pointer to the details element:
Characteristics with positive and negative sides. Summary
Characteristics are given in the second column…
…
In this markup, a nonvisual reader can now find the summary when encountering the table, while a sighted reader will only be presented the option of whether to expand the details element. It may not prove a great solution in the long run, but until the landscape settles it’s the best on offer.
Figures
Coming up for a quick breath of fresh air before descending into another accessibility attribute pain point, HTML5 introduces the handy new figure element for encapsulating content associated with an image, table, or code example. Grouping related content elements together, as is becoming an old theme now, makes it simpler for a reader to navigate and understand your content:
Figure 3.7 — The blob is digesting Steve McQueen in this unreleased ending to the classic movie.
Unfortunately, there is little support for these two new elements at this time, so they get treated as no better than div elements. That said, it’s still preferable to future-proof your data and do the right thing, as support will catch up, especially since the only other alternative is semantically meaningless div elements.
Images
Images present a challenge for a variety of disabilities, and the means of handling them are not new, but HTML5 has added a new barrier in taking away the longdesc attribute for out-of-band descriptions. Like I talked about for tables, you’re now left to find ways to incorporate your accessible descriptions in the content of your document.
If only to keep consistent with the earlier suggestion for tables, wrapping the img element in a figure and using a details element as a child of the figcaption may suit your needs, as shown in the following example:
Figure 3.7 — The blob is digesting Steve McQueen in this unreleased ending to the classic movie. Description
In the photo, Steve McQueen can be seen floating within the gelatinous body of the blob as it moves down the main street …
Another option is to include a hyperlinked text label to your long description:
Figure 3.7 — The blob is digesting Steve McQueen in this unreleased ending to the classic movie.
which would allow the accessible description to live external to the content. You’ll notice I haven’t added an aria-describedby attribute to this example because only the prose of the associated element gets presented to a reader using an assistive technology. In this case, the word “Description” would be announced, but the reader would not be presented with the option to link to the description.
Continuing to make the case for longdesc, or a better equivalent alternative, is the best course of action, however.
But that muckiness aside, it’s much more pleasant to note that the alt attribute has not changed, even if confusion around its use still abounds. The alt attribute is not a short description; it’s intended to provide a text equivalent that can replace the image for people for whom the image is not accessible.
Best practices for writing the alternative text extend beyond what we can realistically cover in a guide about EPUB 3, and resources can be easily located on the Web if you’re not clear about the distinction between an alt text and description. A good free reference written by Jukka Korpela is available at http://www.cs.tut.fi/~jkorpela/html/alt.html
Of particular note for accessible practices, however, is that even though the alt attribute always has to be present on images, it does not always have to contain a text alternative:
This little fact often gets overlooked. If you add text to an alt attribute, you’re indicating that the image is meaningful to the content and requesting that the reader pay attention to it. Images that only exist to make content look pretty should include empty alt attributes, as that allows reading systems and assistive technologies to skip readers past them without interrupting their reading experience.
SVG
Rounding out the tour of image functionality is SVG. It comes up for debate every so often just how accessible SVG really is, and while you can argue that it can be more accessible than non-XML formats like JPEG and PNG, there’s no blanket statement like “SVG is completely accessible” that can be applied. Like all content, an SVG is only as accessible as you make it, and when you start scripting one, for example, you can fall into all the typical inaccessibility traps.
The advantages of SVG for accessibility are noteworthy, though. You can scale SVG images without the need for specialized zoom software (and without the typical pixelation effect that occurs when zooming raster formats), the images are accessible technology-friendly when it comes to scripting and can be augmented by WAI-ARIA, and you can add a title and a description directly to the markup without resorting to the messy techniques the img element requires:
Figure 1.1, The Hydrologic Cycle The diagram shows the processes of e vaporation, condensation, evapotranspiration, water storage in ice and snow, and precipitation. … …
Note that the SVG working group also provides a guide to making accessible SVGs that should also be consulted when creating content: http://www.w3.org/TR/SVG-access/
The accessibility hooks are also why SVG has been promoted up to a first-class content format (i.e., your ebook can contain only SVG images; they don’t have to be embedded in XHTML files). But if you are going to go with an image-only ebook, the quality of your descriptions is going to be paramount, as they will have to tell the story that is lost in your visual imagery. And to be frank, sometimes descriptions will simply fail to capture the richness and complexity of your content, in which case fallback text serializations should be considered.
MathML
Why is MathML important for accessibility? Consider the following simple description of an equation: the square root of a over b. If you hastily added this description to an image of the corresponding equation, what would you expect a reader who couldn’t see your image to make of it? Did you mean they should take the square root of a and divide that by b, or did you mean for them to take the square root of the result of dividing a by b?
The lack of MathML support until now has resulted in these kinds of ambiguities arising in the natural language descriptions that accompanied math images. Ideally your author would describe all their formulas, but the ability to write an equation doesn’t always translate into the ability to effectively describe it for someone who can’t see it. And sometimes you have to make do with the resources you have available at hand at the time you generate the ebook, and lacking both academic and description expertise is a recipe for disaster.
MathML takes the ambiguity out of the equation, as assistive technologies have come a long way in terms of being able to voice math equations now. There are even Word plugins that can enable authors to visually create equations for you without having to know MathML, and tools that can convert LaTeX to MathML. The resources are out there to support MathML workflows, in other words.
But although EPUB 3 now provides native support for MathML, it is still a good practice to include an alternate text fallback using the alttext attribute, as not all reading systems will support voicing of the markup:
ab
Note
The preceding description was written in MathSpeak. For more information, see the MathSpeak™ Initiative homepage.
If the equation cannot be described within an attribute (e.g., it would surpass the 255 character limit, requires markup elements, like ruby, to fully describe, etc.), it is recommended that the description be written in XHTML and embedded in an annotation-xml element as follows:
… Frac Root a EndRoot Over b EndFrac
Note that a semantics element now surrounds the entire equation. This element is required in order for the addition of the annotation-xml element to be valid.
Footnotes
Footnotes present another challenge to reading enjoyment. Prior to EPUB 3, note references could not be easily distinguished from regular hyperlinks, and the notes themselves were typically marked up using paragraphs and divs, which impeded the ability to skip through them or past them entirely.
Picture yourself in a position where you might have to skip a note or two before you can continue reading after every paragraph. And having to manually listen to each new paragraph to determine if it’s a note or a continuation of the text. The practice of clumping all notes at the end of a section is slightly more helpful, but still interferes with the content flow however you read.
The epub:type attribute helps solve both these problems when used with the new HTML aside element, as in the following example:
The “noteref” term in the epub:type attribute identifies that the link points to a note, which allows a reading system to alert the reader they’ve encountered a footnote reference. It also provides the reader the ability to tell the reading system to ignore all such links if she wants to read the text through uninterrupted. Don’t underestimate the irritation factor of constant note links being announced!
Likewise, the aside element has also been identified as a footnote, permitting the reading system to skip it if the reader has chosen to turn off footnote playback. Putting the note in an aside also indicates that the content is not part of the main document flow.
But footnotes are often a nuisance for all readers; sighted readers typically care just as little to encounter them in the text. Identifying all your notes could also allow sighted readers to automatically hide them if they prefer them to not be rendered, saving sometimes limited screen space for the narrative prose. A configurable reading system that lets you decide what content you want to see is within reach with semantically meaningful data.
Page Numbering
It might seem odd to talk about page numbering in a digital format guide, but ebooks have been used by students the world over for more than a decade to facilitate their learning in a world only just weaning itself off print. Picture yourself using an ebook in a classroom where print books are still used. When the professor instructs everyone to open their book to a specific page, your ebook will be most unhelpful if you can’t find the same location. Or think about trying to quote a passage from a novel in your final paper and not being able to indicate where in the print source it came from. Page numbers are not an antiquated concept quite yet.
The practice to date has been to include page numbers using anchor tags, as in the following example:
But unless a reading system does a heuristic inspection of the name attribute’s value to see if it starts with “page” or “pg” or “p” there’s not going to be a lot of value to this kind of tagging for readers. These kinds of anchor points did give a location for navigating from the NCX page list, and it did keep the number from being rendered, but it’s also lost data.
EPUB 3 once again calls on the epub:type attribute to include better semantics:
361
It’s now clearly stated what the span contains, and the page number no longer has to be extracted from an attribute and separated from a page identifier label. It’s now up to the reader and their reading system to determine when and how to render this information, if at all.
One note when you do include page numbering is to remember that you should also include the ISBN of the source it came from in the package metadata:
urn:isbn:9780375704024
Inclusion of the ISBN is recommended as it can be used to distinguish between hardcover and softcover versions, and between different editions, of the source book. All of these typically would have different pagination, which would affect the ability of the reader to accurately synchronize with the print source in use.
This will ensure that students, teachers, professors, and other interested parties can verify whether the digital edition matches the course criteria. Of course, the ideal day coming will be when everyone is using digital editions and sharing bookmarks—and maybe even auto-synchronizing with the professor’s edition.
But there are also other settings beyond educational where page number can be useful, too. Reading is also a social activity, and being able to reference by page numbers in leisure books allows for easier participation in reading groups, for example.
The world isn’t completely digital yet, so don’t dismiss out of hand the need for print -digital referencing when you’re producing both formats for a book.
Getting Around: Navigating an EPUB
We’ve gone over a number of ways to assist in accessible navigation by improving the structure and semantics of your content, but navigating at the content level is only a complement to a good table of contents. EPUB 3 includes a new declarative means of creating tables of contents called the navigation document, which is a fancy way of saying that you can now create a special kind of XHTML document for reading systems to provide their own built-in navigation mechanism(s).
Note
Note that the navigation document is not necessarily the same as the table of contents at the start of the book or at the beginning of a section. The navigation document is primarily intended for reading system use, but can also be included as content if it can serve both roles.
Declarative tables of contents are not new to EPUB 3, however. EPUB 2 had a file format called the NCX for this purpose, which was taken from the DAISY talking book standard (and that format can still be included in EPUB 3 publications for forwards compatibility with older reading systems). But the NCX was a complex solution to a much simpler problem, and actually hindered accessibility in this new context, as its lack of intrinsic display controls led to navigation levels being chopped off to improve visual rendering.
So, to strike back up on a common theme, not all markup is created equal, and the quality of your table of contents for navigation is a reflection whether you put the full structure of your publication in it or not. The new navigation document fortunately gives you the best of both worlds in that it doesn’t require the decision to pick either visual clarity or full accessibility to be made.
