Blockquotes in Screen Readers

TL;DR: This post does not assert the correct way to code blockquotes, it will only demonstrate how screen readers announce some existing patterns.

Test Details

The first four examples are lifted from WHATWG HTML’s <blockquote> entry. The next three are from W3C HTML’s 2019 <blockquote> guidance (the W3C HTML spec started redirecting to WHATWG’s version after that date).

These are not all the examples provided by either spec. I also changed the quote text so there is some consistency in announcement.

Test Page

There are no styles beyond setting the line-height and system font. Visit the pen directly or view the debug version for your own tests.

See the Pen Untitled by Adrian Roselli (@aardrian) on CodePen.

Testing Kit

I wanted to record videos for all of these, but recording, editing, captioning, and posting just take so much time. Besides, you can fire up the screen reader to which you have access and try these on your own.

I used the virtual cursor and read-all to move through the content.

• NVDA 2023.1 / Firefox 115
• JAWS 2023.2306.38 / Chrome 115
• Narrator / Windows 11 22621.1702 / Edge 115
• VoiceOver / macOS 13.4.1 / Safari 16.5.1
• Orca / Ubuntu 22.04.2 LTS / Firefox 115
• TalkBack 13.1 / Android 13 / Chrome 114
• VoiceOver / iPadOS 16.5 / Safari 16.5

I published this without Orca results, but have since rebuilt my machine. Brian Kardell also ran some Orca tests with Fedora 35 using Firefox 115 (among other browsers) and made me videos. I note the differences in announcement inline.

Test Results

In the sample output, I use “[name]” to represent “Douglas Adams”, “[title]” to represent “Mostly Harmless”, “[URL]” to represent the address of the Wikipedia page on Douglas Adams, and “[text]” to represent the full text of the quote. My intent was to allow quicker scanning for you, dear reader.

I guess you get what you pay for.

1: WHATWG, No Attribution

This is the only example with no attribution of any kind. Just thieving it like a plagiarist or ChatGPT (or Bard or any large language model).

<blockquote>
 <p>
 A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
 </p>
</blockquote>

NVDA

block quote [text] out of block quote

JAWS

block quote [text] block quote end

Narrator

[text]

macOS VoiceOver

[text]

Orca

block quote [text] leaving block quote

TalkBack

[text]

iPadOS VoiceOver

[text]

2: WHATWG, Attribution Outside

WHATWG asserts that Attribution for the quotation, if any, must be placed outside the blockquote element. This argument, however, means developers are hankering for some programmatic association and readers have to rely on context clues. The em-dash seems like an adequate clue — when it is announced (so not VoiceOver, Narrator, or TalkBack).

<blockquote>
 <p>
 A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
 </p>
</blockquote>
<p>
— Douglas Adams
</p>

NVDA

block quote [text] out of block quote em dash [name]

JAWS

block quote [text] block quote end em dash [name]

Narrator

[text] [name]

macOS VoiceOver

[text] [name]

Orca

block quote [text] leaving block quote em dash [name] (it announced the em-dash as “comma” in Brian Kardell’s video)

TalkBack

[text] [name]

iPadOS VoiceOver

[text] comma [name] (it announced the em-dash as “comma”)

3: WHATWG, Using <figure> and <figcaption>

This uses <figure> with <figcaption> for the attribution because, as WHATWG insists again, it is not part of the quote and therefore doesn’t belong inside the blockquote itself. This is the most verbose example as a result (NVDA, JAWS, Orca, and macOS VoiceOver).

<figure>
 <blockquote>
  <p>
  A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
  </p>
 </blockquote>
 <figcaption>
 Douglas Adams, in "<cite>Mostly Harmless</cite>"
 </figcaption>
</figure>

NVDA

[name], in [title] figure block quote [text] out of block quote caption [name], in [title] out of figure

JAWS

block quote has details [text] block quote end has details [name], in [title]

Narrator

[text] [name], in [title]

macOS VoiceOver

[name], in [title], figure [text] [name], in [title] quotation mark (yes, it announced only the final quotation mark)

Orca

[name] in [title] figure block quote [text] leaving block quote [name] in [title] caption leaving figure

TalkBack

[text] [name] in [title]

iPadOS VoiceOver

[text] [name] in [title]

4: WHATWG, with cite and Preceding <cite>

This WHATWG example uses the <cite> element prior to the quote with the cite attribute on the <blockquote>. Just because <cite> and cite have similar names does not mean they are associated in any way for this example.

<p>
Douglas Adams captured modern design in <cite>Mostly Harmless</cite>:
</p>
<blockquote cite="https://en.wikipedia.org/wiki/Mostly_Harmless">
 <p>
 A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
 </p>
</blockquote>

NVDA

[name] captured modern design in [title] colon block quote [text] out of block quote

JAWS

[name] captured modern design in [title] colon block quote cited from [URL] [text] block quote end

Narrator

[name] captured modern design in [title] [text]

macOS VoiceOver

[name] captured modern design in [title] [text]

Orca

[name] captured modern design in [title] block quote [text] leaving block quote

TalkBack

[name] captured modern design in [title] [text]

iPadOS VoiceOver

[name] captured modern design in [title] [text]

JAWS is the only screen reader that allowed me to navigate by block quotes. If the announcement of the URL in the cite attribute was not interesting (verbose) enough, JAWS also uses that to name the block quote (Chrome does not expose it that way):

I wanted you to hear it:

5: W3C, Using <figure> and <footer>

This W3C approach seemed novel because it uses <figure> without <figcaption>. Instead it uses <footer>. As far as WHATWG is concerned, this construct is not allowed. The test page is wrapped in <main> as this is (ideally) representative of where most blockquotes would occur. Without that, the <footer> would be considered a landmark by Chromium browsers.

<figure>
 <blockquote>
 A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
 </blockquote>
 <footer>
 — <cite>Mostly Harmless</cite> by <cite>Douglas Adams</cite>
 </footer>
</figure>

NVDA

figure block quote [text] out of block quote em dash [title] by [name] out of figure

JAWS

block quote [text] block quote end em dash [title] by [name]

Narrator

[text] [title] by [name]

macOS VoiceOver

[text] [title] by [name]

Orca

figure block quote [text] leaving blockquote em dash [title] by [name] leaving figure (it announced the em-dash as “comma” in Brian Kardell’s video)

TalkBack

[text] block quote [title] by [name]

iPadOS VoiceOver

[text] comma [title] by [name] (it announced the em-dash as “comma” here too)

6: W3C, Using Nested <cite>

A single <cite> element, within the <blockquote> and preceded by an em-dash.

<blockquote>
 A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
 — <cite><a href="https://en.wikipedia.org/wiki/Douglas_Adams">Douglas Adams</a></cite>
</blockquote>

NVDA

block quote [text] em dash link [name] out of block quote

JAWS

block quote [text] em dash Link [name] block quote end

Narrator

[text] link [name]

macOS VoiceOver

[text] link [name]

Orca

block quote [text] em dash [name] link leaving block quote (it did not announce the em-dash in Brian Kardell’s video)

TalkBack

[text] [name] link

iPadOS VoiceOver

[text] [name] link

7: W3C, Using Nested <footer>

The Nu Html Checker has no issue with this pattern, in case seeing a <footer> here makes you twitchy. The test page is wrapped in <main> as this is (ideally) representative of where most blockquotes would occur. Without that, the <footer> would be considered a landmark by Chromium browsers.

<blockquote>
 <p>
 A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
 </p>
 <footer>
 — <cite>Douglas Adams, <a href="https://en.wikipedia.org/wiki/Mostly_Harmless">Mostly Harmless</a></cite>
 </footer>
</blockquote>

NVDA

block quote [text] em dash [name], link [title] out of block quote

JAWS

block quote [text] em dash [name], Link [title] block quote end

Narrator

[text] [name] link [title]

macOS VoiceOver

[text] space [name] link [title] (yes, “space” was spoken)

Orca

block quote [text] em dash [name] [title] link leaving block quote (it announced the em-dash as “comma” in Brian Kardell’s video)

TalkBack

[text] em dash [name] [title] link

iPadOS VoiceOver

[text] [name] [title] link

For variety, here is it with desktop VoiceOver:

Verdict

I am not telling you what is the right approach. That should be a function of your audience.

On this site I use Example 7 (which I show in my 2021 post about embedding tweets). The <footer> is no more than a styling hook, since in this context the element is strictly presentational. The <cite> at least has some semantic intent behind it, even if it is not exposed to users. I use CSS generated content to insert the em-dash before the <cite>. I avoid the cite attribute completely owing to noise in JAWS.

My audience is humans, though. I am not concerned with SEO or LLM feeding, so the screen reader output is the only programmatic output I care about aside from styling. Syndication isn’t really a thing for my site.

What works for you may be different. However, I definitely recommend against using <figure> with <figcaption> (Example 3). Enough that I adjusted the advice for <blockquote> at MDN. It is unnecessarily verbose in NVDA, JAWS, Orca, and macOS VoiceOver.

This post was prompted by someone on the socials pointing out the use of quotes on Tailwind’s home page, which in turn seemed to be copied from MDN, which in turn appeared to be lifted from the WHATWG spec. Which is the overwrought code in Example 3.

Update: 14 October 2024

Heydon warned me this was coming: The blockquote element. His preferred pattern is different than mine. That’s ok.

Update: 1 November 2024

Michelle Barker followed up on Heydon’s post by noting I’ve Been Doing Blockquotes Wrong. She mostly identifies that people have different uses and expectations for what blockquotes are meant to represent. She also confirms that few people understand how it is programmatically exposed to users.

If you want to have a broader discussion of the difference between a pull-quote, a chart reference, and a tangential note and how to represent each, then check my post ARIA `note`. If nothing else, it demonstrates that people are driven to bring print paradigms to the web (for good and bad).