I have:
Bug description
A bare {{< placeholder >}} in an HTML document produces an <img> element with no alt attribute. The output fails WCAG 2.0 A, SC 1.1.1 (Non-text Content). The axe rule image-alt reports it as a critical violation.
The attribute is absent, not empty. This difference is important. alt="" is valid HTML. It marks an image as decorative, and it passes image-alt. A missing attribute fails the rule.
The shortcode builds the image with pandoc.Image({}, result). The first argument holds the caption inlines, and it is always empty. No alt attribute reaches the output.
|
if context == "text" then |
|
return result |
|
else |
|
return pandoc.Image({}, result) |
|
end |
An author can add alt text today with markdown image syntax and the fig-alt attribute:
{fig-alt="Placeholder image"}
This affects quarto.org
An audit of quarto.org with axe found two of these images on docs/authoring/placeholder.qmd. Both are critical image-alt violations.
That page documents this shortcode, so the fig-alt workaround above is not available there. The workaround changes the examples, and the examples are what the page teaches.
Steps to reproduce
---
title: Placeholder
format: html
---
{{< placeholder 400 200 >}}
Render the document to HTML. Then read the alt attribute of the <img> element.
Actual behavior
The <img> element has no alt attribute:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSU…" class="img-fluid">
Expected behavior
The shortcode writes a default alt string when the author gives none.
The shortcode already knows the width and the height. It also draws both values into the image as text:
local size_str = tostring(width) .. " x " .. tostring(height)
A default such as alt="Placeholder image, 400 by 200" therefore needs no change from the author. Every existing {{< placeholder >}} then passes the rule.
An empty alt="" also passes image-alt. A descriptive default is better here, for two reasons. First, the image contains text, and an empty alt states that the image conveys nothing. Second, the pages that use this shortcode use it to demonstrate a size or a layout. An empty alt maps the image to the presentation role, so assistive technology does not announce it. A screen reader user then loses the demonstration.
Your environment
- Positron 1.124.0
- macOS 26.5.2 (build 25F84)
Quarto check output
Quarto 1.10.18
[✓] Checking environment information...
Quarto cache location: /Users/charlottewickham/Library/Caches/quarto
[✓] Checking versions of quarto binary dependencies...
Pandoc version 3.10.0: OK
Dart Sass version 1.101.0: OK
Deno version 2.7.14: OK
Typst version 0.15.1: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
Version: 1.10.18
Path: /Applications/quarto/bin
[✓] Checking tools....................OK
TinyTeX: v2026.04
Chrome Headless Shell: 150.0.7871.115
VeraPDF: 1.28.2
[✓] Checking LaTeX....................OK
Using: TinyTex
Path: /Users/charlottewickham/Library/TinyTeX/bin/universal-darwin
Version: 2026
[✓] Checking Chrome Headless....................OK
Using: Chrome Headless Shell installed by Quarto
Path: /Users/charlottewickham/Library/Application Support/quarto/chrome-headless-shell/chrome-headless-shell-mac-arm64/chrome-headless-shell
Version: 150.0.7871.115
[✓] Checking basic markdown render....OK
[✓] Checking R installation...........OK
Version: 4.6.0
Path: /Library/Frameworks/R.framework/Versions/4.6/Resources
LibPaths:
- /Users/charlottewickham/Library/R/arm64/4.6/library
- /Library/Frameworks/R.framework/Versions/4.6/Resources/library
knitr: 1.51
rmarkdown: 2.31
[✓] Checking Knitr engine render......OK
[✓] Checking Python 3 installation....OK
Version: 3.12.2
Path: /Users/charlottewickham/.pyenv/versions/3.12.2/bin/python3
Jupyter: 5.9.1
Kernels: python3
[✓] Checking Jupyter engine render....OK
[✓] Checking Julia installation...
AI helped investigate this issue, grounded in a local clone of quarto-cli (see CONTRIBUTING.md, "Using AI tools to investigate").
I have:
Bug description
A bare
{{< placeholder >}}in an HTML document produces an<img>element with noaltattribute. The output fails WCAG 2.0 A, SC 1.1.1 (Non-text Content). The axe ruleimage-altreports it as a critical violation.The attribute is absent, not empty. This difference is important.
alt=""is valid HTML. It marks an image as decorative, and it passesimage-alt. A missing attribute fails the rule.The shortcode builds the image with
pandoc.Image({}, result). The first argument holds the caption inlines, and it is always empty. Noaltattribute reaches the output.quarto-cli/src/resources/extensions/quarto/placeholder/placeholder.lua
Lines 57 to 61 in abc6a78
An author can add alt text today with markdown image syntax and the
fig-altattribute:This affects quarto.org
An audit of quarto.org with axe found two of these images on
docs/authoring/placeholder.qmd. Both are criticalimage-altviolations.That page documents this shortcode, so the
fig-altworkaround above is not available there. The workaround changes the examples, and the examples are what the page teaches.Steps to reproduce
Render the document to HTML. Then read the
altattribute of the<img>element.Actual behavior
The
<img>element has noaltattribute:Expected behavior
The shortcode writes a default
altstring when the author gives none.The shortcode already knows the width and the height. It also draws both values into the image as text:
A default such as
alt="Placeholder image, 400 by 200"therefore needs no change from the author. Every existing{{< placeholder >}}then passes the rule.An empty
alt=""also passesimage-alt. A descriptive default is better here, for two reasons. First, the image contains text, and an emptyaltstates that the image conveys nothing. Second, the pages that use this shortcode use it to demonstrate a size or a layout. An emptyaltmaps the image to thepresentationrole, so assistive technology does not announce it. A screen reader user then loses the demonstration.Your environment
Quarto check output
Quarto 1.10.18 [✓] Checking environment information... Quarto cache location: /Users/charlottewickham/Library/Caches/quarto [✓] Checking versions of quarto binary dependencies... Pandoc version 3.10.0: OK Dart Sass version 1.101.0: OK Deno version 2.7.14: OK Typst version 0.15.1: OK [✓] Checking versions of quarto dependencies......OK [✓] Checking Quarto installation......OK Version: 1.10.18 Path: /Applications/quarto/bin [✓] Checking tools....................OK TinyTeX: v2026.04 Chrome Headless Shell: 150.0.7871.115 VeraPDF: 1.28.2 [✓] Checking LaTeX....................OK Using: TinyTex Path: /Users/charlottewickham/Library/TinyTeX/bin/universal-darwin Version: 2026 [✓] Checking Chrome Headless....................OK Using: Chrome Headless Shell installed by Quarto Path: /Users/charlottewickham/Library/Application Support/quarto/chrome-headless-shell/chrome-headless-shell-mac-arm64/chrome-headless-shell Version: 150.0.7871.115 [✓] Checking basic markdown render....OK [✓] Checking R installation...........OK Version: 4.6.0 Path: /Library/Frameworks/R.framework/Versions/4.6/Resources LibPaths: - /Users/charlottewickham/Library/R/arm64/4.6/library - /Library/Frameworks/R.framework/Versions/4.6/Resources/library knitr: 1.51 rmarkdown: 2.31 [✓] Checking Knitr engine render......OK [✓] Checking Python 3 installation....OK Version: 3.12.2 Path: /Users/charlottewickham/.pyenv/versions/3.12.2/bin/python3 Jupyter: 5.9.1 Kernels: python3 [✓] Checking Jupyter engine render....OK [✓] Checking Julia installation...AI helped investigate this issue, grounded in a local clone of quarto-cli (see CONTRIBUTING.md, "Using AI tools to investigate").