14 Accessibility conformance report
A 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 accessibility 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.
The “not evaluated” list below is as much a part of the report as the table. No claim here rests on intent.
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: it predates the 1.0.0 release, 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. Also: 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. 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 | Heading-skip is linted on every page. At the report date, listing pages paired the page <h1> with <h3> card titles, a skip inside the one listing block that the lint cannot see; card titles emit as <h2> since 2026-09-01 |
| 2.5.3 Label in Name | Supports | The 2026-07-28 audit recorded this as failing (visible “Ctrl K”, accessible name “Search”), and aria-hidden on the hint never satisfied 2.5.3, which is about visible text. Fixed 2026-09-01: the accessible name now contains the visible shortcut hint on every platform (“Search: ⌘K”, resynced to “Search: Ctrl K” where the hint is rewritten) |
| 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
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 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, neither the page nor its author configures the theme or motion. Both follow preferences the reader already set on their own device:
- Theme. The page follows the reader’s system setting and has no theme control of its own: 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: it asked the reader again for a preference already set in their operating system, and could disagree with the rest of their screen.
prefers-reduced-motionis honoured for every animation and for JavaScript-initiated scrolling, not only for CSS transitions. The exceptions are the highlight on a search hit and, in the preview, the outline on the block a click-to-source lands on: each is a colour fade rather than motion, and collapsing it would leave the target unmarked.
Taliesin ships no text-size, line-spacing, or focus-mode control, because the browser’s own zoom and reading tools already provide them.
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.
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
An accessibility barrier is a bug. 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 no screen-reader testing has been done (see Not evaluated).