[chanellebingham]

Description

In a default listing, a post with no preview image gets an empty thumbnail link. item-default.ejs.md wraps the thumbnail of every item in <a href="…" class="no-external">, and when the post has no image and the listing sets no image-placeholder, emptyDiv() in website-listing-read.ts fills that link with <div class="listing-item-img-placeholder">&nbsp;</div>. The link has no accessible name but is still a Tab stop, so keyboard and screen reader users meet one unnamed link per post before its title link. axe-core reports it as link-name.

The template only knows about an image the post declares in its front matter (image). Otherwise it emits a placeholder comment, and completeListingItems() resolves it once the post has been rendered: a preview image found in the rendered page (.preview-image, a feature/cover/thumbnail image, or the first local image), the listing's image-placeholder, or the empty div. So the fix sits at that last step. When the placeholder becomes the empty div and sits directly inside a link, the link gets aria-hidden="true" and tabindex="-1". Its other attributes are kept and the markup is otherwise unchanged, so the layout stays the same and links that do show an image are not touched. The title link next to the thumbnail goes to the same page.

Before:

<div class="thumbnail"><a href="./posts/no-image/index.html" class="no-external">

<div class="listing-item-img-placeholder card-img-top" >&nbsp;</div>

</a></div>

After:

<div class="thumbnail"><a href="./posts/no-image/index.html" class="no-external" aria-hidden="true" tabindex="-1">

<div class="listing-item-img-placeholder card-img-top" >&nbsp;</div>

</a></div>

I hid the link rather than removing it because that keeps the DOM identical for CSS and custom templates, and it is one of the two outcomes the issue asks for. A custom template that puts the placeholder inside a link next to other content is left alone, since that link has content of its own.

The new smoke test renders a default listing with three posts (image in the front matter, image found in the rendered body, no image), once without image-placeholder (index.qmd) and once with it (placeholder.qmd). On main it fails with Required DOM Element div.thumbnail a[aria-hidden="true"][tabindex="-1"] div.listing-item-img-placeholder is missing; with this change it passes.

Run on Windows 11 with the dev build (configure.cmd):

.\run-tests.ps1 smoke/site/render-listing-thumbnail-link.test.ts
ok | 1 passed | 0 failed (3s)

.\run-tests.ps1 --agent smoke/site/render-listings.test.ts smoke/site/render-listing-contents-file.test.ts smoke/site/render-listing-feed-image.test.ts smoke/site/render-blog.test.ts smoke/site/render-listing-thumbnail-link.test.ts
ok | 7 passed | 0 failed (39s)

The smoke-all listing documents under listings/image-lazy-loading/blog/, 2026/10/12/issue-15022, 2024/10/23/issue-10829, 2024/12/03/issue-11580, 2025/04/01/issue-8238 and website/llms-txt-listing pass as well (11 passed). 2024/10/28/issue-10311 fails on this machine with and without the change because its posts need a Python kernel that is not set up here.

axe-core 4.14 on the rendered index.html: the link-name finding on .thumbnail > .no-external[href="./posts/no-image/index.html"] is gone, and no aria-hidden-focus finding appears. The link-name and image-alt findings that remain on thumbnails that do show an image come from those <img> having no alt, which is #15038 / #7028 and not changed here.

The axe-core check ran in headless Chromium (Playwright's chromium_headless_shell), not with a screen reader. deno fmt --check on website-listing-read.ts flags lines 18–21 (an import block); that complaint exists on main unchanged and I left it alone. The added code is fmt-clean and deno lint passes.

Open questions

1. Hide vs remove: the issue accepts either. Hiding keeps the DOM identical; removing the <a> would be a small change in the same helper if you prefer no link at all.
2. The helper hides any link that wraps only the placeholder, so a table listing with field-links: [image] gets the same treatment. The default table listing uses a <span>, so default output is unchanged. Fine, or should it be limited to the default template?
3. The thumbnails that do show an image still have no alt (a11y: quarto create project blog scaffold has images with no alt text and icon-only navbar links with no name #15038, Add support for alt (and maybe title) for placeholder-image in listings #7028). Left untouched on purpose; happy to follow up separately.

Fixes #15066

Checklist

I have (if applicable):

• referenced the GitHub issue this PR closes
• updated the appropriate changelog in the PR
• ensured the present test suite passes (ran the listing, blog and smoke-all listing tests listed above; the full suite needs R, Python and Julia which I have not set up)
• added new tests
• created a separate documentation PR in Quarto's website repo and linked it to this PR (not applicable: no documented behaviour changes)

AI-assisted PR

• AI tool used: Claude Code
• Codebase grounding: local clone
• Human review: I have reviewed, tested, and verified the AI-generated content before submitting.

Note: autonomous AI agents submitting PRs without human oversight are not permitted — see the Code of Conduct.

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[chanellebingham]

Merged main to resolve a conflict in news/changelog-1.11.md: main's #15080 entry landed in the same spot as this one, so I kept both, in issue-number order. No other changes.

[cderv]

Thanks for the PR. The new test fails on main with the assertion you quote and passes with the change, and the other listing tests still pass.

About your questions:

1. Hiding is fine. The empty thumbnail stays a mouse target like the ones showing an image, and the markup does not change for themes and custom templates.
2. Fine as is. With a table listing using field-links: [image, title], the empty image link is hidden and the title link stays reachable. The only case where it matters is field-links: [image] without any other linked field, where the hidden link was the only link to the post. That one was already not usable before (link without a name), so I don't think it is worth special casing here.
3. Yes, separately. #15038 and #7028 already track it.

There is a new conflict in news/changelog-1.11.md with main. No need to push anything, we'll merge main on the branch before merging.