アクセシビリティの基礎
このページで学ぶこと
Section titled “このページで学ぶこと”- ウェブアクセシビリティが誰のための何の品質か
- 障害、加齢、一時的・状況的な制約とWeb利用の関係
- WCAG 2.2の四原則と適合レベル
- HTML、デザイン、コンテンツ、JavaScriptが担う基礎的な対応
- PMが目標・対象・役割・テストを要件化する方法
ウェブアクセシビリティは、利用者の身体・認知・利用環境等にかかわらず、Webの情報や機能へアクセスし、理解し、操作できるようにすることです。
flowchart LR
C[Webコンテンツ・機能] --> V[見る]
C --> H[聞く]
C --> K[キーボード等で操作]
C --> U[理解する]
C --> A[支援技術から利用]
「障害者向けの追加機能」だけではありません。
次のような状況にも関わります。
- 画面を見にくい
- 音を聞けない
- マウスを使えない
- 小さな操作が難しい
- 複雑な文章・手順を理解しにくい
- 強い動きや点滅で体調に影響する
- 一時的なけが
- 屋外のまぶしい環境
- 音を出せない場所
- 片手でスマートフォンを使う
- 通信が遅い
- 加齢による変化
アクセシビリティ改善は、多くの利用者の使いやすさ・堅牢性にもつながります。
利用方法は一つではない
Section titled “利用方法は一つではない”Webサイトは、画面を見てマウス・タッチで操作する人だけが使うものではありません。
支援技術・設定の例
Section titled “支援技術・設定の例”- スクリーンリーダー
- 画面拡大
- ハイコントラスト設定
- 音声入力
- スイッチデバイス
- キーボード
- 点字ディスプレイ
- 字幕
- 読み上げ・読みやすさ支援
- 動きを減らすOS設定
- 画像を見ずに代替テキストを聞く
- 見出し一覧から目的箇所へ移動する
- Tabキーで操作対象を移る
- 200%・400%へ拡大する
- 色ではなくテキスト・形で状態を判断する
- 動画を字幕で理解する
見た目の完成画像だけでは、これらの利用方法を確認できません。
アクセシビリティは複数職種の成果
Section titled “アクセシビリティは複数職種の成果”flowchart TD
P[企画・PM] --> A[目標・対象・調達]
IA[情報設計・コンテンツ] --> B[構造・言葉・代替]
D[デザイン] --> C[色・文字・操作・状態]
E[実装] --> F[HTML・キーボード・動的UI]
Q[テスト] --> G[自動・手動・支援技術]
O[運用] --> H[更新・教育・継続改善]
実装者だけに「アクセシビリティ対応してください」と依頼しても、次は解決できません。
- 分かりにくい情報構造
- 色だけで表したデザイン
- 文字の入った画像
- 説明のないリンク文言
- 字幕のない動画
- 複雑すぎるフォーム
- CMS編集者が入力する代替テキスト
要件・原稿・デザインから分担します。
WCAGとは
Section titled “WCAGとは”WCAG（Web Content Accessibility Guidelines）は、Webコンテンツをアクセシブルにするための国際的な技術標準です。
W3CのWAIによって策定されています。
WCAG 2.2は、四つの原則の下にガイドラインと、検証可能な達成基準を持ちます。
flowchart TD
W[WCAG 2.2] --> P[知覚可能]
W --> O[操作可能]
W --> U[理解可能]
W --> R[堅牢]
P --> L[A・AA・AAAの達成基準]
O --> L
U --> L
R --> L
知覚可能（Perceivable）
Section titled “知覚可能（Perceivable）”情報・UIを、利用者が知覚できる形で提供します。
- 画像の代替
- 字幕
- 情報構造
- 色・コントラスト
- 拡大・リフロー
操作可能（Operable）
Section titled “操作可能（Operable）”操作・移動を行えるようにします。
- キーボード操作
- 十分な時間
- 点滅・動き
- ナビゲーション
- フォーカス
- 操作対象の大きさ
理解可能（Understandable）
Section titled “理解可能（Understandable）”内容と操作を理解・予測しやすくします。
- 言語
- 一貫した操作
- 入力支援
- エラーの説明
- 認証の負担
堅牢（Robust）
Section titled “堅牢（Robust）”ブラウザ・支援技術等が内容と状態を解釈できるようにします。
- 適切なHTML
- 名前・役割・状態
- 動的更新の通知
WCAGの達成基準にはA、AA、AAAのレベルがあります。
一般に、対象規格・調達要件・組織方針に基づき、目標レベルを設定します。
「AA対応」という言葉だけでは不十分です。
- 対象ページ
- 対象機能
- 適用するWCAGの版
- 適合レベル
- 対象外・第三者コンテンツ
- 試験方法
- 公開時期
- 適合表明・試験結果
- 公開後の維持
を明確にします。
日本の案件ではJIS X 8341-3等を参照する場合があります。法令・調達・社内基準上の要求は、案件ごとに専門部門と確認します。
WCAGは初心者向けの作り方説明書ではない
Section titled “WCAGは初心者向けの作り方説明書ではない”WCAGは技術標準であり、実装・デザインの入門資料とは役割が異なります。
- WCAG：満たすべき達成基準
- Understanding：達成基準の意図・背景
- Techniques：満たす方法の例
- Quick Reference：基準・方法を検索
- デジタル庁ガイド：非専門家向けの考え方・実務
- APG：複雑なUIパターンのARIA・キーボード例
標準だけを読み、チェック項目を機械的に適用すると、不要・不適切な対応になることがあります。
目的と利用者の使い方を理解して使います。
意味のあるHTML
Section titled “意味のあるHTML”適切なHTML要素を使うと、ブラウザ・支援技術が情報の役割を理解できます。
- ページタイトル
- 見出し
- ナビゲーション
- メインコンテンツ
- リスト
- 表
- 引用
- フォーム
- ボタン
- リンク
見た目をCSSで同じにしても、単なるdivとボタン要素では、キーボード・読み上げ・役割が異なります。
ARIAはHTMLへ意味・状態を補う技術ですが、標準HTMLで実現できるものを不要に置き換えないことが基本です。
見出しとランドマーク
Section titled “見出しとランドマーク”見出しは、文字を大きくする装飾ではなく、内容の階層を表します。
flowchart TD
H1[ページの主題 h1] --> H2A[主要セクション h2]
H1 --> H2B[主要セクション h2]
H2A --> H3A[下位セクション h3]
スクリーンリーダー利用者は、見出し一覧でページを移動できます。
ランドマークは、ヘッダー、ナビゲーション、メイン、フッター等の領域を示します。
情報設計とHTML構造を合わせます。
画像の代替テキスト
Section titled “画像の代替テキスト”画像が伝える目的・情報を、見られない利用者へテキストで提供します。
情報を伝える画像
Section titled “情報を伝える画像”内容・目的を簡潔に説明します。
情報を持たない場合、読み上げ対象から外します。
リンク・ボタン画像
Section titled “リンク・ボタン画像”画像の見た目ではなく、操作の目的を伝えます。
短い代替だけで足りない場合、本文・表・詳細説明を用意します。
「画像です」「写真」「image.jpg」のような代替は役に立ちません。
一方、周囲の本文と同じ情報を冗長に繰り返す必要もありません。
CMS編集者が判断できる入力ガイドを用意します。
色・コントラスト
Section titled “色・コントラスト”色覚や視力、画面・照明条件によって、色の見え方は異なります。
- 文字と背景
- ボタン・入力枠
- フォーカス
- グラフ
- エラー
- 選択状態
で十分な判別を確保します。
色だけで意味を伝えず、テキスト、アイコン、形、パターン等を併用します。
例：
- 赤だけで必須・エラーを示さない
- グラフ系列を色だけで区別しない
- 選択中タブを色だけで表さない
ブランドカラーを変えるだけでなく、文字サイズ、太さ、背景、部品の使い方で調整できます。
キーボード操作
Section titled “キーボード操作”マウスを使えない・使わない利用者は、キーボード等で操作します。
- すべての操作へ到達できる
- 論理的な順番で移動する
- 現在位置が見える
- 操作不能な場所へ閉じ込められない
- メニュー・モーダルを開閉できる
- スキップリンク等で繰り返し領域を飛ばせる
- 独自ショートカットが入力を妨げない
フォーカス枠をデザイン上の理由で消さないようにします。
必要なら、ブランドに合う見やすいフォーカス表示へ変更します。
リンクとボタン
Section titled “リンクとボタン”別ページ・場所へ移動します。
送信、開閉、実行等の動作を起こします。
見た目ではなく役割で使い分けます。
「こちら」「詳しく見る」だけが多数並ぶと、リンク一覧で目的を判別しにくくなります。
文脈を含むリンク名や、アクセシブルな名前を設計します。
フォームは、ラベル、説明、入力、エラー、確認、完了を一連で設計します。
flowchart LR
L[項目名・説明] --> I[入力]
I --> V{検証}
V -->|問題あり| E[場所と修正方法を示す]
V -->|問題なし| C[確認・送信]
C --> R[完了・次の行動]
基礎的な確認
Section titled “基礎的な確認”- 入力欄にラベルが関連づく
- 必須・任意が分かる
- 形式・文字数を入力前に説明
- エラー箇所と理由を伝える
- 色だけでエラーを示さない
- 入力内容を不必要に消さない
- 自動入力を妨げない
- キーボードで操作できる
- 完了・失敗を通知する
プレースホルダーだけをラベル代わりにすると、入力中に項目名が見えなくなります。
拡大・リフロー・レスポンシブ
Section titled “拡大・リフロー・レスポンシブ”文字やページを拡大したときに、内容・操作が欠落しないようにします。
- 横スクロールが過剰に発生しない
- 文字が重ならない
- ボタン・入力欄が画面外へ消えない
- 固定ヘッダーが内容を隠さない
- モーダルをスクロールできる
- 表の閲覧方法を用意する
- 画面方向を不必要に固定しない
レスポンシブデザインを実装しただけで、拡大・リフロー要件を満たすとは限りません。
長文、多言語、ブラウザズームで確認します。
動画・音声・動き
Section titled “動画・音声・動き”- 字幕
- 音声解説
- 文字起こし
- 操作可能なプレイヤー
- 自動再生の制御
- 音だけで重要情報を伝えない
必要な対応はコンテンツの種類・要件で異なります。
- 自動で動くカルーセル
- 背景動画
- 点滅
- スクロールアニメーション
- 視差効果
は、停止・一時停止や、動きを減らす設定への配慮を検討します。
強い点滅は健康上のリスクになる場合があります。
分かりやすい内容
Section titled “分かりやすい内容”アクセシビリティはコードだけではありません。
- 短く具体的な見出し
- 難語・略語の説明
- 一貫した名称
- 手順の分割
- 重要情報の先出し
- エラーの修正方法
- 日付・金額・期限の明示
- アイコンだけに頼らない
- PDF以外の情報提供
- 多言語の言語指定
等が、理解可能性に関わります。
業界用語を使う場合、対象利用者が理解できるか確認します。
アクセシビリティ目標を決める
Section titled “アクセシビリティ目標を決める”案件開始時に次を決めます。
- 適用規格・版
- 目標レベル
- 対象ページ・機能
- 対象ブラウザ・支援技術
- 第三者コンテンツ
- 既存コンテンツ
- PDF・動画
- 試験方法
- 公開する情報
- 未達事項の扱い
- 公開後の改善
「できる限り対応」では、見積・テスト・合否が曖昧です。
対象外がある場合も、理由、代替手段、改善計画を記録します。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”コーポレートサイト
Section titled “コーポレートサイト”- ナビゲーション
- 見出し
- 画像・図表
- フォーム
- 動画
- スライダー
- CMS更新
- 多言語
を職種横断で確認します。
施設検索サイト
Section titled “施設検索サイト”- 検索条件
- 地図だけに頼らない一覧
- 現在地許可
- フィルター状態
- 0件・エラー
- キーボード
- 動的更新の通知
- 距離・営業時間の表現
が重要です。
業務・会員アプリ
Section titled “業務・会員アプリ”- ログイン
- セッション期限
- モーダル
- 複雑なフォーム
- 表・グリッド
- 動的通知
- SPAページ遷移
- タイムアウト
等、JavaScriptによる状態管理とフォーカスが重要になります。
PMチェックリスト
Section titled “PMチェックリスト”- アクセシビリティを対象利用者と事業品質として説明できる
- 適用規格・版・目標レベル・対象範囲を決めている
- 発注・見積・受入条件にアクセシビリティを含めている
- 情報設計、原稿、デザイン、実装、運用の担当を分けている
- 見出し・ナビゲーション・HTML構造を確認している
- 画像・図表・アイコンの代替情報を設計している
- 色だけで状態・意味を伝えていない
- コントラストとフォーカス表示を確認している
- すべての主要操作をキーボードで行える
- フォームのラベル・説明・エラー・完了を設計している
- 拡大・リフロー・長文・多言語を確認している
- 動画の字幕等と自動再生・動きの制御を決めている
- CMS編集者向けの入力ルールを用意している
- 自動検査だけでなく手動・支援技術確認を計画している
- 公開後のコンテンツ更新・改修で維持する体制がある
よくある誤解・失敗
Section titled “よくある誤解・失敗”「アクセシビリティは視覚障害者向け」
Section titled “「アクセシビリティは視覚障害者向け」”聴覚、身体、認知、発話、加齢、一時的・状況的な制約等、幅広い利用に関わります。
「WCAGのチェックリストを満たせば使いやすい」
Section titled “「WCAGのチェックリストを満たせば使いやすい」”WCAGは重要な基準ですが、実際の内容・操作・業務が分かりやすいか、利用者が目的を達成できるかも確認します。
「ARIAを追加すればアクセシブルになる」
Section titled “「ARIAを追加すればアクセシブルになる」”誤ったARIAは支援技術へ誤情報を伝えます。まず適切な標準HTMLを使い、必要な場合に役割・状態を補います。
「実装者が最後に対応する」
Section titled “「実装者が最後に対応する」”原稿、色、部品、動画、フォーム、CMS運用等は上流で決まるため、最後では手戻りが大きくなります。
「自動ツールでエラーがゼロなら合格」
Section titled “「自動ツールでエラーがゼロなら合格」”代替テキストの適切さ、キーボードの自然さ、読み上げ順、内容理解等、自動判定できない問題があります。
理解度チェック
Section titled “理解度チェック”Q1. ウェブアクセシビリティを一言で説明してください。
Section titled “Q1. ウェブアクセシビリティを一言で説明してください。”回答と解説
利用者の障害・加齢・利用環境等にかかわらず、Webの情報と機能を知覚・操作・理解し、支援技術を含む環境から利用できるようにすることです。Q2. WCAGの四原則を挙げてください。
Section titled “Q2. WCAGの四原則を挙げてください。”回答と解説
知覚可能、操作可能、理解可能、堅牢です。Q3. 色だけでエラーを示してはいけない理由は何ですか。
Section titled “Q3. 色だけでエラーを示してはいけない理由は何ですか。”回答と解説
色を判別しにくい利用者や環境では意味が伝わらないためです。テキスト、アイコン、位置・形等を併用します。Q4. 画像の代替テキストは、画像の見た目をすべて説明すればよいでしょうか。
Section titled “Q4. 画像の代替テキストは、画像の見た目をすべて説明すればよいでしょうか。”回答と解説
画像がその文脈で伝える目的・情報を表します。装飾なら読み上げから外し、グラフ等は本文・表で詳細を補う場合があります。Q5. 自動アクセシビリティ検査だけでは不十分な理由は何ですか。
Section titled “Q5. 自動アクセシビリティ検査だけでは不十分な理由は何ですか。”回答と解説
代替テキストの意味、見出しの妥当性、キーボード操作の自然さ、読み上げ、内容理解等は人間による手動・支援技術確認が必要だからです。- W3C WAI「WCAG 2 Overview」
https://www.w3.org/WAI/standards-guidelines/wcag/
WCAG 2.2の四原則、達成基準、レベル、関連文書を確認する公式資料。 - W3C「Web Content Accessibility Guidelines (WCAG) 2.2」
https://www.w3.org/TR/WCAG22/
Webコンテンツのアクセシビリティに関する技術標準。 - デジタル庁「ウェブアクセシビリティ導入ガイドブック」
https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook
非専門家が発注・制作・運用で取り組むための初心者向け公式ガイド。 - web.dev「Learn Accessibility」
https://web.dev/learn/accessibility/
HTML、ARIA、フォーカス、色、フォーム、テスト等の実践的な公式コース。 - サイボウズ「2021年度アクセシビリティ研修」
https://speakerdeck.com/cybozuinsideout/accessibility-2021
組織・制作実務での基礎学習用参考資料。