Extended Description Whack-a-Mole

With the publishing of the EPUB Accessibility specification, there’s been a noticeable up-tick in people looking to produce accessible content. Normally, that would be a great thing, but it also means more people are hitting on the limitations of reading systems for accessibility. It’s true, EPUB reading systems aren’t just a headache for designers!

Providing extended descriptions is one of the more problematic areas, as we’ve been searching for years now for solutions that meet publishers’ needs and are also broadly supported enough that they can be reliably used. That headache popped up again this last week, so I thought I’d detail the anatomy of finding a solution.

The Problem

If publishers would just link to descriptions that anyone could read, life would be so simple. Unfortunately, a common complaint is that not only can the note reference not be visible, but the description must not be visible, either. Never mind that this is not truly an accessible practice, as it assumes the user who wants the description is blind. (How does someone who has low vision, dyslexia or any other reading or learning disability get to these descriptions? They don’t. But, yes, I know, I know. Contractual obligations.)

The longdesc attribute was an attempt at solving this problem. It was an attribute you could attach to an img element to link to the description. But it never got much in the way of real support, as how it was supposed to work was always under-specified. It also had a fatal flaw in being limited to images when there are other structures, like complex tables, that need descriptions, too.

If you follow accessibility issues at all, you’ll know that longdesc was turfed from HTML 5 (formally called obsoleting). And then it was resurrected as an extension of HTML 5. And all the while support hasn’t improved significantly.

The bigger deathblow for EPUB 3 is that it isn’t supported in HTML 5 proper, so that makes it invalid to use. There were attempts to add the extension, but the acrimony of HTML 5 around it spilled over into EPUB 3 discussions, so it’s fair to say it will probably never be supported. (Who knows what happens with EPUB 4, of course.)

That long story was a preface to saying that we were left on our own to work out an intractable problem. And that’s the crux of this story, what are the solutions for EPUB?


This is the original alternative to longdesc. It’s an attribute for attaching a description to an element. It’s not really meant for extended descriptions, though, as it can’t handle complex markup. Why that’s important is because it means whatever you reference gets flattened to a text string that the user has to listen to from beginning to end. If you wrote a nice long description with list and tables, too bad. Text string. No navigation.

It does meet the invisibility test, though. The description you link to can be visibly hidden and assistive technologies will still read it. Except most don’t.

When we started testing, the results were pretty poor. Only combinations close to native in Firefox worked with invisible descriptions (Firefox EPUBReader extension and Google Play with NVDA). If you don’t hide the content, some others like VoiceOver+iBooks start working, but support was such a mess it can’t be recommended.

The details element

The details element has a lot of promise, as it’s a collapsible box that doesn’t require scripting to work. You provide a label like “Description”, or an icon, and then can write as long and complicated a description as you need and the user only sees the label to open it.

It doesn’t completely pass the invisibility test (much as I hate that requirement) because of the label, but that can be minimized with icons and CSS.

The real sticker is that you have to migrate to EPUB 3.1 to get support for details because it’s a part of HTML 5.1, so is not allowed in EPUB 3.0 content.

I’m also a bit of sceptical of what details will do in practice. Expanding content in paginated reading systems has a way of blowing text off screen. But we’ll see. Hopefully, the reading systems devs will be quick off the block to support the element.

It’s a messy story, but some day this will be incredibly useful.

Back to Basics

So having three techniques fail to pan out, we had to go back to basics: hyperlinks.

You can hyperlink from the image to its description and include a hyperlink at the end of the description that lets the user jump back to where they were. Simple stuff. Visible to everyone.

You can even take steps to minimize the intrusion and prove that accessibility doesn’t have to be ugly. Style the hyperlink so that it isn’t attention grabbing, like the way photo credits are done around the border of the image. Place the descriptions in a separate file, if you have to.

This is the most robust and reliable way to add descriptions right now.

(Note: Watch out for images inside hyperlinks. Support for this is all over the place.)


Another idea we had was what if we added epub:type semantics to the link and description to turn them into pop-up footnotes in supporting browsers. Any user agent that didn’t recognize the semantics would treat them like regular links. Win-win!

Well, yes and no. Everything looked good until we tried to put an image inside the note reference (see note above). iBooks started crashing whenever we clicked on the link. The solution of putting pointer-events: none on the img element got our hopes up when the pop-ups started working, but of course this technique then breaks any mouse interface. After fiddling with media queries for different device sizes, the icon approach was abandoned as too brittle.

Still, it’s something to consider.

So that was the fun week that was in the life of EPUB accessibility: hyperlinks for extended descriptions, with footnoting for the adventuresome.

If you want to see examples, have a look at the images section of the accessible publishing knowledge base.

If you hate these solutions, don’t scream at the accessibility community please. We have to work with what we’re given.

Until the next breakthrough in extended description support…

Update: The original post mentioned aria-details for use with the details element, but on sober second thought I’m not going to play that up at all. It may be fated to the same destiny as longdesc and aria-describedAt before it.

Leave a Reply

Your email address will not be published. Required fields are marked *