ここで「WCAG 2.2 AAA を目標とする」とは

目標とするという言葉は意図的に選んでいます。このページでは、何が、何によって検証されているのか、何がどこからも検証されていないのか、 そのギャップに対して何をするつもりなのかを正確に述べます。Lily が WCAG への「適合」を主張することはありません。それを裏付ける監査がないからです。

継続的に検証されているもの

  • すべてのコンポーネントの標準セマンティック要素、ARIA 属性、クラスフック。フレームワークごとの単体テスト群 (7 つのフレームワークで 15,000 件以上)で検証しています。
  • SvelteKit サンプルアプリにある 571 個すべてのコンポーネントデモページが axe でクリーンです (WCAG 2.0/2.1 の A+AA と 2.2 AA のルールセット)。全カタログのスイープは 2026-08-27 に最初のベースラインを取り、2026-10-06 に再実行しました。 さらに、7 つのサンプルアプリすべてで、ホーム、カタログ、組み合わせルートごとのベースラインがあります。
  • インタラクティブなコンポーネントごとのキーボード操作の約束事。各コンポーネントの標準メタデータに文書化され、テスト群で実行されています。 ヘルパーパッケージでは、さらに実ブラウザーの Playwright テストも走らせています。
  • 57 種類すべてのテーマにおける WCAG 2.2 のターゲットサイズ下限とオーバーフロー対策。スキップリンク、ランドマーク、 アプリごとに 4 つのビューポートでの横方向オーバーフローなし。RTL 反転を含む lang/dir の適用。

どこからも検証されていないもの

  • 適合性監査は一度も行われていません。 VPAT も認証もありません。自動化ツールがカバーするのは、WCAG の達成基準のうち少数です。
  • AAA 固有の基準(強化されたコントラストなど)は設計上の意図であり、検証された性質ではありません。axe のルールセットは A/AA を対象に動いています。 専用のハイコントラストテーマはまだありません。
  • スクリーンリーダーの挙動は、ほとんど検証されていません。 テスト群が確かめるのは ARIA 属性であり、 VoiceOver、NVDA、JAWS が何を読み上げるかではありません。このプロジェクトでは、テストがすべて成功しているのに実際の不具合があったことが一度ならずあり、 テストでは見えなかったからこそ、そのたびに変更履歴に記録しています。

このギャップに対してすること

独立したアクセシビリティ監査は、プロジェクトへの資金提供の最初の使い道として挙げているもので、監査人に必要な範囲はすでに用意してあります。 それまでは、スクリーンリーダーでの報告が、このプロジェクトがいちばん欲しい貢献です。 「コンポーネント X は Y と読み上げるが、Z の理由で誤りである」という形の報告は、そのまま対応につなげられます。

問題を報告する

github.com/LilyDesignSystem/lily-design-system で issue を開くか、 joel@joelparkerhenderson.com にメールしてください。WCAG の基準を挙げてもらえると助かりますが、必須ではありません。「X をキーボードで操作できなかった」だけで、完全な報告です。

検証表とそのレビュー履歴を含む声明の全文は、リポジトリにあります。 docs/accessibility-statement.md