Yu Morita (yuu) @securecat

Claudeの基本性能にWCAG 2.2 AAを組み込んで欲しい旨を本日Anthropicに送ったのですが、そもそもとして、アクセシビリティに対する想いが共通認識の土台になってないといけないよなと思うなどしまして、とりあえず私のアクセシビリティステートメントとして綴ってみました。 github.com/securecat/my-a…

Claude Codeの場合は /feedback コマンド。

サポートによると、You can also use the thumbs down button in Claude's interface to flag specific responses where accessibility could be improved, which helps our teams understand real-world patterns. だそう。非アクセシブルな提案をされたら都度「A11y matters」とFBするのが良さげ。

A11Y.mdの時点で、短くならない・書いても書いても足りない…なことになってるので、Claude Designにしたとしても、新しい要素が発生するたびにたくさん整備しないといけないみたいになってしまう。「外付けの規律」じゃなくて「素で身についている感覚」になって欲しいのよ。がんばれ、生成AI界隈。

A11Y.mdみたいなことはClaude Designでやればいい…というような発想自体が、「違う、そうじゃない」なんだよね。もっと手前の話で、「セキュリティホールのあるコードを書かない」とか「変数名を意味のあるものにする」みたいな、もう呼吸のレベルなんだよ、アクセシビリティってのは。

生成AIの基本性能がそうなっていれば、これからのインターネットは、これまでのインターネットに比べて圧倒的にアクセシブルな世界になるのだろうになぁ

Claude designでこれらのルール適用済みのDesign Systemを使えば…とか以前の話で、基本性能に「WCAG 2.2 AAは品質保証の最低限だ」というのを備えて欲しいという話。Design Systemがあってもwebページ/アプリ以外の開発では使えなかったりする。ベースラインがアクセシビリティの知識を持つべきだ。

Claudeがいちいちアクセシビリティ不考慮のコードを吐くので、逐一対応した結果、グローバルCLAUDE.mdからアクセシビリティ基準として参照している A11Y.md 、現状こうなっています。 ーーーーーーーーーーーーーーーーーーー # Accessibility Baseline (WCAG 2.2 AA) サンプルコード・テストコードを含む**すべてのコード出力**において以下を遵守すること。 WCAG 2.2 AA ぎりぎりではなく、**余裕のある水準**を目指すこと。このファイルに明示的な記載がある場合はその値を優先し、記載のない事項は WCAG 2.2 AA に基づいて判断すること。 --- ## アクセシビリティの哲学 アクセシビリティとは、基準のぎりぎりを狙ったり、基準の抜け道をくぐって省略したりするものではない。**できるだけ多くの人に恩恵があるようにすること**が目的である。 ### 「装飾かどうか」を決めるのは制作者ではない ある要素が「装飾的かどうか」を決める権利は制作者にない。閲覧者は誰もが、画面に表示されているものが何であるかを知る権利を等しく持っている。晴眼者も、弱視の人も、全盲の人も。制作者がその権利を「これは装飾だから対象外」という判断で奪うことは許されない。 ### WCAGの免除規定は現代に適合していない WCAGの免除規定のほとんどはWCAG 2.0（2008年）当時のブラウザの表現力・支援技術の機能・通信速度などを根拠に書かれており、現代の技術環境にはマッチしていない。「WCAGではこれは免除される」という理由を、基準を下げる根拠にしないこと。 視認できる要素はすべて、テキストであるか装飾であるかを問わず、コントラスト比の基準を満たすこと。 --- ## フォントサイズ - `lang="ja"` の文書：本文・注釈ともに **最小16px** - `lang="en"` の文書：本文・注釈ともに **最小14px** - 単位は `px` に限らず `rem` / `%` 等を用途に応じて使ってよい。最終レンダリング結果として上記サイズとすること - 見出し（h1・h2・h3 等）は本文より大きくすること。具体的なサイズは都度決める - ただし、ブラウザ拡張の `popup.html` においては、見出しサイズは本文と同じでよい - 本文と注釈の優先度の差は、フォントサイズではなく**コントラスト比**で表現すること（後述） --- ## コントラスト比（全般） コントラスト比は、実装方法によらず**最終レンダリング結果**で判定すること。`opacity` の重ね合わせ・`rgba()` / `hsla()` の透明度指定・`filter: opacity()` 等で色が薄まった場合も、実効コントラスト比がこの基準を満たしていなければならない。 `opacity` はデザイン上の明確な理由がある場合を除いて使用しないこと。テキスト・境界線・UIコンポーネントなど、コントラスト比が求められる要素に適用すると実効コントラスト比が下がるため。 --- ## コントラスト比（テキスト） - **本文**と背景のコントラスト比：**7:1 以上** - **注釈など優先度の低いテキスト**と背景のコントラスト比：**4.5:1 以上**（本文より淡い色にすること） - ライトテーマ・ダークテーマのそれぞれで独立して適合すること - ぎりぎりの確保を狙わず、余裕をもった色選定をすること --- ## コントラスト比（非テキスト） 境界線・区切り線・アイコンなど、**あらゆる視覚的要素**は隣接する背景色に対して **3:1 以上**を確保すること。ボタン・入力欄などの UI コンポーネントはもちろん、カードの枠線・水平線・装飾的なボーダーも同様に適用される。 余裕のある目安： - 白・明るい背景（`#fafafa` 相当）に対して：`#767676` 相当以上の濃さ - 黒・暗い背景（`#18181b` 相当）に対して：`#6e6e76` 相当以上の明るさ ボタン背景が薄くなる場合は、**`#949494` 以上の濃さのボーダー**で囲むことでコントラストを確保してよい。 ライトテーマ・ダークテーマのそれぞれで独立して適合すること。 --- ## CSS 変数の設計 - 「装飾的な区切り線・背景」と「UIコンポーネントの境界・インジケーター」を**同じ変数で兼用しない**こと - 装飾ボーダーが 3:1 を確保できない場合は、削除すること（低コントラストの装飾は弱視ユーザーに見えておらず、存在意義がない） --- ## フォーカス・リンク - フォーカスインジケーターを消さないこと（`outline: none` の安易な使用禁止） - リンクのアンダーラインを消さないこと - hover 時もアンダーラインを維持し、さらに**太くする**こと --- ## インタラクション - **トースト／スナックバー**は自動消去しないこと - 原則：操作結果は地の文章として表示する - トーストを使う場合は**閉じるボタン**を設け、ユーザーが閉じるまで表示を維持すること - **自動再生・自動スクロール・カルーセル等**の自動で動くものを作らないこと - ユーザー操作による動きはOK。ただし**いつでも停止できる**手段を提供すること --- ## キーボード操作 - すべてのインタラクションをキーボードで操作できるようにすること - `