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:

<details>
    <summary>Summary</summary>
    <p>…</p>
</details>

(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:

<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>

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>
    <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>

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 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>

Another option is to include a hyperlinked text label to your long description:

<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>

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:

<img src="rounded-corner.jpg" alt=""/>

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.