Repository navigation
[BLOCKED] doc-pullquote should be exposed as repeated content; not hidden #16
Description
A user might wish to know that a pullquote is present in the document -- even if it is just repeated for visual effect. But https://w3c.github.io/dpub-aria/#example-39 makes that impossible because it uses aria-hidden="true". Hidden content is typically pruned from the accessibility tree.
If there were an ARIA property which allowed authors to mark something as "repeated content" then a screen reader could have an option to hide/show repeated content. Then users who don't want to read the duplicated content would get the same result as aria-hidden="true". But users who do want that repeated content presented would be able to.
I've marked this as "BLOCKED" because ARIA currently has no such feature. But that might change. See w3c/aria#1044.
Activity
mattgarrish commentedon Jul 24, 2020
I see this is marked with the ARIA 1.3 milestone, so not something we can address in this revision.
Would it make sense to add a note that such an attribute is under discussion and may be available in the future, or is that too speculative at this point?
mattgarrish commentedon Jul 5, 2022
It looks like w3c/aria#1044 was closed without providing any help for this issue.
Hiding pullquotes is a pretty awful experience. When there's no way to cycle through the pullquotes, it leaves AT users without the same ability to read the quotes and see if they're interested in reading an article. They aren't duplicate visual emphasis but a key enticement to read.
Any idea what else we could try for this @joanmarie ?
pkra commentedon Jul 6, 2022
I think the discussion around w3c/aria#1746 might be useful, in particular the wai-cc discussion linked to at w3c/aria#1746 (comment). That is, this seems like something that a user might want to control via some form of verbosity setting in their AT.
mattgarrish commentedon Jul 6, 2022
@GeorgeKerscher has been doing some research into this, and the consensus he's been finding is that AT users do not care to hear pullquotes where they happen to be marked up in the content. Like visual readers, the pullquote is meant to entice you to read. When you're actually reading you don't want to hear the redundancy.
But maybe selectively enabling their playback would work, as for most users the option would be to disable. It at least wouldn't make the pullquotes invisible to AT, so while playback in the linear reading order would be disabled, it would still be possible to offer users the ability to cycle through them.
pkra commentedon Jul 7, 2026
I stumbled upon this again today. I find the spec language confusing.
The definition currently states:
This makes it sound like a pullquote is (only viable for) a direct repetition - and in that case, it must be hidden. Then why is a role needed?
Next the first example is preceded by the following text:
So the role is used on the source of a pullquote, not the actual (duplicating) pullquote. That makes it seem like the only valid use case is marking up the source of a pullquote, rather than the pullquote itself (which is then presumably aria-hidden, so again the role doesn't matter). That seems very odd to me.
Furthermore, I think pullquotes are frequently not a direct repetition but a slightly edited version to work out of context and to grab the readers attention. So the argument to avoid repetition does not hold up particularly well.
Besides, why wouldn't an author want AT users to know there's a pullquote? What if they have a conversation with a non-AT user who points out this (usually prominently designed) piece of content? It seems like a WCAG failure to hide it.
Aside: perhaps the superclass should be changed to
blockquote(which I'm guessing wasn't around when pullquote was originally written.)mattgarrish commentedon Jul 7, 2026
The idea behind the role is that it offers quick access to the pullquotes the same way a visual reader can quickly skim over the enlarged quotes to see if they're of any interest. It's to enable that kind of feature.
When reading the article, the user doesn't typically care to know what text is being used as a pullquote or at what random location the pullquote markup was injected. It's not relevant to the reading experience.
That's been the problem in finding a suitable approach to the role. You don't normally want the role announced where the text is tagged inline, and in the cases of duplication you don't normally want the repetitions read out, but you typically will always want to have the quotes compiled and made iterable.
I don't know how we can make all that work, though, as if users can selectively disable reading of the quotes then they can end up turning off the text in the body of the article. It makes me think we shouldn't be accommodating inline tagging of pullquotes but only identifying the instances where the quote is reproduced. If you want to use a script to generate the pullquote from the body text, then how you identify the text to select should be the publisher's problem (data-*, class, etc.). I'd actually be surprised if any publishers dynamically generate their pullquotes, certainly in epub given it's poor support for scripting.
GeorgeKerscher commentedon Jul 7, 2026
In the Transition to accessible EPUB - DAISY working group, we are making suggestions to screen reader developers on the presentation of DPUB ARIA attributes. for the pullquote we have:
doc-pullquote Test
This text has the role of pullquote.
This is a medium priority. Many times an extracted quote is emphasized by taking portions of text and repeating it in the margin or pulled to the side. It should be vocalized when the document semantic verbosity is set to most or all.
Suggested output: "extracted quote"
We are reviewing these recommendations and hope to finalize our guidance. If you find any problems with this guidance, leave a comment.
mattgarrish commentedon Jul 7, 2026
George do you recall why we tried to accommodate tagging the text in the content that represents the pullquote? I'm thinking it didn't come from the epub group because scripting pullquotes doesn't seem like anything publishers would bother trying to make work in the mostly static world of ebooks. It seems like a problematic thing to do even for a web page.
If we drop the inline case and focus on tagging the duplicate text that is the actual pullquote, I don't think we'd need any special type of superclass role and we could drop the stuff about having the author hide the text.
GeorgeKerscher commentedon Jul 7, 2026
When James from Tayler and Francesis talked about what they do, He said they put it in the margin as ttext. There is no scripting. It is just here to emphasise an item. Of course, this is seen in magazines more than anywhere else.
I think the hidden approach because people do not want things repeated is inappropriate here; it is just a way to emphasise.
pkra commentedon Jul 8, 2026
@mattgarrish I've put it on the agenda for today's editors call. Will you be able to join?
mattgarrish commentedon Jul 8, 2026
Sorry, no, I can't make it today (dental appt) and then I'm off for the next few weeks. But if there's no issue with taking out the inline usage and aria-hidden stuff, I'm happy to put together an update. I assume we'd have to do the whole proposed corrections/updated REC thing, though?
daniel-montalvo commentedon Jul 8, 2026
Thanks @mattgarrish and all.
Yes we should do the proposed correction process.
Happy to review this PR and add the appropriate markup
pkra commentedon Jul 9, 2026
@mattgarrish
This doesn't make sense to me for pullquotes. Do you mean the quote sources?
As I wrote, I would question that AT users generally don't want or need to know about pullquotes.
Maybe a role is not the right tool for this. (Though I don't understand how AT users would disable reading pullquotes.)
👍 Should we add this issue to the WG agenda (when you're available)?
mattgarrish commentedon Jul 9, 2026
Pullquotes are mix of marketing material and visual design. Their purpose is to draw sighted readers into reading an article. Users almost always access them before reading the article, or when flipping pages, not while trying to read the article itself. They're often redundant by that time, and in any case their purpose is lost as you've already been required to read. Maybe someone wants quick access to source quotes, too, but they serve an entirely different purpose.
The problem is with the placement of pullquotes and when you want to read them, not whether users should have access to them. Their placement is for display and is normally done by the publisher not the author. It's not like a quote from another source that is directly related to the text that comes before and after it. A pullquote could come immediately after the exact text it's replicating, in which case it's noise, or it could come well before the text, in which it's out-of-context noise. Without a role what's a person supposed to make of this noise, though?
But I don't know that we need to keep debating all that. What I'd propose we do is:
I wouldn't change the superclass role to blockquote as a blockquote is always from another source and pullquote is always from the same source. There could be a related generic quote parent for both of them, but one's not a derivation of the other.
daniel-montalvo commentedon Jul 22, 2026
Hi @pkra and @mattgarrish
It seems this deserves a synchronous discussion at some point.
@mattgarrish Can you tell which of these ARIA meetings you could attend so that we can schedule this for discussion? Currently the WG pages are giving a 503, but this will be fixed later.