epubjs

<?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_10.html" /><link rel="next" href="./ch02_12.html" /></head><body> <p data-origPath="/html/body/section/section/section[9]/p[12]">But throwing our collective hands up in the air isn’t a viable solution, either. The <code class="literal">details</code> 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 <code class="literal">epub:type</code> 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 <code class="literal">summary</code> element to carry a prose title, as in the following example:</p> <pre class="screen" data-origPath="/html/body/section/section/section[9]/pre[2]"><details> <summary>Summary</summary> <p>…</p> </details></pre> <p data-origPath="/html/body/section/section/section[9]/p[13]">(The value of the <code class="literal">summary</code> element represents the clickable text used to expand/close the field and can be whatever you choose.)</p> <p data-origPath="/html/body/section/section/section[9]/p[14]">If we then take a small liberty with the meaning of the <code class="literal">aria-describedby</code> attribute to also include summary descriptions, we could reformulate the HTML5 specification example to include an explicit pointer to the <code class="literal">details</code> element:</p> <pre class="screen" data-origPath="/html/body/section/section/section[9]/pre[3]"><table aria-describedby="tbl01-summary"> <caption> Characteristics with positive and negative sides. <details id="tbl01-summary"> <summary>Summary</summary> <p>Characteristics are given in the second column…</p> </details> </caption> … </table></pre> <p data-origPath="/html/body/section/section/section[9]/p[15]">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 <code class="literal">details</code> element. It may not prove a great solution in the long run, but until the landscape settles it’s the best on offer.</p> <section class="sect2" title="Figures" data-origPath="/html/body/section/section/section[10]"> <h3 class="title" id="_figures">Figures</h3> <p>Coming up for a quick breath of fresh air before descending into another accessibility attribute pain point, HTML5 introduces the handy new <code class="literal">figure</code> 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:</p> <pre class="screen"><figure> <img src="images/blob.jpeg" alt="the blob"/> <figcaption> Figure 3.7 &#x2014; The blob is digesting Steve McQueen in this unreleased ending to the classic movie. </figcaption> </figure></pre> <p>Unfortunately, there is little support for these two new elements at this time, so they get treated as no better than <code class="literal">div</code> 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 <code class="literal">div</code> elements.</p> </section> <section class="sect2" title="Images" data-origPath="/html/body/section/section/section[11]"> <h3 class="title" id="_images">Images</h3> <p>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 <code class="literal">longdesc</code> 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.</p> <p>If only to keep consistent with the earlier suggestion for tables, wrapping the <code class="literal">img</code> element in a <code class="literal">figure</code> and using a details element as a child of the <code class="literal">figcaption</code> may suit your needs, as shown in the following example:</p> <pre class="screen"><figure aria-describedby="fig01-desc"> <img src="images/blob.jpeg" alt="the blob"/> <figcaption> Figure 3.7 — The blob is digesting Steve McQueen in this unreleased ending to the classic movie. <details id="fig01-desc"> <summary>Description</summary> <p> In the photo, Steve McQueen can be seen floating within the gelatinous body of the blob as it moves down the main street … </p> </details> </figcaption> </figure></pre> <p>Another option is to include a hyperlinked text label to your long description:</p> <pre class="screen"><figure> <p><a href="blob-desc.xhtml">Description</a></p> <img src="images/blob.jpeg" alt="the blob"/> <figcaption> Figure 3.7 — The blob is digesting Steve McQueen in this unreleased ending to the classic movie. </figcaption> </figure></pre> <p>which would allow the accessible description to live external to the content. You’ll notice I haven’t added an <code class="literal">aria-describedby</code> 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.</p> <p>Continuing to make the case for <code class="literal">longdesc</code>, or a better equivalent alternative, is the best course of action, however.</p> <p>But that muckiness aside, it’s much more pleasant to note that the <code class="literal">alt</code> attribute has not changed, even if confusion around its use still abounds. The <code class="literal">alt</code> 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.</p> <p>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 <a class="ulink" href="http://www.cs.tut.fi/~jkorpela/html/alt.html" target="_top">http://www.cs.tut.fi/~jkorpela/html/alt.html</a></p> <p>Of particular note for accessible practices, however, is that even though the <code class="literal">alt</code> attribute always has to be present on images, it does not always have to contain a text alternative:</p> <pre class="screen"><img src="rounded-corner.jpg" alt=""/></pre> <p>This little fact often gets overlooked. If you add text to an <code class="literal">alt</code> 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 <code class="literal">alt</code> attributes, as that allows reading systems and assistive technologies to skip readers past them without interrupting their reading experience.</p> </section> </body> </html>