Was „zielt auf WCAG 2.2 AAA” hier bedeutet
Das Wort zielt ist bewusst gewählt. Diese Seite sagt genau, was verifiziert wird, womit, was von nichts verifiziert wird und was wir gegen die Lücke tun wollen. Lily behauptet nie WCAG-„Konformität” – kein Audit belegt sie.
Laufend verifiziert
- Das kanonische semantische Element, die ARIA-Attribute und die Klassen-Hooks jeder Komponente – abgesichert durch Unit-Test-Suiten je Framework (über 15.000 Fälle in sieben Frameworks).
- Jede der 571 Komponenten-Demoseiten in der SvelteKit-Beispiel-App ist axe-sauber (Regelsätze WCAG 2.0/2.1 A+AA und 2.2 AA) – der Durchlauf über den gesamten Katalog, erstmals am 2026-08-27 als Baseline erfasst und am 2026-10-06 erneut ausgeführt – plus Baselines je App für Startseite, Katalog und zusammengesetzte Routen in allen sieben Beispiel-Apps.
- Tastaturverträge je interaktiver Komponente, dokumentiert in den kanonischen Metadaten jeder Komponente und von den Suiten geprüft; die Helferpakete führen zusätzlich Playwright-Specs in echten Browsern aus.
-
Untergrenzen für Zielgrößen nach WCAG 2.2 und Überlaufschutz in allen 57 Themes; Sprunglink, Landmarken und kein horizontaler Überlauf bei vier Viewports je App;
lang/dir-Anwendung einschließlich der RTL-Umkehrung.
Von nichts verifiziert
- Es wurde nie ein Konformitätsaudit durchgeführt. Kein VPAT, keine Zertifizierung. Automatisierte Werkzeuge decken nur eine Minderheit der WCAG-Erfolgskriterien ab.
- AAA-spezifische Kriterien (erhöhter Kontrast und andere) sind Gestaltungsabsichten, keine verifizierten Eigenschaften; die axe-Regelsätze laufen für A/AA. Ein eigenes Hochkontrast-Theme gibt es noch nicht.
- Das Verhalten von Screenreadern ist weitgehend ungetestet. Die Suiten prüfen ARIA-Attribute, nicht was VoiceOver, NVDA oder JAWS ansagen – und dieses Projekt hat mehr als einmal grüne Suiten über echten Mängeln ausgeliefert, jeweils im Changelog festgehalten, gerade weil die Suiten sie nicht sehen konnten.
Was wir dagegen tun wollen
Ein unabhängiges Barrierefreiheitsaudit ist die erste genannte Verwendung jeder Projektfinanzierung, und der Umfang, den ein Prüfer braucht, ist bereits vorbereitet. Bis dahin sind Screenreader-Berichte der Beitrag, den sich dieses Projekt am meisten wünscht: „Komponente X sagt Y an, was falsch ist, weil Z” ist unmittelbar umsetzbar.
Ein Problem melden
Eröffnen Sie ein Issue auf github.com/LilyDesignSystem/lily-design-system oder schreiben Sie an joel@joelparkerhenderson.com. Ein WCAG-Kriterium zu nennen hilft, ist aber nicht erforderlich – „Ich konnte X nicht mit der Tastatur bedienen” ist eine vollständige Meldung.
Die vollständige Erklärung mit der Verifizierungstabelle und ihrem Prüfverlauf liegt im Repository: docs/accessibility-statement.md.