Webアクセシビリティ技術と実装の実際

Webアクセシビリティ技術と実装の実際
.NETラボ 勉強会 2026年2月
視覚障碍者や色覚異常、年齢、教育、地理的な場所、言語などに関係なくあらゆる情報にアクセスできWebサービスを享受できることはとても重要なことです。次の瞬間、病気や事故によってあなたもそれらが困難になるかもしれません。

しかしながら、代替手段でアクセスできるようにすることが重要なことです。

とても大事なことですので今一度Webアクセシビリティについて振り返ってみましょう。

実際に視覚障碍者がどのようにPCやスマートフォンを使っているかデモンストレーションを通じてアクセシビリティの実際を学んでいきましょう。
https://dotnetlab.connpass.com/event/378424/

Transcript

1. Webアクセシビリティ技術と 実装の実際 FutureOne株式会社 草場 友光 .NETラボ勉強会2026年2月
2. 自己紹介 • コミュニティ活動を通じて知識を アップデートしています。 • 2022/08-2026 Microsoft MVP (Developer Technologies) • tomo_kusaba • ドラクエ大好き ドラクエ10のプレイ時間→ 1キャラ目：2663時間 2キャラ目：916時間 3キャラ目：791時間 4キャラ目：190時間(配信用)
3. 注意 • 個人の見解・解釈が多分に入っています。 • 見解の相違・事実誤認などありましたらご指摘ください。
4. 今日の目的 • 視覚障碍者や色覚異常、年齢、教育、地理的な場所、言語などに関 係なくあらゆる情報にアクセスできWebサービスを享受できるこ とはとても重要なことです。次の瞬間、病気や事故によってあな たもそれらが困難になるかもしれません。 • しかしながら、代替手段でアクセスできるようにすることが重要な ことです。 • とても大事なことですので今一度Webアクセシビリティについて 振り返ってみましょう。
5. あなたのサービスは、 ある日あなたが色を 識別できなくなったとしても 不自由なく使えますか？
6. あなたのサービスは、 ある日あなたが目が 見えなくなったとしても 不自由なく使えますか？
7. アクセシビリティに ついて学びましょう
8. アクセシビリティとは？ • 誰もが自由に何かの目的を達成できるような状態のことを指す。 • 特に情報システムにおいては何らかのハンディキャップを持った 方でも不自由なく情報にアクセスできるような状態を指す。 • 2024年4月障害者差別解消法によって合理的配慮の提供が求 められています。
9. アクセシビリティの根幹 • 情報や機能への「別ルート」を確保するということ • 視覚に頼れないとき →スクリーンリーダー • 聴覚に頼れないとき →字幕・文字情報 • マウス操作が困難なとき →キーボード操作のみで完結 • 一つの手段が使えないときに別の手段がある状態を作る →複数の手段で情報を伝えられるようにすることが重要
10. 視覚障碍者の方は どのようにPCやスマートフォンを操作してるの？
11. Webアクセシビリティの国際標準 • WCAG(Web Content Accessibility Guidelines) 現在は2.1が広く採用され2.2への移行が進んでいる。 レベルA(最低限)、AA(推奨)、AAA（最高）の3段階があり多くの 法規制はAAを基準にしています。 • 日本ではJIS X 8341-3がWCAG 2.0/2.1と整合しており公 共機関や大企業での対応基準として参照されます。
12. WCAG 2.2の全体像 • 4つの原則 原則 説明 知覚可能 情報とUIコンポーネントがユーザーに知覚可能な方法で提示されなければならないとい う原則です。視覚・聴覚に頼らなくてもコンテンツを把握できる代替手段を提供すること が求められます。 操作可能 UIコンポーネントとナビゲーションが操作可能でなければならないという原則です。キー ボードのみでの操作や、十分な操作時間の確保、発作を引き起こさないコンテンツ設計な どが含まれます。 理解可能 情報とUIの操作が理解可能でなければならないという原則です。読みやすいテキスト、予 測可能なページ動作、入力を支援する機能などが該当します。 堅牢 コンテンツが支援技術を含む多様なユーザーエージェントによって確実に解釈できるほど 堅牢でなければならないという原則です。
13. WCAG 2．2の全体像(ガイドライン レベルA) 達成基準 概要 1.1.1 非テキストコンテンツ すべての非テキストコンテンツにテキストの代替を提供する 1.2.1 音声のみ・映像のみ（収録済み） 収録済みの音声・映像のみのメディアに代替を提供する 1.2.2 キャプション（収録済み） 収録済み音声コンテンツにキャプションを提供する 1.2.3 音声解説またはメディアの代替（収録済み） 収録済み映像に音声解説またはメディアの代替を提供する 1.3.1 情報および関係性 表示で伝達される情報・構造・関係性をプログラム的に決定可能にする 1.3.2 意味のある順序 コンテンツの正しい読み上げ順序をプログラム的に決定可能にする 1.3.3 感覚的な特徴 指示が形状・色・サイズ・位置・音のみに依存しない 1.4.1 色の使用 色だけを情報伝達の唯一の視覚的手段としない 1.4.2 音声の制御 自動再生される音声を停止・一時停止・音量調整可能にする 2.1.1 キーボード すべての機能をキーボードで操作可能にする
14. WCAG 2．2の全体像(ガイドライン レベルA) 達成基準 概要 2.1.2 キーボードトラップなし キーボードフォーカスが特定のコンポーネントから移動できなくならない 2.1.4 文字キーのショートカット 文字のみのキーボードショートカットを無効化・再割り当て可能にする 2.2.1 タイミング調整可能 時間制限がある場合にユーザーが調整可能にする 2.2.2 一時停止・停止・非表示 動き・点滅・スクロール・自動更新するコンテンツを制御可能にする 2.3.1 3回の閃光またはしきい値以下 1秒間に3回を超える閃光を含むコンテンツを含まない 2.4.1 ブロックスキップ 繰り返されるコンテンツブロックをスキップする手段を提供する 2.4.2 ページタイトル Webページにトピックや目的を説明するタイトルを設定する 2.4.3 フォーカス順序 フォーカス可能なコンポーネントが意味と操作性を保つ順序でフォーカスを受 け取る 2.4.4 リンクの目的（コンテキスト内） リンクテキストまたはその文脈からリンクの目的が判断可能にする 2.5.1 ポインタジェスチャ マルチポイント・パスベースのジェスチャを単一ポインタでも操作可能にする
15. WCAG 2．2の全体像(ガイドライン レベルA) 達成基準 概要 2.5.2 ポインタのキャンセル 単一ポインタ操作のダウンイベントで即座に機能を実行しない 2.5.3 ラベルとアクセシブルネーム UIコンポーネントの視覚的ラベルがアクセシブルネームに含まれる 2.5.4 モーションによる操作 デバイスモーションで操作可能な機能にUIコンポーネントでの代替操作を提 供する 3.1.1 ページの言語 ページのデフォルト言語をプログラム的に決定可能にする 3.2.1 フォーカス時 フォーカスを受け取ったときにコンテキストの変化を開始しない 3.2.2 入力時 設定変更時にコンテキストの変化を自動的に発生させない 3.2.6 一貫したヘルプ ヘルプ機構がページ間で同じ相対的順序で提示される 3.3.1 エラーの特定 入力エラーが自動検出された場合にエラー項目を特定しテキストで説明する 3.3.2 ラベルまたは説明 ユーザー入力が必要な場合にラベルまたは説明を提供する 3.3.7 冗長な入力 同一プロセスで以前入力した情報を再入力させない 4.1.2 名前・役割・値 UIコンポーネントの名前と役割がプログラム的に決定可能である
16. WCAG 2．2の全体像(ガイドライン レベルAA) 達成基準 概要 1.2.4 キャプション（ライブ） ライブ音声コンテンツにキャプションを提供する 1.2.5 音声解説（収録済み） 収録済み映像コンテンツに音声解説を提供する 1.3.4 表示の向き コンテンツが特定の表示向きに制限されない 1.3.5 入力目的の特定 ユーザー情報を収集する入力フィールドの目的をプログラム的に決定可能に する 1.4.3 コントラスト（最低限） テキストと背景のコントラスト比が4.5:1以上（大きなテキストは3:1以上） 1.4.4 テキストのサイズ変更 テキストを200%まで拡大してもコンテンツや機能が損なわれない 1.4.5 文字画像 技術的に可能な場合は文字画像ではなくテキストを使用する 1.4.10 リフロー 320CSSピクセル幅（横スクロールコンテンツは256CSSピクセル高）で2方 向のスクロールを必要としない 1.4.11 非テキストのコントラスト UIコンポーネントとグラフィックのコントラスト比が3:1以上 1.4.12 テキストの間隔 行の高さ・段落間隔・文字間隔・単語間隔を調整してもコンテンツや機能が損 なわれない 1.4.13 ホバーまたはフォーカスで表示されるコン テンツ 追加コンテンツを解除可能・ホバー可能・持続的にする
17. WCAG 2．2の全体像(ガイドライン レベルAA) 達成基準 概要 2.4.5 複数の手段 Webページセット内のページを見つける方法が複数提供される 2.4.6 見出しおよびラベル 見出しとラベルがトピックまたは目的を説明する 2.4.7 フォーカスの可視性 キーボード操作可能なUIのフォーカスインジケータが視覚的に確認可能であ る 2.4.11 フォーカスの遮蔽防止（最低限） フォーカスを受けたコンポーネントが作成者のコンテンツにより完全に隠され ない 2.5.7 ドラッグ操作 ドラッグ操作を使用する機能にドラッグなしの代替手段を提供する 2.5.8 ターゲットサイズ（最低限） ポインタ入力のターゲットサイズが24×24CSSピクセル以上 3.1.2 部分的な言語 各文節やフレーズの言語をプログラム的に決定可能にする 3.2.3 一貫したナビゲーション ナビゲーションが複数ページで同じ相対的順序で繰り返される 3.2.4 一貫した識別 同じ機能を持つコンポーネントが一貫して識別される 3.3.3 エラーの修正候補 入力エラーが自動検出され修正候補が分かる場合はそれを提供する
18. WCAG 2．2の全体像(ガイドライン レベルAA) 達成基準 概要 3.3.4 エラーの防止（法的・金銭的・データ） 法的義務等を伴うページでは操作の取り消し・検証・確認のいずれかを提供す る 3.3.8 アクセシブルな認証（最低限） 認証プロセスで認知機能テストを要求しない（代替手段またはメカニズムを提 供） 4.1.3 ステータスメッセージ ステータスメッセージをrole等でプログラム的に決定可能にする
19. WCAG 2．2の全体像(ガイドライン レベルAAA) 達成基準 概要 1.2.6 手話（収録済み） 収録済み音声コンテンツに手話通訳を提供する 1.2.7 拡張音声解説（収録済み） 映像の前景音声の間に十分な間合いがない場合に拡張音声解説を提供する 1.2.8 メディアの代替（収録済み） 収録済み同期メディア・映像のみのメディアに代替を提供する 1.2.9 音声のみ（ライブ） ライブ音声コンテンツに同等情報の代替を提供する 1.3.6 目的の特定 UIコンポーネント・アイコン・リージョンの目的をプログラム的に決定可能にす る 1.4.6 コントラスト（強化） テキストと背景のコントラスト比が7:1以上（大きなテキストは4.5:1以上） 1.4.7 背景音が小さいまたは無し 前景音声に対して背景音を20dB以上低くする 1.4.8 視覚的な表現 テキストの前景色・背景色・行幅・配置・行間・サイズをユーザーが調整可能にす る 1.4.9 文字画像（例外なし） 純粋な装飾または本質的な場合を除き文字画像を使用しない 2.1.3 キーボード（例外なし） すべての機能がキーボードで特定のタイミングなしに操作可能である
20. WCAG 2．2の全体像(ガイドライン レベルAAA) 達成基準 概要 2.2.3 タイミング不要 タイミングがコンテンツに必須の要素ではない 2.2.4 中断 緊急時を除きユーザーが中断を延期・抑制可能にする 2.2.5 再認証 認証セッション期限切れ後にデータを失わずに活動を継続可能にする 2.2.6 タイムアウト データ損失の原因となるタイムアウトを事前に警告する 2.3.2 3回の閃光 1秒間に3回を超えて閃光するコンテンツを含まない 2.3.3 インタラクションによるアニメーション インタラクションで発生するモーションアニメーションを無効化可能にする 2.4.8 現在位置 ページセット内におけるユーザーの現在位置情報を提供する 2.4.9 リンクの目的（リンクのみ） リンクテキストのみからリンクの目的を特定可能にする 2.4.10 セクション見出し セクション見出しでコンテンツを構成する 2.4.12 フォーカスの遮蔽防止（強化） フォーカスを受けたコンポーネントのいかなる部分も隠されない
21. WCAG 2．2の全体像(ガイドライン レベルAAA) 達成基準 概要 2.4.13 フォーカスの外観 フォーカスインジケータが十分な面積とコントラストを持つ 2.5.5 ターゲットサイズ（強化） ポインタ入力のターゲットサイズが44×44CSSピクセル以上 2.5.6 同時入力メカニズム プラットフォームで利用可能な入力モダリティの使用を制限しない 3.1.3 珍しい用語 特殊な意味で使用される用語の定義を特定する仕組を提供する 3.1.4 略語 略語の展開形式や意味を特定する仕組を提供する 3.1.5 読解レベル 中学校教育修了レベルを超える読解力を要するテキストに補足コンテンツを 提供する 3.1.6 発音 文脈上意味が曖昧になる単語の発音を特定する仕組を提供する 3.2.5 要求による変化 コンテキストの変化はユーザーの要求によってのみ開始される 3.3.5 ヘルプ コンテキストに応じたヘルプを利用可能にする 3.3.6 エラーの防止（すべて） ユーザーが情報を送信するすべてのページで取り消し・検証・確認のいずれか を提供する 3.3.9 アクセシブルな認証（強化） 認証プロセスで認知機能テストを要求しない（オブジェクト認識・個人コンテン ツの例外なし）
22. 支援技術の種類 • スクリーンリーダー • 拡大鏡・画面拡大 • 音声認識 • スイッチデバイス • 点字デバイス
23. なぜ、開発当初に意識すべきか • 情報構造や操作フローはあとから変更することはとても工数がか かる。 • きちんと設計されたHTML要素は支援技術と相性がとてもよい。
24. 意味のあるHTML要素を正しく使う 要素 役割 用途 <header> banner ページやセクションのヘッダー <nav> navigation 主要なナビゲーション <main> main ページの主要なコンテンツ(ページに一つ) <aside> complementary 補足情報（サイドバーなど） <footer> contentinfo ページやセクションのフッター <section> region 見出し付きのセクション
25. 見出しの階層 • <h1>から<h6>は飛ばさず、論理的な階層で使います。 • スクリーンリーダーは見出し一覧でページ構造を把握するので正 しい階層が重要です。 <h1>サイト名</h1> <main> <h2>記事タイトル</h2> <section> <h3>セクション1</h3> <p>本文...</p> </section> </main>
26. UIフレームワークに見るアクセシビリティ • UIフレームワークはその設計原則をそのまま取り入れることがア クセシビリティを考える上でとても大事な要素です。 • 構造と階層：見出しを論理順に配置してスキャンしやすい情報構造を作る。 • キーボード操作と支援技術：ダイアログなど一時的UIのあとにフォーカス を失わないように管理する。 • 色とコントラスト：本文は4.5:1以上、見出しは3:1以上で設計する。 • レスポンシブとズーム：最大400%のズームでも横スクロールなしで再配 置される設計を意識する。 • 代替手段：画像には適切なテキスト。動画には字幕や視認性の高いテキス トを用意する。 • 意味のある文言：簡潔で明確な文を使い、内容が重複しないようにする。
27. 代表的コンポーネント（Button） • クリック対象には明確なラベルを付ける。 • アイコンのみの場合は補助テキストを用意する。 • 無効化と読み上げの意味がずれないよう見た目だけで無効にし ない。 • フォーカスリングを消さず、キーボード操作で常に視認できるよう にする。
28. 代表的コンポーネント（Input） • ラベルは必ずつける。 • プレースホルダーをラベルの代替にしない。 • エラーを色だけで示さず、メッセージ文で理由と対処を伝える。 • 入力補助を一貫した場所で提供する。
29. 色覚多様性を前提にする設計 • 色は情報の伝達に便利ですが色覚の違いがあると「同じ色に見え る」「区別できない」という状況が起こります。 • 色覚多様性を前提にした設計では次のようなポイントが有効です。 • 状態を色だけで示さず、アイコンやテキストラベルを併用する。 • グラフやタグは模様・線種・形状で区別できるようにする。 • エラーや警告は色に加えて説明文を添える。 • 背景と文字色の組み合わせはコントラスト比で検証する。 • UIの境界線やフォーカス文字も3:1を目安に検証する。
30. 多様な色覚異常に対応する • 色覚には複数のタイプがある。 →誰にとっても識別できる設計が重要 • Microsoft Edge DevToolsのRenderingツールには 「Emulate vision deficiencies」機能があり以下の色覚シ ミュレーションが可能です • Protanopia（1型色覚） • Deuteranopia（2型色覚） • Tritanopia（3型色覚） • Achromatopsia（全色盲） • Blurred vision（ぼやけ）
31. 点滅の制限(WCAG 2.3.1 レベルA) • 1秒に3回を超える点滅はてんかん発作を誘発する危険がありま す。 →私を倒したければこんな画面を設計するとたまに意識消失して 倒れているかもしれません！ • WCAGでは一般的な閃光について厳格な制限が定められていま す。 • 1秒間に3回を超えて点滅しない • 閃光の面積を画面の10％未満に抑える
32. Webアクセシビリティのテスト方法 • アクティビティは実装だけでなくテストで担保することが重要 • 最低限以下のようなテストをすることが望ましい • キーボード操作テスト • スクリーンリーダーテスト • ズーム・リフローテスト • コントラストチェック • 色依存チェック
33. 自動テストと手動テスト • 自動テストの例 • Axe DevToolsでCIを回す • Lighthouseツールでアクセシビリティスコアとレポートを生成する • 手動テストの例 • キーボード移動で操作のつまりやフォーカスの欠落を確認 • 画面幅を小さくしたりレイアウト崩れや可読性を確認 • スクリーンリーダーで読み上げ順序・意味・状態が伝わるかを確認 • 音声認識やハイコントラストモードでも操作が破綻しないかを確認
34. Lighthouseツール
35. Emulate vision deficienciesで確認
36. Axe DevTools • アクセシビリティを自動検査するためのツール群 • ブラウザー拡張やCI向けの実行環境が提供されている • GitHub Actionsなどで回帰検知の仕組みを作る
37. 必要なのはアクセシビリティへの姿勢 • アプリケーション自体の改善や機能追加に伴いアクセシビリティが 一時的に損なわれることはよくあることです。 • 問題は膨大でとてもコストがかかることがしばしばあります。 • 特に手動での回帰テストで実証するほかないところはなおさら • そんな中でも常に問題を認識して常に改善に取り組んでい ることが大事と考えます。 • ソフトウェアに100％はないですし。。。
38. いつものチャットアプリに対してアクセシ ビリティ対応してみた！ • GitHub Copilotに 「WCAG2.2 AAに準拠するようにアクセシビリティ対応してくだ さい。必要ならばFluent UI Blazorのドキュメントを参照してく ださいとしてURLを添付」 以上のプロンプトでお願いしました
39. 結果 • Lighthouseの自動検査結果 • 違反箇所を見てみたらGoogleの広告とコントラスト比不足の指 摘 →コントラスト比不足については再度GitHub Copilotに修正依 頼で改善
40. 次回予告 axe DevTools（Playwright C#統合）の話
41. 宣伝 おしまい
42. 【劇場版】アニメから得た学びを発表会 2026(4/11)
43. シアトルに行ってきたバー @ エデン日暮里 (4/3) 収益でいらないもの交換会が豪華になります
44. くさば生誕祭 @ エデン日暮里(６/2６) 収益でいらないもの交換会が豪華になります
45. おしまい おしまい