Co tutaj znaczy „dąży do WCAG 2.2 AAA”
Słowo dąży jest wybrane celowo. Ta strona mówi dokładnie, co jest weryfikowane, czym, czego nie weryfikuje nic i co zamierzamy zrobić z tą luką. Lily nigdy nie twierdzi, że jest „zgodny” z WCAG — żaden audyt tego nie potwierdza.
Weryfikowane w sposób ciągły
- Kanoniczny element semantyczny, atrybuty ARIA i haki klas każdego komponentu — potwierdzane przez zestawy testów jednostkowych dla każdego frameworka (ponad 15 000 przypadków w siedmiu frameworkach).
- Każda z 571 stron demonstracyjnych komponentów w aplikacji przykładowej SvelteKit jest czysta według axe (zestawy reguł WCAG 2.0/2.1 A+AA oraz 2.2 AA) — przegląd całego katalogu, po raz pierwszy ustalony jako baza 2026-08-27 i uruchomiony ponownie 2026-10-06 — plus bazy dla każdej aplikacji dla strony głównej, katalogu i tras złożonych we wszystkich siedmiu aplikacjach przykładowych.
- Kontrakty klawiatury dla każdego interaktywnego komponentu, udokumentowane w kanonicznych metadanych każdego komponentu i sprawdzane przez zestawy testów; pakiety pomocnicze dodatkowo uruchamiają specyfikacje Playwright w prawdziwych przeglądarkach.
-
Dolne granice rozmiaru celu według WCAG 2.2 i zabezpieczenia przed przepełnieniem we wszystkich 57 motywach; link pomijający, punkty orientacyjne i brak przepełnienia poziomego w czterech widokach na aplikację;
lang/dirstosowanie, w tym odwrócenie RTL.
Niezweryfikowane przez nic
- Nigdy nie przeprowadzono audytu zgodności. Brak VPAT, brak certyfikacji. Narzędzia automatyczne obejmują mniejszość kryteriów sukcesu WCAG.
- Kryteria specyficzne dla AAA (podwyższony kontrast i inne) są zamierzeniami projektowymi, a nie zweryfikowanymi właściwościami; zestawy reguł axe działają na poziomie A/AA. Nie ma jeszcze dedykowanego motywu wysokiego kontrastu.
- Zachowanie czytników ekranu jest w dużej mierze nietestowane. Zestawy testów potwierdzają atrybuty ARIA, a nie to, co ogłaszają VoiceOver, NVDA czy JAWS — i ten projekt więcej niż raz wydał zielone zestawy testów mimo rzeczywistych defektów, z których każdy opisano w dzienniku zmian właśnie dlatego, że zestawy ich nie widziały.
Co zamierzamy z tym zrobić
Niezależny audyt dostępności to pierwsze nazwane przeznaczenie jakiegokolwiek finansowania projektu, a zakres potrzebny audytorowi jest już przygotowany. Do tego czasu raporty z czytników ekranu to wkład, którego ten projekt pragnie najbardziej: „komponent X ogłasza Y, co jest błędne, ponieważ Z” nadaje się do bezpośredniego działania.
Zgłoś problem
Otwórz zgłoszenie na github.com/LilyDesignSystem/lily-design-system lub napisz na joel@joelparkerhenderson.com. Podanie kryterium WCAG pomaga, ale nie jest wymagane — „nie mogłem obsługiwać X klawiaturą” to kompletne zgłoszenie.
Pełna deklaracja, z tabelą weryfikacji i historią przeglądów, znajduje się w repozytorium: docs/accessibility-statement.md.