Task list checkboxes are rendered with no accessible name (WCAG 4.1.2, Level A)

Problem

Markdown task lists render as <input type="checkbox" disabled> with no associated label, so the checkbox has no accessible name. A screen reader announces each one as "checkbox, unchecked" with no indication of what it refers to; a sighted reader associates the checkbox with the adjacent text visually, but that association exists nowhere in the markup.

This fails WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value (Level A). axe-core reports it under the label rule with impact critical and tags wcag2a, wcag412, section508, section508.22.n, EN-301-549, EN-9.4.1.2.

It affects any book using task lists. In ours it is a setup checklist, which is precisely the content a reader most needs to work through item by item. It is also the only accessibility defect in our output that mdBook could fix without us changing the theme, and the only one of the four we hit that has no existing issue.

Steps

1. Put a task list in a chapter:

   markdown复制

   - [ ] `lake build` finishes without errors.
   - [ ] Opening a `.lean` file shows the infoview.

2. mdbook build

3. Inspect the generated HTML:

   xml复制

   <li><input disabled="" type="checkbox"> <code>lake build</code> finishes without errors.

4. Run any accessibility checker over the page, or navigate it with a screen reader.

axe-core reports, for each input: no implicit or explicit <label>, no aria-label, no aria-labelledby, no title, and default semantics not overridden with role="none" or role="presentation".

Possible Solution(s)

Two directions, either of which resolves it:

1. Give the control a name — wrap the item's content in a <label>, so the text already present becomes the accessible name. Preserves the checkbox semantics for users who benefit from them.

2. Treat it as presentational — these checkboxes are disabled and convey state visually only, so aria-hidden="true" (or role="presentation") on the input, leaving the item text to carry the meaning, is arguably the more honest markup. A non-interactive checkbox is arguably not a form control at all.

(2) is the smaller change and avoids inventing label text; (1) is better if the checkbox is meant to be perceivable as a checkbox.

Notes

Related open accessibility issues, none of which cover this: #2615 (sidebar toggle keyboard access), #2107 (bypass blocks), #1789 (code blocks). I searched issues and PRs for "checkbox", "task list", "task-list", "input label" and "unlabeled" and found no existing report.

Version

mdbook v0.5.4