アクセシビリティ

障害の有無・年齢・環境にかかわらず、誰もが Web やアプリを利用できるよう設計する取り組み。色覚多様性・スクリーンリーダー対応・キーボード操作・コントラストなど、煩雑で忘れがちな観点を体系的にカバーする。

A11y は accessibility の「a」と「y」の間に 11 文字あることに由来する省略表記。

概要 — もはや「あったら良い」ではない

アクセシビリティは 2025 年現在、グローバルでは法令遵守の対象 。

地域	規制	内容
EU	EAA（European Accessibility Act, 2025 年 6 月施行）	EU 域内サービスはアクセシビリティ対応必須
米国	ADA（Americans with Disabilities Act）	公共サイトは WCAG 準拠が事実上必須
日本	JIS X 8341-3 / 障害者差別解消法	公的機関は対応義務、民間は努力義務

加えて SEO 効果 （セマンティック HTML / 代替テキスト）、 ユーザー体験の向上 （キーボードショートカット、コントラスト）、 法的リスク回避 など、対応する理由は揃いました。

主な対応観点

領域	対象ユーザー	対応例
視覚（色覚多様性）	P 型 / D 型 / T 型色覚	色 + アイコン + ラベルで情報を冗長化、コントラスト確保
視覚（全盲・弱視）	スクリーンリーダー利用者	`alt` 属性 / `aria-label` / セマンティック HTML
聴覚	聴覚障害者	動画字幕、音声コンテンツに文字起こし
運動	マウスが使えない・パーキンソン病など	キーボード操作完結、フォーカス可視化、十分なクリック領域
認知	高齢者 / 認知障害 / 母語が違う	平易な言葉、明確なエラーメッセージ、十分な操作時間

色覚多様性は忘れられがち

型	通称	該当率
P 型	赤色弱	男性の約 1%
D 型	緑色弱	男性の約 4%
T 型	青色弱	0.001% 程度

男性のおよそ 5%、女性のおよそ 0.2% が何らかの色覚多様性を持つ。EC サイトの男性顧客 100 人中 5 人は 「赤い在庫切れ表示」「緑の決済成功ボタン」が見分けにくい 。

「色だけで情報を伝えない」が鉄則：

× 在庫状況を色だけで示す（赤＝切れ・緑＝あり）
○ 色 + アイコン + ラベル（🔴 在庫なし / 🟢 在庫あり）

WCAG — 国際標準ガイドライン

WCAG（Web Content Accessibility Guidelines）は W3C が定める国際標準。2025 年現在は WCAG 2.2 が最新。

POUR の 4 原則

原則	意味	例
Perceivable（知覚可能）	情報が知覚できる	alt 属性、字幕、コントラスト
Operable（操作可能）	UI が操作できる	キーボード操作、十分な時間
Understandable（理解可能）	内容が理解できる	平易な言語、予測可能な動作
Robust（堅牢）	多様な手段で解釈できる	セマンティック HTML、ARIA

適合レベル

レベル	内容	推奨
A	最低限	必須ライン
AA	標準	多くの法令が要求するライン
AAA	最高	公的機関・特別な配慮が必要な領域

民間サービスは WCAG 2.2 AA が現実的な目標。

主要ツール

カテゴリ	ツール	役割
自動チェック	axe-core / Lighthouse / WAVE	WCAG 違反の自動検出、CI 組み込み可
スクリーンリーダー	NVDA / JAWS / VoiceOver / TalkBack	全盲ユーザーの体験を再現
コントラスト	WebAIM Contrast Checker / Stark	文字 / 背景のコントラスト比測定
色覚シミュレーション	Stark / Sim Daltonism	色覚多様性の見え方を再現
デザイン段階	Figma plugin（Stark / Able）	デザイン時点でチェック

コントラスト比の基準（WCAG 2.2 AA）

テキスト種別	必要コントラスト
通常テキスト	4.5 : 1 以上
大きいテキスト（18pt+ / 14pt+ Bold）	3 : 1 以上
UI 部品・グラフィカル	3 : 1 以上

実装テクニック

セマンティック HTML

× <div onclick="submit()">送信</div>          <!-- 意味が伝わらない -->
○ <button type="submit">送信</button>          <!-- スクリーンリーダーが「ボタン」と読み上げ -->

代替テキスト

× <img src="logo.png">                                <!-- 画像が読み上げられない -->
○ <img src="logo.png" alt="CTS-KB ナレッジベース">    <!-- スクリーンリーダーが代替テキストを読む -->

装飾的な画像:
○ <img src="decoration.png" alt="" aria-hidden="true">  <!-- 意図的に無視させる -->

ARIA 属性

セマンティック HTML で表現できない場合の補助：

<!-- カスタムボタンに役割を明示 -->
<div role="button" tabindex="0" aria-label="閉じる" onkeydown="...">
  ✕
</div>

<!-- 動的に変わる情報を通知 -->
<div role="status" aria-live="polite">
  注文を受付ました
</div>

キーボード操作

すべての操作は Tab・Enter・Space・矢印キーで完結すること。
:focus { outline: 2px solid var(--color-focus); } で可視化。

AI 駆動開発との相性 — まさに AI の出番

アクセシビリティ対応は 「重要だが、煩雑で忘れがち」 という典型的な領域。だからこそ AI 駆動開発と相性が極めて良い。

煩雑な作業	AI が任せられること
全画像の `alt` 属性付与	Vision API で画像内容を解析、適切な代替テキストを生成
ARIA 属性の付与	コンポーネント役割を判定、適切な `role` ・ `aria-label` を提案
コントラスト比チェック	tokens の組み合わせを WCAG AA で自動検証
スクリーンリーダー読み上げレビュー	DOM 構造から読み上げ順を予測、不自然な箇所を指摘
キーボード操作の網羅	フォーカス可能要素のリストアップと Tab 順検証
色覚シミュレーション	スクリーンショットを 3 型でフィルタし、識別困難箇所を検出
WCAG 違反の自動修正	axe-core の指摘を AI に渡して一括修正

AI 駆動開発での実装フロー

1. デザイン段階: Figma + Stark で色覚 / コントラストチェック
2. 実装段階:    AI に「WCAG 2.2 AA 準拠で実装して」と明示
3. CI 段階:     axe-core で自動チェック、違反時はビルド失敗
4. レビュー:    AI に「アクセシビリティ観点でレビューして」と依頼
5. 手動確認:    Storybook + a11y アドオンで対話確認

CLAUDE.md に書いておくべきこと

## アクセシビリティ要件

- 全画像に alt 属性必須（装飾は alt="" + aria-hidden="true"）
- ボタンは <button>、リンクは <a> を使う（div + onclick 禁止）
- コントラスト比 WCAG AA（4.5:1）以上
- 色だけで情報を伝えない（必ずアイコン or ラベル併用）
- キーボード操作完結（Tab で全機能アクセス可能）
- フォーカスリング (:focus) を必ず可視化
- 動的更新は aria-live で通知

ここまで明示すれば、AI が生成するコードは大半が WCAG AA 相当を最初から満たします。

アンチパターン

失敗	是正
リリース前にチェッカーで一括対応	設計段階から組み込む。`<button>` を使わない設計はレビューで弾く
色だけで状態を表現	色 + アイコン + ラベルの 3 点セットを規約化
`alt` 属性に画像のファイル名	Vision API で内容ベースの代替テキストを生成
マウス前提の UI	キーボードでも操作完結を必須化、CI で検証
div + onclick の自前ボタン	セマンティック HTML（`<button>` `<a>`）を使う
動的更新を視覚だけで通知	`aria-live` でスクリーンリーダーにも通知

開発手法ガイド：アトミックデザイン編 — Atom レベルでアクセシビリティ対応を組み込む
開発手法ガイド：テスト技法編 — axe-core / Lighthouse による自動アクセシビリティテスト