Can Eleventy enforce heading hierarchy and required alt text without custom plugins?
0 reputation · 20 Dec 2024, 14:09 UTC
0 reputation · 20 Dec 2024, 14:09 UTC
Improving accessibility in the Eleventy authoring workflow requires reliable checks for document outline and image alt text without relying on manual review.
Eleventy core does not validate heading hierarchy across template includes or layouts, and template languages allow arbitrary heading levels in partials. The official eleventy-img plugin generates responsive markup but does not auto-populate alt attributes; authors must supply alt text via front matter or data. No built-in accessibility linting runs during eleventy --serve or production builds, and the dev server has no integration with axe-core or Lighthouse CI. Incremental builds can skip re-rendering included partials when only data changes.
Does Eleventy provide a documented build-time mechanism to validate heading hierarchy for WCAG 1.3.1 compliance? Which configuration, if any, makes alt text required when using eleventy-img? When does an incremental build guarantee updated heading structures in the output?
35275 reputation · 20 Dec 2024, 19:02 UTC
No. Eleventy core does not validate heading hierarchy, does not require alt attributes when using eleventy-img, and incremental builds do not guarantee updated heading structures when only data files change. All three checks require custom transforms or external tooling.
Eleventy treats templates, layouts, and includes as plain text until they are rendered. There is no build-time pass that parses the combined HTML output and verifies that heading levels (h1–h6) follow a logical outline. A partial included in multiple pages can contain an h2 while the parent page uses an h3, and Eleventy will emit both without warning during eleventy --serve or a production build.
The official @11ty/eleventy-img plugin generates responsive <picture> and <img> markup but does not auto-populate the alt attribute. Authors must supply alt text via front matter, data files, or the plugin’s options object. If the alt property is omitted, the build succeeds and the emitted <img> tag simply lacks an alt attribute (or receives an empty one depending on configuration). No core configuration flag makes alt text mandatory.
Eleventy’s watch/incremental mode re-renders a template only when that template’s source file changes. If a heading lives in an included partial or is driven by a data file, editing the partial or the data alone will not trigger re-render of the consuming pages. The output heading structure remains stale until a full eleventy rebuild runs.
eleventy-img that validates the alt option before calling the plugin, throwing on missing or empty values._site folder as a separate CI step.h2 in a partial and a page that uses an h3; run eleventy --serve — no warning appears.eleventy-img without providing alt; build succeeds, output lacks alt.Assumes Eleventy 2.x/3.x. Behavior may differ in future major versions.
Are you using a templating language (Nunjucks, Liquid, 11ty.js) that allows you to write a transform in JavaScript, or do you need a solution that works purely through configuration?
Use comments to ask for clarification. Post a solution as an answer.
6,550 reputation · 20 Dec 2024, 14:27 UTC
A transform is the right place for this because it runs after Eleventy has resolved includes and layouts, so it sees the final heading outline rather than individual partials. In Eleventy v2.x or later, eleventyConfig.addTransform receives the rendered HTML string; you can parse it with a DOM library and fail the build when an img lacks non-empty alt or when heading levels skip more than one step. This only covers server-rendered output, not content generated client-side. Practical check: add a temporary transform that logs violations, run eleventy --clean, then compare against eleventy --serve after editing only a shared data file to confirm incremental builds do not rewrite dependent pages.