アクセシビリティ概要

読了 5分＋実践 20分

AIでUIを作るときに、アクセシビリティの基本を設計段階から押さえたい方

HTMLの見出し、リンク、ボタン、フォームの基本を知っていると理解しやすいです

アクセシビリティとは、利用環境、入力方法、読み上げ環境、画面サイズなどが変わっても、できるだけ多くの人が情報を理解し、操作できるようにする設計です。WCAG 2.2は、Webコンテンツをよりアクセシブルにするための推奨事項をまとめたW3C Recommendationで、知覚可能、操作可能、理解可能、正しく解釈できる（堅牢）という4つの原則を土台にしています。[1]

AIにUIを作らせると、見た目は整っていても、ボタンがキーボードで操作できない、フォームにラベルがない、色だけでエラーを伝えている、といった問題が残りやすくなります。アクセシビリティは「最後にチェックする項目」ではなく、プロンプト、設計、実装、レビューのすべてに入れる条件として扱います。

アクセシビリティで見る4つの観点

1. 知覚可能

ユーザーが情報を認識できる状態にします。テキストのコントラスト、画像の代替テキスト、見出し構造、音声・動画の代替情報が該当します。

WCAG 2.2のコントラスト基準では、通常テキストは少なくとも4.5:1、大きいテキストは少なくとも3:1のコントラスト比が求められます。[1] AIに色を任せる場合でも、ブランドカラーだけでなく、背景との組み合わせを検証する指示が必要です。

背景色と文字色の全組み合わせについて、通常テキストは4.5:1以上、
大きいテキストは3:1以上のコントラストを満たすようにしてください。
不足する場合は、色を変えて理由をコメントで説明してください。

2. 操作可能

マウス、タッチ、キーボード、支援技術のどれでも操作できる状態にします。WCAG 2.2は、コンテンツのすべての機能をキーボードインターフェースから操作できることを求めています。[1]

すべての操作要素はキーボードだけで操作できるようにしてください。
Tabで自然な順序に移動し、EnterまたはSpaceでボタンを実行し、
モーダルはEscapeで閉じ、閉じた後は開いたボタンへフォーカスを戻してください。

3. 理解可能

画面の意味、操作結果、エラー原因が分かる状態にします。フォームでは、プレースホルダーだけに頼らず、ラベル、説明、エラーメッセージを用意します。エラーは色だけでなく、文章とアイコンでも示します。

フォームのエラー状態は、赤色だけでなく、説明文とアイコンで伝えてください。
入力欄にはlabelを関連付け、エラー時はaria-invalidとエラーメッセージを接続してください。

4. 正しく解釈できる（堅牢）

ブラウザ、支援技術、自動検査ツールが意味を解釈できる状態にします。WAI-ARIAは、動的コンテンツや高度なUIコントロールを支援技術へ伝えるための属性や状態を定義しています。[2] ただし、ARIAはネイティブHTMLの代替ではありません。まず button、a、label、fieldset のような意味を持つHTMLを使い、必要な場合だけARIAで補います。

<button type="button" aria-expanded="false" aria-controls="menu-panel">
  メニュー
</button>

AIに任せる前に決める要件

生成AIへ「アクセシブルにして」とだけ伝えても、期待する品質にはなりません。少なくとも次の要件をプロンプトに含めます。

観点	指示する内容
構造	`h1`から始まる見出し階層、ランドマーク、フォームラベル
操作	キーボード操作、フォーカス順、Escapeや矢印キーの扱い
視覚	コントラスト、フォーカスリング、色以外の状態表現
状態	読み込み、エラー、成功、無効、選択中
動き	`prefers-reduced-motion` への対応
検証	自動検査、キーボード操作、スクリーンリーダー確認

コンポーネント別の基本チェック

ボタン

可視テキストまたは aria-label がある
button 要素を使う
Enter と Space で実行できる
フォーカスリングが見える
無効状態は disabled と説明で伝える

リンク

リンク先や目的がテキストだけで分かる
ボタンの見た目でも、画面遷移なら a 要素を使う
「こちら」「詳細」だけをリンクテキストにしない

フォーム

すべての入力に label がある
必須、任意、入力形式が分かる
エラー文が具体的で、該当フィールドと関連付いている
入力後にエラーが出た場合、次に何をすればよいか分かる

モーダル

モーダルやタブのような複雑なUIは、WAI-ARIA Authoring Practices Guideのパターンを参照して、ロール、状態、キーボード操作を確認します。[3] 特にモーダルは、開いたときのフォーカス移動、背景へフォーカスが抜けないこと、閉じた後のフォーカス復帰をセットで考えます。

モーダルを作成してください。
- dialogとして扱う
- 開いたら最初の操作要素へフォーカス
- Tabはモーダル内を循環
- Escapeで閉じる
- 閉じたら開いたボタンへフォーカスを戻す

検証は自動と手動を組み合わせる

W3Cは、アクセシビリティ評価ツールは役立つ一方で、ツールだけではサイトがアクセシビリティ標準を満たすか判断できず、知識のある人による評価が必要だと説明しています。[4] 自動検査は、ラベル漏れ、コントラスト不足、ARIAの誤用のような問題を早く見つけるために使い、キーボード操作や読み上げ順序は手動で確認します。

最低限、次の順番で確認します。

ブラウザで見出し、リンク、フォームの意味が自然か見る
Tab、Shift+Tab、Enter、Space、Escapeで操作する
自動検査ツールで明確な違反を確認する
スクリーンリーダーまたはブラウザのアクセシビリティツリーで名前・役割・状態を見る
AIに修正させる前に、失敗した操作と期待する挙動を具体的に書く

参考文献

W3C, Web Content Accessibility Guidelines (WCAG) 2.2, 2024年12月12日
W3C Web Accessibility Initiative, WAI-ARIA Overview
W3C Web Accessibility Initiative, ARIA Authoring Practices Guide
W3C Web Accessibility Initiative, Evaluating Web Accessibility Overview

クイズ

アクセシビリティ設計

Claudeの機能・製品ラインナップ