epub-specs
epub-specs copied to clipboard
w3c
Extended Descriptions in EPUB3
Similar to the [footnotes issue (#2690)](https://github.com/w3c/epub-specs/issues/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:
- These links are not programmatically identifiable as extended descriptions
- There are no established best practices for reading systems to handle these links
- The current implementation has a disruptive navigation experience for users, particularly those using assistive technologies
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.
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?
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.
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.
+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.
This was discussed during the pmwg meeting on 20 March 2025.
View the transcript
Footnotes and Extended Descriptions - w3c/epub-specs#2690
<wendyreid> w3c/
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/
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
Do we need to identify the chunk of text which provide the extended description in addition to the link which points to this text. e.e. aria-details on page 2 points a link, which points to the extended description on last page (e.g. page 210). the link can be identified with help of aria-details. But is there a need to identify the description which is on page 210?
This was discussed during the pmwg meeting on 17 July 2025.
View the transcript
Extended Descriptions in EPUB3: Issue #2691
<AvneeshSingh> w3c/
gpellegrino: define a common way to semantically tag an extended description the image, the link to the description and the backlink.
… give this template to publishers so that it becomes a common way to do extended descriptions and RS can start to leverage this tagging, and tools can of the supply chain, to extracting the extended descriptions, etc. could utilize this common tagging structure. I made two versions to try to experiment with the semantics we have now.
… without new ARIA codes/attributes I released first set of examples, and we discussed and I made an update that I released yesterday the latest version 2 files 1. main content with the actual chapter with 2 images both having a extended descriptions, one with a fig/figcaption and the other is just an image without a container with linksto the extended descriptions to a different file, it is in the spine with linear no, so you can only reach it via the link not by browsing to the end of the book.
… this document 2 sections are the tags we used for the container for the ext-desc. with the image with role="presentation" alt="", and then the extended description with back link to the original image.
… limitations: 1. tried to put link to the ext. description inside the fig tag but after the caption. the fig caption must be first or last tag of the figure. so the link is in the caption as a result.
… we don't have proper semantic roles to the link to the extended description. JS / tools can select all the links to the extended descriptions, but for the ext. desc. container we don't have a solution. RS can implement across different document what links point to the container file, or some new roles would need to be added to DPUB aria for example.
AvneeshSingh: the identification is done by aria-details on an image pointing to a link anchor which goes to the extended description file.
… this is main focus area, is this enough special behavior for RS, accessibility checking tools, etc. or do we need something more for explicitly specifying the container of the ext. description.
George: Years ago there was longdesc attribute which could go to a different page of the description, which was opposed, since you could loose where you were if you went to a different page.
… we have an id pointing to the link. maybe it is problematic link to another file in an attribute in which case having a similar relationship like notref/footnote have a extendedDescRef and extendedDesciption as DPUB aria roles.
… RS could figure out this is an ext. description ref, not sure how that could be figured out.
gpellegrino: even if we have a role to a link to the ext. description using aria-details we are already linking the image to the link to the ext. description. to identify those with the ext description. and which image they extended description is defined for.
Hadrien: True in general that RS / Browser to work with info in a single document. A read-aloud feature we would extract a tree for the current document and when you ref. something in a different resource is more work but not impossible to do. The more external references the more work.
… if we expect the RS to extract info from another resource that becomes more problematic ie. read-aloud if you want it to go and get the ext. description read in-line.
AvneeshSingh: what if the ext. desc. was on the same page, and aria-details can be used on any element not just images.
Hadrien: if we want the ext description beside the image. all comes down to use-case and what should we do with the ext. description. Pop-ups are so bad, and some publishers don't put noteref footnote for this reason
gpellegrino: knowing proper tagging but in edu. setting having a sidebar containing the ext. description could be different UX implementations.
Hadrien: On blue sky I can put alt text on image, and users must include it, if I see something that the image has an alt text, and if I click on it I can see the image and display its description. Are we expecting something like this image details affordance with extended description and alt text description.
gpellegrino: tts could have some settings to announce the fact there is a ext-desc. or to read the description or not, also skipablility could also be possible.
… if the markup to do something like that is what we are trying to achieve.
Hadrien: if image has alt text and ext-desc. we could provide an indicator and provide an image details view. we could have something in verbosity in read-aloud.
… screen readers is a black box, either we hope they do the right thing, or we create a new view were we fetch the ext. desc. in the middle of the text so the SR will read the ext. desc.
AvneeshSingh: do we want to work on some kind of role, broader use case includes browsers or is this just publishing and DPUB aria role. broader ARIA role will be more challenging.
Hadrien: this seems broader than publishing.
DanielWeck: aria-details is html identifiers can target more than 1 element, what happens to reach into an <a> element
… in an example I saw one links to a <p> and the other pointing to the <a>
<gpellegrino> https://
DanielWeck: , when I hover over an image I see the outline of the image and can click on it brings up a new popoup with the image can be zoomable but add additional information displaying the alt attribute, the fig caption. and the extended description
… we could dump the entire text of the hyperlink. which is I can hit back, or use the back link you provided.
… epub type backlink has an outstanding issue.
<Hadrien> +1 to what Daniel said, which is very similar to my Bluesky example
DanielWeck: , leaning more towards fetching the nonlinear document ext. desc. and providing a different view with additional AI description.
… using the footnote popup if I have to render the HTML into a new viewport it could be a challenge.
AvneeshSingh: epubtype is deprecated, so do we need a new role. annotating the <a> hyperlink the destination is optional but useful if the Longdesc. is inside an aside then the aside should be hidden, so you don't repeat the description if they are available on demand with a popup.
gpellegrino: do you think role for enabling the UX do you think it is needed to have a role, or could with the xpath you could identifiy the links by aria-details we may end up with broken experiences.
DanielWeck: because aria-details can link to multiple reference so that could be an issue. xpath is expensive, CSS selectors better. whereever we can us a role on a target or source link is better.
Some existing best practices documents relative to EPUB extended descriptions that have to evolve after the new recommendation is settled:
- https://kb.daisy.org/publishing/docs/html/images-desc.html
- https://daisy.github.io/transitiontoepub/best-practices/extended-desc/ExtendedDescriptionsBestPractices.html
- https://apln.ca/how-to-add-extended-descriptions-in-epubs/
This was discussed during the pmwg meeting on 21 August 2025.
View the transcript
Extended Descriptions - w3c/epub-specs#2691
gpellegrino: I volunteered to work on the standardized aproach to semantically describe
… the image itself and the backlink that takes people to their original postion
… Adobe will implement extended descriptions
… this is different than alt text, extended descriptions have no standard way to make them
… we are looking for a standard way to have extended descriptions across publishers
… similar to the discussion we had about footnotes
… so RS can leverage best practices and other tools also
… we did an experiment, linked in the github issues
… uses just the tags we have with the standards and existing ARIA codes and attributesd
… I have put together a main content file with 2 images
… one figure has a caption with a link to the extended description
… for both descriptions there is an ARIA tag called aria-details
… the extended description is in the spine with the attribute "linear: no"
… in this separate file we have containers made with section elements. Within them we have the image, the desccription
… the image is hidden from screen readers
… the extended description can use tags beyond text
… in tests, we want to know if these can be programmatically identified
<gautierchomel> Gregorio's poc is available at https://
gpellegrino: so you can identify the links to extended description
… at this time we cannot identify the extended description div with a role
… we see that maybe one or two roles could help identify the links to the extended descriptions and description containers
… we are open to discussion right now
CharlesL: When we first had this discussion, the objection was that publishers didn't want an ugly link under their images
Geroge: an icon might be more palatable for publishers. So their would be a link with alt text
CharlesL: what has changed? Are publishers more receptive to this?
… or is still the clickable image link preferred?
gpellegrino: the technique we are proposing could work with icons or text links
… but the semantics behind it would be the same
wendyreid: did we do anything with the details element? Does that mess up pagination?
… any guidance for the icon must be very clear so it meets a minimum touch target size
… making the images themselves links creates other problems for RS
ivan: anything we do we should also do it in our own document
… we are talking about an HTML document, it doesn't work in our current spec to make a separate document for the extended description
… is there another solution that is plain text readable for everyone
CharlesL: regarding the visible URL under an image that you click on to get to the extended description is what publishers objected to
… the link doesn't have to be to a separate document in the spine
… this is just another HTML page that is separate
… the summary details, our previous option works well in HTML
… RS have problems with extended descriptions they can expand past the end of the current page and not be fully displayed
… RS say this would be hard to fix
gpellegrino: in EPUB we try to leave the user experience to the RS and the contetn to the EPUB
… the semantic tagging we are proposing maintains this
… so the content creator is not imposing an experience on the user
… in the first experiment, we tried having an extended description on the same page isn't simple for the publisher
… adding external files is easier so that's what we propose as the standard
George: people are asking us to tell them how to do this, and not give them options
… when we identify and icon, we should try to standardize what this icon is and what it looks like
… so it becomes known to readers that it will lead to an extended description
… we would have the semantics on this through a DPUB ARIA role
… it shouldn't take as long as it has in the past to get new DPUB ARIA roles if the community wants it
shiestyle: my colleagues tested this
… you propose to add a new feature only when people are using assitive technologies?
George: I think having the icon would be visible for everyone and would not require assistive technology
shiestyle: so the icon or the link would be visible for all?
shiestyle: is this different from footnotes?
George: these descriptions can get quite long, having them in a modal may be too long
… if you have the semantics from DPUB ARIA a reading system can put them anywhere they want
<LaurentLM> https://
LaurentLM: there are already recommendations. Having just one would help reading systems
<LaurentLM> https://
<LaurentLM> https://
LaurentLM: would we contact Daisy? APLM? and the knowledge base?
… would these 3 documents be updated by decisions made here?
… so the other options would be suppressed in this case?
George: yes
Avneesh: these techniques are specific to the EPUB world
… we need to make these because of the constraints of our environment
… we will be working on details about the visibility of links, etc. in the WG
… can the larger group focus on the reading systems
… what does the reading system need? Are new roles required only for the extended description text?
… we plan to discuss this with the APA maybe at TPAC
ivan: related to Laurent's question? What is the intention of this?
… what is the idea to give the text the maximum visibility
Avneesh: the idea is to develop best practices within the WG
… maybe a new specification on DPUB or DPUB ARIA
… this best practice will inform what specification changes we need to make
duga: looking at the examples, how do we know there is a double indirection?
… now the ARIA details are a link to something else that should be extracted
… if you go to the details, you would want to extract the extended descriptions and take the user directly there
… would reading systems know this is a double indirection?
gpellegrino: using ARIA details as an attribute may cause this issue, thinking that a RS can follow the link change without showing the user an external document
duga: the heuristic is if the ARIA details is a link you follow that link to get the details, but don't follow it if it isn't a link
George: so this role, there are two possibilities. One is an extended description reference on an anchor, so you know it is a link
… then the target is the extended description.
… in the HTML world where they may want to use the details element and linking and not taking people away from a page
… you could then put the extended description attribute in the details element.
Hadrien: thinking about the expectations. We set expectations that are different from the web
… there is probably and expectation that the user can access a detail view
… another is links, but we don't treat links the same way
… we would identify that this link is somehow different and we would display it in a different way, maybe a new view that could be dismissed
… and when I think of readaloud, what is expected from a reading system?
… mention that there is an extended description? just play the description?
… these considerations are more important than our technical solution
… i don't think we have thoroughly discussed what these expectations are
gpellegrino: and there is another expectation in the supply chain
… that tools can open an epub and understand when there is an extended description
duga: I think a role will be helpful, because by the time you get to a link you need to know it is an extended description
… in readaloud you could get the link and replace the image, does it get read aloud?
<Zakim> Avneesh, you wanted to comment on meeting with APA
without a role, you might need to figure out that an extended description link is somehow different
<gpellegrino> +1 for Brady
Avneesh: another topic, we would like to discuss this with the APA
… most of the people in the APA will be online. It is becoming challenging to arrange the meeting at TPAC
… perhaps we can arrange a virtual meeting at another time?
<CharlesL> +1 to APA meeting ahead of time 2 weeks would be good, week before harder :)
wendyreid: as long as it is OK with the APA it is no problem for us
<ivan> details' def
ivan: looking at the definition of ARIA details, list a number of roles
… is the idea here that we would add one or more roles here?
… the APA can accept or refuse them?
gpellegrino: with the plain link, we are already safe
ivan: the behavior has to be defined in some way
… looking at the details, we are hoping to add bullet items under those details
gpellegrino: yes. and if we need other roles to work with the extended description
CharlesL: in that link on the ARIA details one of the items (Example 36) is pointing to an anchor that points to an extended description
ivan: but then there are no details about what should happen
wendyreid: I may have to talk to the ARIA group about extending the details
George: we have talked about images and those are most of the cases but there may be other elements
… for instance super complex tables
ivan: sometimes complex mathematical formulas require descriptions as well
wendyreid: we will contact the APA to set up a new meeting time
ivan: maybe we can get this meeting done before TPAC but we can maintain the meeting time at TPAC
Avneesh: perhaps we can have a follow up meeting after TPAC
ivan: agreed
wendyreid: is there anything else we should be doing in the meantime?
Avneesh: we need to pinpoint our exact ask for the APA
wendyreid: this was a really good discussion, we will push the other agenda items to another time
This was discussed during the pmwg meeting on 22 August 2025.
View the transcript
Extended Descriptions in EPUB3: Issue #2691
<AvneeshSingh> w3c/
gpellegrino: we presented the proof of concept established in transition to EPUB to the maintenance WG. Two main takeaway: document usecases (readers perspectives) for semantic markup and reading systems would prefer to have a role on the extended description itself.
AvneeshSingh: usecases will be particularly important when we'll present to other groups.
George: usecases must not restrain to ebooks, and apply to web contents too. Having a `Role` will make sure things are explicit for web browser and reading systems. Also, having a pictogram or an image instead of a text link would probably make things more acceptable for content creators.
AvneeshSingh: for readers use cases, let's open an issue and start a wiki page to collect references.
gpellegrino: use cases presented in the PMWG were "as a visual reader I want to have more informations on the image", "as a listener, " there's also usecases for tools in the production chain. ACE, EPUB editors, stats and report tools, etc. As an end user I would like to list all extended descriptions in an EPUB and see which has one extended description and which one not.
gautierchomel: listing images is a real usecase we've met with the french publisher'ss association about wether or not it is of interest to reproduce list of figures present in the printed edition, implying difficulties to maintain links, while a reading system should be able to provide better listing of figures.
AvneeshSingh: the route of a new DPUB Aria implies that a description could be not only for an image, so we would need a usecase that is not about images.
gpellegrino: to me this work is part of broader work for content creator guidance. I would think about a place where we can have all those together.
AvneeshSingh: PMWG is for project management, epub-spec is about the spec. There are permissions rights to figure out there. We'll discuss with the group. For now let's start with our usual publ-a11y repository.