What “targets WCAG 2.2 AAA” means here
The word targets is deliberate. This page says precisely what is verified, by what, what is not verified by anything, and what we intend to do about the gap. Lily never claims WCAG “compliance” — no audit supports it.
Verified, continuously
- Every component's canonical semantic element, ARIA attributes, and class hooks — asserted by per-framework unit suites (15,000+ cases across seven frameworks).
- Every one of the 571 component demo pages in the SvelteKit example app is axe-clean (WCAG 2.0/2.1 A+AA and 2.2 AA rule sets) — the full-catalog sweep, first baselined 2026-08-27 and re-run 2026-10-06 — plus per-app baselines on home, catalog, and composed routes in all seven example apps.
- Keyboard contracts per interactive component, documented in each component's canonical metadata and exercised by the suites; the five helper packages additionally run real-browser Playwright specs.
- WCAG 2.2 target-size floors and overflow guards in all 45 themes;
skip-link, landmarks, and no horizontal overflow at four viewports per
app;
lang/dirapplication including the RTL flip.
Not verified by anything
- No conformance audit has ever been performed. No VPAT, no certification. Automated tooling covers a minority of WCAG success criteria.
- AAA-specific criteria (enhanced contrast, and others) are design intents, not verified properties; the axe rule sets run A/AA. There is no dedicated high-contrast theme yet.
- Screen-reader behaviour is largely untested. The suites assert ARIA attributes, not what VoiceOver, NVDA, or JAWS announce — and this project has shipped green suites over real defects more than once, each written up in the changelog precisely because the suites could not see them.
What we intend to do about it
An independent accessibility audit is the first named use of any project funding, and the scope an auditor needs is already prepared. Until then, screen-reader reports are the contribution this project wants most: “component X announces Y, which is wrong because Z” is directly actionable.
Report a problem
Open an issue at github.com/LilyDesignSystem/lily-design-system or email joel@joelparkerhenderson.com. Naming a WCAG criterion helps but is not required — “I couldn't operate X with the keyboard” is a complete report.
The full statement, with the verification table and its review history, lives in the repository: docs/accessibility-statement.md.