Що тут означає «орієнтація на WCAG 2.2 AAA»

Слово орієнтація вжито свідомо. Ця сторінка точно описує, що перевіряється, чим, що не перевіряється нічим і що ми збираємося робити з цією прогалиною. Lily ніколи не заявляє про «відповідність» WCAG — жоден аудит цього не підтверджує.

Перевіряється постійно

  • Канонічний семантичний елемент кожного компонента, атрибути ARIA та клас-гачки — підтверджені наборами модульних тестів для кожного фреймворку (понад 15 000 випадків у семи фреймворках).
  • Кожна з 571 демосторінок компонентів у прикладі застосунку SvelteKit проходить axe без зауважень (набори правил WCAG 2.0/2.1 A+AA та 2.2 AA) — повний обхід каталогу, вперше зафіксований 2026-08-27 і повторений 2026-10-06 — плюс базові лінії для кожного застосунку на головній сторінці, каталозі та складених маршрутах у всіх семи прикладах застосунків.
  • Клавіатурні контракти для кожного інтерактивного компонента, задокументовані в канонічних метаданих кожного компонента й перевірені наборами тестів; пакети допоміжних засобів додатково запускають Playwright-специфікації в реальних браузерах.
  • Мінімальні розміри цілей WCAG 2.2 та захист від переповнення в усіх 57 темах; посилання пропуску, орієнтири та відсутність горизонтального переповнення у чотирьох в’юпортах для кожного застосунку; lang/dir застосування та перевертання RTL.

Не перевіряється нічим

  • Аудит відповідності ніколи не проводився. Жодного VPAT, жодної сертифікації. Автоматизовані інструменти охоплюють меншість критеріїв успіху WCAG.
  • Специфічні критерії AAA (підвищена контрастність та інші) — це проєктні наміри, а не перевірені властивості; набори правил axe запускають A/AA. Спеціальної теми високої контрастності поки немає.
  • Поведінка зчитувачів екрана здебільшого не тестувалася. Набори тестів перевіряють атрибути ARIA, а не те, що озвучують VoiceOver, NVDA чи JAWS, — і цей проєкт не раз випускав зелені набори тестів над реальними дефектами, кожен з яких описано в журналі змін саме тому, що тести їх не бачили.

Що ми збираємося з цим робити

Незалежний аудит доступності — перше назване використання будь-якого фінансування проєкту, і обсяг, потрібний аудитору, уже підготовлено. До того часу звіти про зчитувачі екрана — це внесок, якого проєкт хоче найбільше: «компонент X оголошує Y, що неправильно, бо Z» — це безпосередньо придатно до дії.

Повідомте про проблему

Відкрийте issue на github.com/LilyDesignSystem/lily-design-system або напишіть на joel@joelparkerhenderson.com. Назва критерію WCAG допомагає, але не обов’язкова — «я не зміг керувати X з клавіатури» — повноцінний звіт.

Повна заява з таблицею перевірок та історією її перегляду є в репозиторії: docs/accessibility-statement.md.