14 Accessibility conformance report
An honest WCAG 2.1 AA conformance report for the HTML Taliesin generates: what it supports, what it partially supports, and what has not been evaluated.
Reference: Cheat sheet · CLI · Configuration · Cell options · Troubleshooting · Accessibility · Licensing
This is an Accessibility Conformance Report (the ACR half of a VPAT) for the HTML Taliesin produces. It exists because “is it accessible?” is a procurement question as often as an engineering one: the ADA Title II rule requires WCAG 2.1 AA of public institutions, and accessibility documentation is routinely used to screen tools before anyone installs them. If you are evaluating Taliesin for a university or a public body, this page is meant to be the document you need.
An inflated report is worse than none, so the “not evaluated” list below is as much the deliverable as the table. Nothing here is claimed on the strength of an intention.
14.1 Scope
Product: the HTML output of taliesin build, audited at 0.2.0.
Standard: WCAG 2.1 Level AA.
Report date: 2026-07-28.
Read it as a report on the version it names: the current release is 1.0.0, the palette and the chrome have both changed since the report date, and the table has not been re-run.
Evaluation methods. Automated conformance testing (Lighthouse, which embeds axe-core)
over built output: 54 pages across three projects as they stood at the report date,
desktop and mobile, in both the light and dark themes. Plus the project’s own static
rule set (crates/core/src/diagnostics/a11y.rs) and a manual audit pass on 2026-07-25.
What this covers, precisely. It evaluates the chrome and layout Taliesin
generates: the navigation, the search palette, the chapters drawer, the theme
palettes, the page scaffolding. It cannot evaluate what you write. Alt text, heading
order, link text and media captions are the author’s responsibility; Taliesin lints for
two of them (a missing or placeholder alt, and a heading-level skip) on every build and
through build --check-only, but a linter cannot guarantee an author wrote a good
description.
14.2 Conformance table
| Criterion | Conformance | Remarks |
|---|---|---|
| 1.1.1 Non-text Content | Partially supports | Tool chrome supplies an accessible name for every control it emits. Author images are linted for a missing or placeholder alt but cannot be enforced |
| 1.3.1 Info and Relationships | Supports | Semantic landmarks, <section> extents and a real heading hierarchy; verified across those 54 pages |
| 1.4.3 Contrast (Minimum) | Supports | Zero contrast violations in both themes, desktop and mobile |
| 1.4.10 Reflow | Supports | No horizontal overflow at mobile widths (measured 2026-07-26) |
| 1.4.11 Non-text Contrast | Supports | No violations |
| 2.1.1 Keyboard | Partially supports | The skip link and the Cmd-K palette are keyboard-first and pinned by tests, but a full keyboard walkthrough of every surface has not been run |
| 2.4.2 Page Titled | Supports | Titles compose as "{page} · {site}", page name first |
| 2.4.4 Link Purpose | Supports | No violations. The static ambiguous-link-text lint was cut on 2026-08-08 (it named something an author reads back in the preview), so this rests on the audit rather than on a linter |
| 2.4.6 Headings and Labels | Supports | Clean; heading-skip is linted on every page |
| 2.5.3 Label in Name | Supports | The search control’s visible ⌘K hint is aria-hidden, so it is not part of the accessible name |
| 3.1.1 Language of Page | Supports | Every page builder emits <html lang="en">, from one constant that no front matter can override |
| 4.1.2 Name, Role, Value | Supports | Clean on every audited page |
14.3 Not evaluated
Listing these is the point of the format. None of the following is a claim of failure; each is an absence of evidence.
- No screen-reader pass. No NVDA, VoiceOver or TalkBack testing has been done. Automated tooling detects roughly a third of real barriers, so every “Supports” above rests on a partial instrument.
- No keyboard walkthrough, which is why 2.1.1 is “partially supports” and why 2.4.3 (Focus Order) and 2.4.7 (Focus Visible) appear nowhere in the table.
- No standalone axe-core run. Lighthouse runs a weighted subset, and that weighting has demonstrably hidden a real defect here before.
- 1.2.x (time-based media), 3.2.x and 3.3.x were not assessed.
- The live preview was not audited, only built output. The preview is a development surface, not a published one.
14.4 Reader controls
Independent of the table above, two aspects of the reading experience follow a preference the reader already set on their own device, rather than anything the page or its author configures:
- Theme. The page is lit by the reader’s device, and there is no control on the page itself: a system set to dark renders the page dark, a system set to light renders it light, and changing that system setting mid-read changes the page live. Both palettes ship inside every page and one is selected before the page paints, so there is no flash of the wrong theme and no round trip. A per-page theme picker shipped for a while and was removed: the reader had already answered the question once, in their operating system, and a picker asked them to answer it a second time, then risked disagreeing with the rest of their screen.
prefers-reduced-motionis honoured for every animation and for JavaScript-initiated scrolling, not only for CSS transitions.
There is deliberately no text-size, line-spacing, or focus-mode control: the browser’s own zoom and reading tools already cover that ground.
14.5 Keyboard access
Tab from the top of any page reveals a Skip to content link that jumps focus past
the chrome straight to the prose. The link and its focusable <main> target are
emitted server-side, so they work even with JavaScript disabled. A few keyboard
interactions speed up reading (each is ignored while you are typing in a field or a
dialog is open):
- Cmd/Ctrl-K opens the search palette.
←/→move to the previous / next chapter (in a book).Esccloses the open menu, dialog, or palette.
None of these is a character-key shortcut (a single key fired with no modifier), so WCAG 2.1.4’s requirement to make character-key shortcuts switchable off does not apply, and no off-switch is owed.
Keyboard focus is always visible: every interactive control shares one consistent focus ring, shown only for keyboard or assistive-technology focus and never on a mouse click. The ring is a single theme token, so it follows the active palette, including the high-contrast modes below.
Landmarks and dialogs. Each <nav> on a page carries a distinguishing accessible
name (the table of contents announces as “Table of contents”, separate from the
navbar and the prev/next pager), so a screen reader’s landmark list is navigable.
The one modal overlay, the search palette, moves focus into itself on open, traps
Tab while open, and restores focus to whatever opened it on close.
High contrast. In Windows High Contrast / forced-colors mode, and under
prefers-contrast: more, borders, focus rings, separators, and the active-item
markers are re-asserted with system colors so the chrome stays legible when the
palette is forced.
14.6 Reporting a barrier
If you hit an accessibility barrier, it is a bug and it is wanted. Please open an issue describing the surface, your assistive technology and what you expected. A report against a real screen reader is especially valuable, since that is the largest measured gap above.