Extended Descriptions in EPUB3

[gregoriopellegrino]

Similar to the [footnotes issue (#2690)](#2690), extended descriptions for images represent another area that appears to be under-specified in the EPUB standard, with implications for accessibility and user experience.

There are several techniques for inserting extended descriptions in EPUBs (summary/details, hidden extended description, etc.). One of the techniques used is using a link near the image that navigates to the full description, followed by a back-link to return to the original content. However, this approach presents several challenges:

1. These links are not programmatically identifiable as extended descriptions
2. There are no established best practices for reading systems to handle these links
3. The current implementation has a disruptive navigation experience for users, particularly those using assistive technologies

[mattgarrish]

These links are not programmatically identifiable as extended descriptions

You can use aria-details to point to a link to a description. It's one of the examples they provide in the spec for its use: https://www.w3.org/TR/wai-aria-1.3/#example-31

But the lack of universal support for going back to where you were is definitely not a good look.

[GeorgeKerscher]

Are we thinking that semantics of a link to an extended description is needed? As its mate, do we want semantics that this is an extended description?

[mattgarrish]

Are we thinking that semantics of a link to an extended description is needed?

Are links to descriptions all that ambiguous? The reason we added the semantics we did for links is because it's not necessarily clear what a word, or number, or symbol might be linking to.

The more common issue is finding the link, but that's what aria-details can help with.

[gregoriopellegrino]

In my opinion, it is not so much an issue of semantics as finding a common best-practice across the supply chain to identify this type of link. This can help in different tasks, such as:

• automated control of which images have the extended description
• development of custom UX in reading solutions
• optimization of authoring tool outputs
• etc.

[clapierre]

+1 to Gregorio's comments. Also, note that some publishers are referring to these as "Text Alternatives" instead of "Extended Descriptions". It would be great if we could come up with some best practices around all this, so we have a unified approach and consistency across the ecosystem.

[iherman]

This was discussed during the pmwg meeting on 20 March 2025.

View the transcript

Footnotes and Extended Descriptions - w3c/epub-specs#2690

<wendyreid> w3c/epub-specs#2691

wendyreid: footnotes have come up a couple of times on the list, and gpellegrino opened an issue on extended descriptions
… these are very similar issues
… There was once a philosophical decision that epub would explain how to make the metadata, etc, but we wouldn't tell them how to actually write their books
… We are now seeing there is confusion around features, how to do them well and interchangeably

<wendyreid> w3c/publishingcg#77

wendyreid: There are probably more issues than just footnotes and extended desc
… I opened an issue to see if there are other things that would benefit from having an approach

<gpellegrino> cover page!

SueNeu: Most of my projects don't let me push the envelope very much
… can we think of this in two ways, one as a best practices doc, and another for people who want to be more creative?
… We have also matured, RS have really taken over the UX side
… I am not sure I would want to push the envelope for most titles

Hadrien: Constraints can be liberating

<SueNeu> +1

Hadrien: Without constraints we can't provide some features

<gpellegrino> +1 to Hadrien

Hadrien: setting constraints actually makes features possible

wendyreid: Because of the interconnectedness of content and RS, what is the best approach for producing the document?

<Dale> +1 to Hadrien

wendyreid: It isn't a huge change to add best practices, but it is huge o put it in the spec

gpellegrino: I think a note is the right thing
… the same as 1.1 a11y techniques doc. Notes are easier to update
… though, with a note we can really check implementations

AvneeshSingh: I am reluctant to at user experience mandaes to the spec
… if we need a normative change we should start from ux

<SueNeu> +1

duga: We've certainly had a philosophical position of not mandating UX, except for the times we do (FXL)
… not sure if it's philosophical or practical, footnotes had epub:type for a long time
… but it also caused RMSDK to crash, and it was the main way books were displayed for a long time
… we didn't understand the consequences of the decision, and now we have a mess where people avoided using epub:type
… and there's endnotes vs footnotes, we're not picking one or the other, not something we can dictate
… we did dictate it, and it didn't work, and we created a problem, but it's hard to put in the spec, we don't know what will crash tomorrow

ivan: I must admit, it is difficul to put this into practice coming from the web
… if we put constrains, then are we fighting with what html says to do?
… hml5 goes into extreme detail since it reverse engineers what actually happened in browsers
… how would a RS constraint work? Are we splitting the web?
… If I do a note with best practices, that is fine, but if it is normative it is scary

Hadrien: There is already a lot we do that isn't the web (e.g pagination)
… So this is already the reality
… So footnotes is probably better as best practices
… We already live in a world where we diverge
… But things like popup footnotes are a problem, since they work one way on one platform and differently on another

gpellegrino: We also have spine and TOC which is different from the web
… We need guidance on how to mark things up
… Without proper markup RS have to try and guess which causes problems

<ivan> +1 to gregorio

gpellegrino: the bar shouldn't be on the RS implementation, but on what we expect from authors

<Hadrien> +1 to what gpellegrino just said

<LaurentLM> +1 to Gregorio

wendyreid: We want to push content creators to use html to the full extent
… And we don't see that much today
… Some books are just endless P tags, with different styles
… There is also dpub-aria which is under utilised
… Content creators often don't know what will happen if they use it

AvneeshSingh: Footnote, extended desc, these are important for a11y
… when they change it causes confusion
… We need conformance reqs
… for instance, we need a way to get back from footnotes
… this can be broad guidance

wendyreid: It is helpful for RS implementors to get things in a standard way - implementors know what things would be good here

ivan: So we start with some sort of note, say best practices, keeping an eye on whether we need new things in the spec (eg epub types)
… but I am not seeing much need for normative changes

wendyreid: I think that is right

CharlesL: Another thing is page breaks, they all seem to be different

duga: On the reading system normative side, I think there are some
… being able to go back from a footnote, that's a normative thing we might want to say
… it's strange, but there might be something to add there
… another thing might be the display of footnotes in popups, most RSs display the text, but footntoes aren't used in Japan, they have ruby
… we could make normative statements, if you display a popup, use the HTML
… we can spec all we want, but if there is no one doing it, it may not matter
… we shouldn't be too prescriptive, we should respect the content

CharlesL: Also linking in general, the web already has a back buton
… having a RS mimic that has been missing
… for instance one to many links are hard to author correctly wihout rs back funcionality

Hadrien: For back affordance, there are some RS that have history
… sometimes there is contextual back, usually for following links
… Apple set implementation for popups, but displaying the content richly is really hard
… styling, for instance, is really hard
… No one has managed to do popup + styled

shiestyle: Japanese content is pretty complex, so we generally refrain from footnotes

SueNeu: Ebooks may also diverge on location in the documen
… sometimes we need to be able o point back to a printed item

ivan: Annotation popups will be an issue

CharlesL: And footnote popup can be extended to ext desc
… So guidance there would be great
… WW Norton (Evan Yamanishi) did some experiments with that back in the day
… maybe we can use those as examples

---