アクセシビリティを制作実務へ組み込む
このページで学ぶこと
Section titled “このページで学ぶこと”- アクセシビリティが実装段階だけでは解決できない理由
- モーダル、メニュー、カルーセル、タブ、入力候補等の動的UIで必要な設計
- フォーカス管理、動的更新通知、SPAページ遷移の考え方
- 自動・手動・支援技術・利用者テストの使い分け
- 調達、デザインレビュー、受入、CMS運用へ組み込む方法
アクセシビリティは、一度チェックして完了する作業ではありません。
flowchart LR
P[企画・要件] --> I[情報設計・原稿]
I --> D[デザイン]
D --> E[実装]
E --> T[テスト]
T --> R[公開]
R --> O[運用・更新]
O --> T
各工程で作られた問題は、後工程で修正するほど費用が高くなります。
たとえば、色だけで状態を示すデザインは、実装時にHTMLを調整しても根本解決しません。
複雑すぎる申請フローは、スクリーンリーダー対応だけで分かりやすくなりません。
工程ごとの責任
Section titled “工程ごとの責任”| 工程 | 主な責任 |
|---|---|
| 企画・要件 | 対象、規格、目標、予算、役割、試験 |
| 情報設計 | ページ構造、ナビゲーション、手順、名称 |
| コンテンツ | 見出し、リンク文言、代替、字幕、説明 |
| デザイン | 色、文字、フォーカス、状態、拡大、動き |
| 実装 | HTML、キーボード、ARIA、動的更新、エラー |
| テスト | 自動、キーボード、拡大、読み上げ、実機 |
| 運用 | CMSルール、教育、更新確認、改善 |
一つのチェックシートを実装者へ渡すだけでは、これらをカバーできません。
企画・要件へ組み込む
Section titled “企画・要件へ組み込む”最初に決めること
Section titled “最初に決めること”- 適用する規格・版
- 目標レベル
- 対象ページ・機能
- 対象外と理由
- PDF・動画・外部サービス
- 既存コンテンツ
- 対象ブラウザ・支援技術
- 試験方法
- 成果物
- 公開後の維持
- 未達時の判断者
曖昧な記述：
アクセシビリティに配慮する。
確認可能な記述：
- 対象ページはWCAG 2.2 レベルAA相当を目標とする
- 主要フローをキーボードのみで完了できる
- ブラウザ200%拡大と指定幅で内容・操作が欠落しない
- フォームエラーを項目と関連づけ、修正方法をテキストで示す
- 自動検査、手動確認、代表ページのスクリーンリーダー確認を行う
- 第三者ウィジェットの制約を記録し、代替手段を提供する
案件に応じて、基準・試験方法は専門家と調整します。
情報設計とコンテンツ
Section titled “情報設計とコンテンツ”ページの目的
Section titled “ページの目的”一ページに複数の目的・導線が競合すると、誰にとっても理解しにくくなります。
- 主題
- 主要行動
- 前提情報
- 次の行動
- 例外・問い合わせ
を整理します。
見た目の階層とHTMLの階層を一致させます。
デザイン都合で小さな文字を上位見出し、大きな文字を装飾へする場合も、文章構造は別途設計します。
「こちら」「詳細」だけを避け、リンク単体または周囲の文脈で目的が分かるようにします。
CMS一覧で同じ「詳しく見る」が並ぶ場合、支援技術向けに記事名を含む名前を持たせる方法があります。
意味のあるアイコンにはテキストラベルまたはアクセシブルな名前を用意します。
装飾アイコンを重複して読み上げないようにします。
PDFだけで情報を提供すると、端末・読み上げ・検索・更新で利用しにくい場合があります。
- 主要情報をHTMLでも提供
- 適切なタグ・読み順
- 代替テキスト
- 文書タイトル
- 表・見出し
- ファイル容量
- 更新日
を確認します。
デザインレビュー
Section titled “デザインレビュー”デザインカンプでは、正常状態だけでなく次の状態を作ります。
- フォーカス
- ホバー
- 選択
- 無効
- 読み込み
- 0件
- 入力エラー
- システムエラー
- 長文
- 多言語
- 拡大
- モバイル
- 高コントラスト・色に依存しない状態
注釈を付ける
Section titled “注釈を付ける”見た目だけでは実装者へ伝わらない事項を仕様として付けます。
- タブ移動順
- 開閉時のフォーカス
- 自動再生・停止
- 動的更新の読み上げ
- エラー表示タイミング
- 画面外コンテンツ
- キーボード操作
- モーション低減時
Figmaの画面だけを納品せず、操作・状態・意味を共有します。
標準HTMLを優先する
Section titled “標準HTMLを優先する”ブラウザ標準のボタン、リンク、入力欄、select、details等は、役割・キーボード操作・支援技術対応を持っています。
独自UIを作ると、これらを自分たちで再実装する必要があります。
flowchart TD
R[必要なUI] --> H{標準HTMLで実現できるか}
H -->|はい| S[標準要素を利用]
H -->|いいえ| C[独自コンポーネント]
C --> K[キーボード]
C --> N[名前・役割・状態]
C --> F[フォーカス]
C --> T[支援技術テスト]
デザイン上の見た目はCSSで変更できます。
標準要素では要件を満たせない場合に、ARIA Authoring Practices Guide等を参考に独自UIを設計します。
ARIAの役割と注意
Section titled “ARIAの役割と注意”ARIAは、標準HTMLだけでは表現できない役割・状態・関係を支援技術へ伝えます。
例：
- モーダルダイアログ
- タブ
- アコーディオン
- 入力候補
- 動的な通知
- 展開・選択状態
ARIAは見た目やキーボード動作を自動で追加しません。
role="button"を付けても、Enter・Spaceで操作できる実装やフォーカス管理は別途必要です。
誤ったARIAは、支援技術へ誤った情報を伝えます。
モーダルを開くと、利用者の操作対象が別の領域へ移ります。
- 開いたこととタイトルが分かる
- 初期フォーカスが適切な場所へ移る
- Tab移動がモーダル内に保たれる
- 背景を操作できない
- Escape・閉じるボタン等で閉じられる
- 閉じた後に元の操作位置へ戻る
- 小画面・拡大時に内容をスクロールできる
- 保存・取消の結果が分かる
sequenceDiagram
participant U as 利用者
participant B as 開くボタン
participant M as モーダル
U->>B: 操作
B->>M: 開く
M-->>U: タイトル・内容を伝え、内部へフォーカス
U->>M: 操作・閉じる
M-->>B: 元のボタンへフォーカスを戻す
背景を暗くするだけではモーダルになりません。
ハンバーガーメニュー、メガメニュー、プルダウン等では次を決めます。
- ボタンとして認識できる
- 開閉状態が分かる
- キーボードで開閉・移動できる
- フォーカスが見える
- マウスホバーだけに依存しない
- Escape・外部操作で閉じる場合の挙動
- サブメニューの構造
- モバイル・デスクトップの違い
デスクトップではホバー、モバイルではタップだけという設計でも、キーボード・タッチ・拡大時の一貫性を確認します。
カルーセル・スライダー
Section titled “カルーセル・スライダー”カルーセルは、情報を隠し、動きを発生させるため、採用目的を確認します。
- 自動再生の必要性
- 停止・再開
- 前後操作
- 現在位置
- キーボード
- 読み上げ順
- 非表示スライドの扱い
- スワイプ以外の操作
- 動きを減らす設定
- 画像・リンクの代替
重要情報をカルーセルの二枚目以降だけに置かないようにします。
自動で切り替わるため読み終えられない問題を避けます。
タブ・アコーディオン
Section titled “タブ・アコーディオン”複数のパネルを切り替えるUIです。
- 選択中タブ
- タブとパネルの関係
- 矢印キー・Tabの挙動
- URL・戻る操作
- 初期表示
- 深いリンク
- 非表示パネル
アコーディオン
Section titled “アコーディオン”見出しボタンで内容を開閉します。
- ボタンとして操作
- 展開状態
- 見出し構造
- 全開閉
- 検索・ページ内リンク
- 印刷
- JavaScript失敗時
「クリックできる見出し風div」だけで作らないようにします。
入力候補・コンボボックス
Section titled “入力候補・コンボボックス”検索サジェスト、住所候補等は、入力欄と候補リストを組み合わせる複雑なUIです。
- 候補が開いたこと
- 件数
- 選択中候補
- キーボード移動
- Enter・Escape
- 入力文字と確定値
- 候補なし
- 読み込み中
- 自由入力可否
- モバイルキーボード
標準のselectで要件を満たせるなら、独自実装より堅牢な場合があります。
フォーム実務
Section titled “フォーム実務”- 必須・任意
- 入力形式
- 使用目的
- 例
- 文字数
- 個人情報
- 保存・送信先
- 自動入力
- コピー・貼り付け
- IME
- 日付・電話番号
- 候補
- 制限
- 入力内容保持
- ページ上部のエラー概要
- 各項目のエラー
- 項目との関連づけ
- フォーカス移動
- 読み上げ通知
- 修正方法
- 入力値保持
- 処理中
- 二重送信防止
- 成功・失敗
- 次の行動
- 受付番号
- メール未着
- 再送
エラーが出たときにページ最上部へ戻るだけで、どこを直すか分からない状態を避けます。
フォーカス管理
Section titled “フォーカス管理”フォーカスは、キーボード操作の現在位置です。
JavaScriptで画面を大きく変更する場合、利用者の操作位置を適切に移す必要があります。
フォーカスを移す例
Section titled “フォーカスを移す例”- モーダルを開いた
- エラー概要から項目へ移る
- SPAで新しいページへ遷移
- 削除後に一覧へ戻る
- 追加した項目を編集する
移しすぎない
Section titled “移しすぎない”- 検索結果更新のたびに先頭へ移す
- 入力中に勝手に別項目へ移す
- 通知表示で作業位置を奪う
のは操作を妨げます。
何が変わり、次にどこを操作するかを基準に設計します。
動的更新の通知
Section titled “動的更新の通知”画面を見ている利用者には、トーストや色の変化で結果が分かっても、スクリーンリーダー利用者へ伝わらない場合があります。
- 保存完了
- 入力エラー
- 検索結果件数
- カート追加
- 接続切断
- 読み込み完了
- 自動更新
等を、必要に応じてライブリージョン等で通知します。
すべての変化を読み上げると騒がしくなるため、重要度とタイミングを選びます。
SPA・クライアント側ルーティング
Section titled “SPA・クライアント側ルーティング”SPAでは、URL・画面内容が変わってもブラウザの通常ページ読み込みが起きない場合があります。
そのため支援技術へ、ページが変わったことが自動で伝わらないことがあります。
- ページタイトル更新
- 見出し
- フォーカス位置
- ルート変更の通知
- 戻る・進む
- スクロール位置
- 読み込み中
- エラー
- 深いリンク
- キーボード操作
フレームワークを使うだけで自動的に解決しません。
ルーター・コンポーネント・画面仕様に合わせて実装・テストします。
無限スクロールと追加読み込み
Section titled “無限スクロールと追加読み込み”コンテンツを自動で追加するUIでは、
- フッターへ到達できない
- 現在位置が分からない
- 戻ると位置・内容が消える
- 読み上げが大量に発生する
- キーボード移動が長くなる
ことがあります。
「もっと見る」ボタン、ページング、URL・履歴保持、追加件数の通知等を検討します。
レスポンシブ・ズーム・リフロー
Section titled “レスポンシブ・ズーム・リフロー”アクセシビリティ確認では、デザイン指定の画面幅だけでなく、
- ブラウザズーム
- 文字サイズ変更
- OS表示拡大
- 320CSS px相当
- 縦横
- 長文・多言語
を試します。
- 固定高さから文字が切れる
- 横スクロールと縦スクロールの二方向が必要
- 固定ヘッダー・Cookieバナーが大部分を覆う
- モーダルの閉じるボタンが画面外
- 表を閲覧できない
- 入力欄がソフトウェアキーボードに隠れる
レスポンシブ対応済みという説明だけで合格にしません。
第三者コンテンツ・ウィジェット
Section titled “第三者コンテンツ・ウィジェット”- 動画プレイヤー
- 地図
- 決済
- チャット
- Cookie同意
- SNS埋め込み
- 広告
- 予約ウィジェット
- PDFビューア
は、制作側で内部実装を修正できない場合があります。
- キーボード
- 読み上げ
- コントラスト
- 拡大
- 言語
- エラー
- 代替手段
- ベンダー改善窓口
を評価します。
制約がある場合、別ページ・電話・メール等の代替手段、説明、改善計画を用意します。
「第三者製なので対象外」とするだけでは、利用者は目的を達成できません。
公開時にアクセシブルでも、CMS更新で品質が崩れます。
編集者が変更するもの
Section titled “編集者が変更するもの”- 見出し
- リンク文言
- 画像・代替
- 表
- 動画
- 色・装飾
- HTML
- 言語
- 公開順
CMS側で支援する
Section titled “CMS側で支援する”- 見出し選択肢を制限
- 代替テキスト欄
- リンク文言ガイド
- 色の自由指定を制限
- 不適切なHTMLを禁止
- 必須項目
- プレビュー
- 自動チェック
- 入力例・ヘルプ
運用で支援する
Section titled “運用で支援する”- マニュアル
- 研修
- 承認
- 定期棚卸し
- 問い合わせ窓口
- コンテンツ監査
- 担当変更時の引継ぎ
CMSの自由度と品質維持を両立させます。
テストを組み合わせる
Section titled “テストを組み合わせる”flowchart TD
A[自動検査] --> R[総合判断]
K[キーボード] --> R
Z[拡大・視覚確認] --> R
S[スクリーンリーダー] --> R
C[コンテンツ確認] --> R
U[利用者テスト] --> R
- HTML・ARIAの明確な問題
- 一部のコントラスト
- ラベルの有無
- ルール違反
を高速に検出します。
- キーボード
- フォーカス
- 読み順
- 拡大
- 動き
- エラー
- 代替テキストの適切さ
を確認します。
支援技術確認
Section titled “支援技術確認”代表的なOS・ブラウザ・スクリーンリーダーの組み合わせを選びます。
すべての組み合わせを網羅するのではなく、対象利用者・要件・市場を基に決めます。
利用者テスト
Section titled “利用者テスト”障害のある利用者を含むテストでは、チェック基準だけでは分からない実際の障壁を発見できます。
参加者一人の結果を全利用者へ一般化せず、設計・標準・複数の観察と合わせます。
自動検査の限界
Section titled “自動検査の限界”自動ツールはすべてのWCAG達成基準を確認できません。
たとえば、
- 代替テキストが内容に合うか
- 見出しの階層が適切か
- フォーカス移動が自然か
- 操作方法が理解できるか
- エラー説明が役に立つか
- 読み上げ順が意味を持つか
は人間の判断が必要です。
自動検査をCIへ組み込みつつ、手動テストを省略しません。
受入条件と成果物
Section titled “受入条件と成果物”- アクセシビリティ要件書
- 対象ページ・機能一覧
- デザインレビュー記録
- コンポーネント仕様
- 自動検査結果
- 手動試験結果
- 使用環境
- 未達事項
- 改善計画
- CMS運用ガイド
- アクセシビリティ方針・試験結果
- 主要操作をキーボードで完了
- 指定した拡大・画面幅で欠落なし
- 主要フォームの読み上げ・エラー確認
- 自動検査の重大項目解消
- 未達事項を責任者が確認
- 第三者機能の代替手段を確認
「対応済み」という自己申告だけでなく、試験条件と結果を残します。
継続的な維持
Section titled “継続的な維持”アクセシビリティは、コンテンツ更新、デザイン改修、外部サービス変更で低下します。
- 共通コンポーネントのテスト
- CIの自動検査
- CMS公開前チェック
- 定期サンプリング
- 主要フローの手動確認
- 利用者からの問い合わせ窓口
- 改善バックログ
- 社内研修
- 年次方針・試験更新
- 第三者サービスの再評価
一度の全面試験だけでなく、変更のたびに小さく確認できる仕組みを作ります。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”モーダルを多数使うブランドサイト
Section titled “モーダルを多数使うブランドサイト”デザイン表現だけでなく、フォーカス、背景操作、拡大、閉じる操作を共通コンポーネントとして実装・テストします。
個別ページごとに別実装しないようにします。
SPA型予約サービス
Section titled “SPA型予約サービス”画面遷移、タイムアウト、入力エラー、予約完了等の動的変化を、視覚・フォーカス・読み上げの三つで設計します。
E2E自動テストと代表フローのスクリーンリーダー確認を組み合わせます。
CMS運用型メディア
Section titled “CMS運用型メディア”記事テンプレートがアクセシブルでも、編集者が見出し・代替・リンク・表を不適切に入力すると品質が下がります。
CMS制約、入力ガイド、承認、定期監査を含めます。
PMチェックリスト
Section titled “PMチェックリスト”- 工程ごとのアクセシビリティ責任を決めている
- 要件を確認可能な受入条件へ変換している
- デザインにフォーカス、エラー、拡大、長文等の状態がある
- 標準HTMLで実現できるかを先に検討している
- 独自UIの名前・役割・状態・キーボードを仕様化している
- モーダルの初期・終了フォーカスを決めている
- メニュー・カルーセル・タブの全操作方法を確認している
- フォームの入力前・エラー・送信後を設計している
- 動的更新を必要なタイミングで支援技術へ伝えている
- SPA遷移時のタイトル、見出し、フォーカス、履歴を確認している
- ズーム・リフロー・長文・多言語で確認している
- 第三者サービスのアクセシビリティと代替手段を評価している
- CMS編集者向けの制約・ガイド・承認を用意している
- 自動、キーボード、拡大、スクリーンリーダー確認を組み合わせている
- 試験環境・結果・未達・改善計画を成果物として残している
- 公開後の更新・改修へ回帰確認を組み込んでいる
よくある誤解・失敗
Section titled “よくある誤解・失敗”「ARIAパターンのサンプルをコピーすれば完成」
Section titled “「ARIAパターンのサンプルをコピーすれば完成」”サンプルは特定条件の例です。コンテンツ、フォーカス、レスポンシブ、フレームワーク、支援技術で検証します。
「キーボードでクリックできたので問題ない」
Section titled “「キーボードでクリックできたので問題ない」”移動順、現在位置、開閉状態、閉じた後の位置、ショートカット競合等も確認します。
「アクセシビリティ試験は公開前の一回でよい」
Section titled “「アクセシビリティ試験は公開前の一回でよい」”CMS更新・共通部品改修・外部サービス変更で劣化するため、継続確認が必要です。
「第三者サービスは自社の責任外」
Section titled “「第三者サービスは自社の責任外」”内部実装を修正できなくても、選定、説明、代替手段、ベンダーへの改善要請は行えます。
「スクリーンリーダーで一度読めればよい」
Section titled “「スクリーンリーダーで一度読めればよい」”操作の効率、名前・状態、読み順、エラー、動的更新、複数環境を含めて確認します。
理解度チェック
Section titled “理解度チェック”Q1. モーダルをアクセシブルにするため、開閉時のフォーカスをどう扱いますか。
Section titled “Q1. モーダルをアクセシブルにするため、開閉時のフォーカスをどう扱いますか。”回答と解説
開いたときは内容に応じたモーダル内の要素へ移し、操作をモーダル内に保ち、閉じたときは原則として開いたボタン等の論理的な位置へ戻します。Q2. ARIAを追加するだけでは独自UIが完成しない理由は何ですか。
Section titled “Q2. ARIAを追加するだけでは独自UIが完成しない理由は何ですか。”回答と解説
ARIAは主に意味・状態を支援技術へ伝えるもので、キーボード動作、フォーカス、見た目、イベント処理を自動で実装しないためです。Q3. SPAのページ遷移で確認することを挙げてください。
Section titled “Q3. SPAのページ遷移で確認することを挙げてください。”回答と解説
ページタイトル、主見出し、フォーカス、ルート変更の通知、読み込み・エラー、戻る・進む、スクロール、深いリンク等です。Q4. CMS運用でアクセシビリティを維持する方法は何ですか。
Section titled “Q4. CMS運用でアクセシビリティを維持する方法は何ですか。”回答と解説
入力項目・許可部品の制約、代替テキスト欄、ガイド、プレビュー、自動チェック、承認、研修、定期監査を組み合わせます。Q5. 自動検査・手動検査・利用者テストはどう使い分けますか。
Section titled “Q5. 自動検査・手動検査・利用者テストはどう使い分けますか。”回答と解説
自動検査で明確な問題を反復検出し、手動・支援技術で操作・意味を確認し、利用者テストで実際の目的達成上の障壁を発見します。- W3C WAI「ARIA Authoring Practices Guide」
https://www.w3.org/WAI/ARIA/apg/
複雑なUIの意味、状態、キーボード操作を設計するための公式ガイド。 - W3C WAI「Dialog (Modal) Pattern」
https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
モーダルのフォーカス、背景操作、キーボード動作の公式パターン。 - W3C WAI「Patterns」
https://www.w3.org/WAI/ARIA/apg/patterns/
アコーディオン、タブ、コンボボックス等のパターン一覧。 - web.dev「Manual accessibility testing」
https://web.dev/learn/accessibility/test-manual
自動検査で確認できないキーボード・視覚・コンテンツ等の手動テストを学ぶ公式資料。 - デジタル庁「ウェブアクセシビリティ導入ガイドブック」
https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook