Webアクセシビリティ入門 2026

2026年度リクルート エンジニアコース新人研修の講義資料です。

1. Webアクセシビリティ入門 2026 雫石 卓耶（@sititou70）
2. 事前準備（1/2） • 以下の環境をセットアップしてください。 PC：Mac ◦ ▪ Node.js（24.16.0） ▪ pnpm（11.4.0） ◦ ブラウザ：Chrome（最新） ◦ エディタ：Visual Studio Code（最新） ▪ • 推奨ですが、別のエディタでも構いません PCから音を出す演習があります。当日は、イヤホン/ヘッドホンを用意してくだ さい 2
3. 事前準備（2/2） • 以下の手順でVoiceOverが起動することを確認してください 1. 適当なWebサイトを開きます 2. 以下のいずれかの方法でVoiceOverを起動します ▪ command + F5 ▪ command + Touch IDを素早く3回 ▪ システム環境設定 > アクセシビリティ > VoiceOver > VoiceOverを有効にする チェックボックス 3. VoiceOverのチュートリアルが表示された場合は、それを行うかスキップし、次回からは 表示されないようにします 4. 適当なWebサイトのテキストの一部を選択し、それが読み上げられることを確認します 5. 起動時と同じ方法でVoiceOverを終了します 3
4. 自己紹介（講師） • 名前：雫石 卓耶（しずくいし たくや）@sititou70 • 株式会社リクルートに2021年新卒入社 • 所属： ◦ 株式会社インディードリクルートテクノロジーズ ◦ Technology 3部 • 普段：チームのテックリードとして設計やレビューなど • 好きなもの：アクセシビリティ ◦ ◦ 勉強したり ▪ 本 / ガイドラインを読む ▪ Trusted Tester：TT-2404-05928 チームに布教したり ▪ • フローリングの アイコンが私 レビュー / テスト整備 / ドキュメント作成 よろしくお願いします 4
5. 自己紹介（サポート講師） • 名前：眞野 隼輔（まの しゅんすけ）@progfay • 株式会社リクルートに2020年新卒入社 • 所属： ◦ 株式会社リクルート ◦ ビューティー開発 1G • 普段：SALONBOARD の技術刷新と横断的な技術支援 • 趣味：Web 動向を追う、漫画を読む まのさん 5
6. 自己紹介（サポート講師） • 名前：水足 友紀（みずたり ともき）@txxm_443 • 株式会社リクルートに2023年新卒入社 • 所属： ◦ 株式会社インディードリクルートテクノロジーズ ◦ Technology 3部 • 普段：FEからインフラに転生。Terraformと格闘 • 趣味：コーヒー、雑草、インテリア みずたりさん 6
7. 研修の目的 / ゴール アクセシビリティの • 「定義・重要性」がわかるようになる • 「基準・ガイドライン」について、自分で調べられる状態になる • 「改善・検証方法」についての演習を通して、 ◦ アクセシブルでないコンテンツの雰囲気を知る ◦ 改善する具体的な方法について、知識のインデックスを作る 7
8. 研修の目的 / ゴール アクセシビリティの • 「定義・重要性」がわかるようになる • 「基準・ガイドライン」について、自分で調べられる状態になる • 「改善・検証方法」についての演習を通して、 ◦ アクセシブルでないコンテンツの雰囲気を知る ◦ 改善する具体的な方法について、知識のインデックスを作る 8
9. 定義 • accessibility = access + ability • accessibility = アクセス + できること（またはその程度のこと） • a11yと略される ◦ aとyの間に文字が11個あるから 参考：ウェブアクセシビリティ導入ガイドブック, デジタル庁, 2022。以降の出典ではタイトルだけ記載 9
10. Webはアクセシブル • 情報媒体の中で考えると、Webコンテンツはかなりアクセシブルです。 ◦ • 例：出版物 ◦ • いつでも、どこでも、いろいろなデバイスからアクセスできる その出版物が販売されている場所と時間で入手しないといけない 例：スマホのアプリ ◦ PCや、対応していないスマホからは使えない場合がある • アクセシブルであることは、Webの大きな利点の1つです • しかし、Webコンテンツの作り方によっては、a11yが低くなってしまいます 10
11. Web a11yが低い例 • Aさんはロービジョン（弱視）の障がいを持っている • あるサイトの文章は、Aさんが読むにはコントラストが低い ◦ • →最低限のコントラストを考慮してデザインすればよかった Aさんは、視覚的に文章を読むのを諦めた。代わりにスクリーンリーダーを使用 して読み上げ音声を聞こうとした。しかし文章はすべて文字画像で、alt属性など は指定されていなかった ◦ • →適切な代替テキストがあればよかった 結果的に、このサイトはAさんにとってa11yが低かったと言える 11
12. 重要性：なぜa11yを改善すべきなのか？ • 代表的なものをピックアップして紹介します ◦ アクセスできない / しにくい人を減らすため ◦ SEO対策のため ◦ さまざまなデバイスに対応するため ◦ UX改善のため 参考：太田良典, 伊原力也, デザイニングWebアクセシビリティ, 株式会社 ボーンデジタル, 2016。以降の出典ではタイトルだけ記載 12
13. アクセスできない / しにくい人を減らすため（1/5） • • a11y改善がメリットとなる障がい者の数*1 ◦ 国内だけで428.7万人 ◦ 視覚 / 聴覚 / 言語 / 内部障がい、肢体不自由など 総人口で割ると ◦ 428.7万人 / 12,399万人*2 ≒ 3.4% ◦ 100人アクセスしたら3人にメリットあり？ ▪ 意外に多いと思いませんか？ *1：ウェブアクセシビリティ導入ガイドブックより。*2：人口推計, 2024年2月報, 総務省統計局 , 2024 13
14. アクセスできない / しにくい人を減らすため（2/5） • 障がい者ではないがa11y改善がメリットになる人 ◦ クイズ：そのような例を思いつくだけ挙げてみてください ▪ （時間：1分） ▪ ヒント： • 例えば目が見えづらい原因は、障がい以外に何かありますか。 • 他にも、音が聞こえづらい、操作が難しい、などについてはどうで すか。 14
15. アクセスできない / しにくい人を減らすため（3/5） • 障がい者ではないがa11y改善がメリットになる人の例 ◦ メガネを忘れてきた / 壊れている ◦ 陽の光が眩しくて画面の色を認識しづらい ◦ 高齢になり、最近目が悪くなってきた ▪ →コントラストが強く、文字が大きいほうが良い ◦ 電車が揺れてスマホでのポインティングが難しい ◦ 最近PCを買ってみた。マウスの操作にはまだ慣れていない ▪ →リンクやボタンが大きめだとうれしい 15
16. アクセスできない / しにくい人を減らすため（4/5） • 障がい者ではないがa11y改善がメリットになる人の例 ◦ イヤホンを忘れてきた / 充電切れ / つけるのが面倒 ◦ 周りがうるさくて音が聞こえない ▪ →動画や音声コンテンツに、字幕や書き起こしがあるとうれしい ◦ 一時的に腕を怪我していてマウスが使えない ◦ マウスを使うだけのスペースが無い、またはマウスを忘れてきた 16
17. アクセスできない / しにくい人を減らすため（5/5） • 障がい者ではないがa11y改善がメリットになる人の例 ◦ 単純にキーボード操作が好き ▪ ◦ →キーボードで操作できると良い 別の言語を話すユーザー ▪ →文字画像などは翻訳できないので困る ▪ →ソースコードが<code>で実装されていないと、変数名まで翻訳の対 象に ▪ ◦ →英語の音声/動画にキャプションや書き起こしがあると翻訳できる リンク先を別タブで開きたい ▪ →「新しいタブで開く」やCtrl + クリック / Cmd + クリックしたいの に、<button>や<div>へのonClickで実装されているので開けない！ 17
18. さまざまなデバイスに対応するため • a11yの基準を守っていると、特殊なデバイスにも対応できる場合がある • 2.5.5 ターゲットのサイズ (高度)：ボタンやリンクなど、ポインタのターゲット が一定よりも大きいこと • ◦ →ポインティングが普通より難しいデバイスに対応 ◦ 例：家庭用ゲーム機Wiiのブラウザ、Wiiリモコンでポインティングする 達成基準 1.4.3 コントラスト (最低限)：ページの色使いに一定以上のコントラス トがあり、はっきり見えること ◦ →白黒表示のデバイスに対応 ◦ 例：Kindle端末、モノクロ印刷機 18
19. SEOのため（1/3） • a11y改善とSEOの方法には共通する部分が多い • 例1：titleタグ • ◦ SEO：<title> 要素に具体的でわかりやすいテキストを記述する*1 ◦ a11y：ウェブページには、主題又は目的を説明したタイトルがある*2 例2：alt属性 ◦ SEO：画像に alt 属性を指定することでユーザーが目的のコンテンツを見つけやす くなる*3 ◦ a11y：利用者に提示されるすべての非テキストコンテンツには、同等の目的を果 たすテキストによる代替が提供されている*4 ▪ 非テキストコンテンツ：画像など ▪ テキストによる代替：alt属性など *1：最適なタイトルリンクを出しやすくするためのベストプラクティス, Google。*2：WCAG 達成基準 2.4.2 ページタイトル, W3C。*3：Google 画像検索 SEO ベストプラクティス, Google。*4：WCAG 達成基準 1.1.1 非テキストコンテンツ, W3C 19
20. SEOのため（2/3） • クイズ：なぜa11y改善とSEOには共通点が多いのでしょうか？ ◦ （時間：1分） 20
21. SEOのため（3/3） • 1つの答え：適切に（セマンティックに）作成されたWebコンテンツがマシン リーダブルであり、検索やa11yに役立つから • 例：画像に適切なalt属性をつけると…… ◦ Googleボット「これは画像を表すテキストなんだな。画像検索のキーワード として活用しよう」 ◦ スクリーンリーダー「これは画像を表すテキストなんだな。画像について ユーザーに説明するときに使おう」 21
22. 注意：マシンリーダブルは基礎 • SEOでは、マシンリーダビリティに加えて ◦ そもそも需要の高いコンテンツを用意する ◦ 他のサイトに支持されるようなコンテンツを用意する ◦ etc…… • といったことも必要 • →基礎もその先もどちらも大事 22
23. UX改善のため • a11yとUXの関係を説明するとき によく登場する図*1 • ある段は、その上の段の前提に なっている • 下から上への時系列があると思っ ても良い *1：Evaluation method of UX “The User Experience Honeycomb”より引用 23
24. UXの例（1/5）：アクセスしやすい • 例：自宅のプリンター（型番：PRT-12345-67）が壊れてしまったので解決策を 探したい • まず、検索エンジンで「PRT-12345-67 説明書」を調べた • 「PRT-12345-67の取扱説明書 | 家庭用プリンタ」というtitleのサイトがヒット した • 目的に合致するページが見つかったので、それにアクセスした 24
25. UXの例（2/5）：アクセスしやすい • title要素が適切でない例 ◦ 「新しいドキュメント」というtitle ▪ ◦ 「PRT-12345-67 | 家庭用プリンタ」というtitle。内容はPR動画 ◦ 「PRT-12345-67 | 家庭用プリンタ」というtitle。内容は消耗品案内 ◦ 「PRT-12345-67 | 家庭用プリンタ」というtitle。内容は説明書 ▪ • →何のページかわからない →あいまい。どれにアクセスすればいいかわからない →今回はtitle要素が具体的でわかりやすかったため、アクセスしやすかった 25
26. UXの例（3/5）：利用しやすい • Webページはシンプルで、必要な情報のみが表示されていた。 • PDFへのリンクを見つけやすかった 26
27. UXの例（4/5）：安心しやすい • 説明書を読んでみた • 説明書には製造元の会社名が記載されており、信頼できそうだ • 「困ったときは」という章には、自分の問題の解決方法が記載されていた • 解決方法を実施したところ、実際にプリンターが復活した ◦ →役に立つ情報だった 27
28. UXの例（5/5）：満足しやすい • このWebサイトに価値を感じ、良い印象を持った 28
29. a11yは土台 • a11yが悪いと、そのあと全てのUXの足を引っ張ってしまう a11yが悪いと 29
30. 研修の目的 / ゴール アクセシビリティの • 「定義・重要性」がわかるようになる • 「基準・ガイドライン」について、自分で調べられる状態になる • 「改善・検証方法」についての演習を通して、 ◦ アクセシブルでないコンテンツの雰囲気を知る ◦ 改善する具体的な方法について、知識のインデックスを作る 30
31. a11yの基準・ガイドライン • 結論：私達が意識すべきa11yのガイドラインはWCAG ◦ • WCAGは「うぃーきゃぐ」と発音することも多い W3Cが作成している ◦ W3C：Webの標準やガイドラインを策定している団体 31
32. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 出典：Essential Components of Web Accessibility 32
33. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 Webコンテンツの提供者 例：デザイナー、コーダー、Webエンジニア、ブロガー… 出典：Essential Components of Web Accessibility 33
34. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 Webコンテンツ 例：Webページ 出典：Essential Components of Web Accessibility 34
35. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 これらを使って Webコンテンツを作成する これらを使ってWebコンテンツを作成する 出典：Essential Components of Web Accessibility 35
36. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 Webサイトを作るソフトウェア 例：CMS、ブラウザのDev Tools、テキストエディタ、 HTML WYSIWYGエディタ… 出典：Essential Components of Web Accessibility 36
37. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 Web a11yの評価ツール 例：HTMLバリデータ、CSSバリデータ… 出典：Essential Components of Web Accessibility 37
38. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 ユーザー 例：Webページの閲覧者 出典：Essential Components of Web Accessibility 38
39. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 これらを使ってWebコンテ これらを使って Webコンテン ツを閲覧する ンツを閲覧する 出典：Essential Components of Web Accessibility 39
40. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 ブラウザ、メディアプレーヤー （またはその他の「ユーザーエー ジェント」） 出典：Essential Components of Web Accessibility 40
41. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 支援技術 例：スクリーンリーダー、点字ディスプレ イ、その他の特別な入出力装置… 出典：Essential Components of Web Accessibility 41
42. アクセシビリティガイドライン • 先程のコンポーネントのうち、3つにアクセシビリティガイドラインがある 出典：Essential Components of Web Accessibility 42
43. ATAG • ATAG：オーサリングツール・アクセシビリティガイドライン（日本語訳） ◦ 例：オーサリングツールは画像にalt属性を指定する手段を提供すべき WordPressでaltテキストを設定しているところ 43
44. WCAG • WCAG：Web コンテンツ・アクセシビリティガイドライン（日本語訳） ◦ 例：Webコンテンツ内の画像にはalt属性があるべき 44
45. UAAG • UAAG：ユーザーエージェント・アクセシビリティガイドライン（日本語訳） ◦ 例：ユーザーエージェントは、画像の代わりにalt属性のテキストを表示する ような設定を持つべき • ありうる事例：「Tylerは、学習障害があり、画像はとても気を散らす。彼は、画 像の代わりに代替テキストを常に表示するようにブラウザーの設定を行う。」*1 *1：https://imagedrive.github.io/TR/UAAG20-Reference/#sc_113より引用 45
46. UAAG 出典：https://addons.mozilla.org/ja/firefox/addon/image-block/より 46
47. どのコンポーネントが欠けてもだめ • 以下の全てが連動することで、ユーザーはaltテキストを利用できるようになる • 私達はWebコンテンツの製作者なので、WCAGを意識することでWeb a11yの達 成に貢献できる 47
48. WCAGの歴史：WCAG 1.0 • 1999-05-05勧告 ◦ • 昔！！！ 「ブラウザが〇〇できるようになるまで〜〜という対処をしてください」という 記述がある • 2021-05-18に廃止 48
49. WCAGの歴史：WCAG 2.0 • 2008-12-11勧告 ◦ 1.0の勧告から約8.5年 • 構造を刷新、より現代的なWebの環境に対応 • 61個の達成基準（a11yを達成するための要件） • 標準化 ◦ ISO/IEC 40500:2012と互換 ◦ JIS X 8341-3:2016と互換 ▪ クイズ：8341という番号は、ある理由によって選ばれました。その理 由とは？（時間：30秒） 49
50. WCAGの歴史：WCAG 2.0 • 2008-12-11勧告 ◦ 1.0の勧告から約8.5年 • 構造を刷新、より現代的なWebの環境に対応 • 61個の達成基準（a11yを達成するための要件） • 標準化 ◦ ISO/IEC 40500:2012と互換 ◦ JIS X 8341-3:2016と互換 ▪ →「やさしい（8341）」の語呂合わせらしいです 50
51. WCAGの歴史：WCAG 2.1 • 2018-06-05勧告 ◦ • 2.0の勧告から約9.5年 78個の達成基準 ◦ 17個の基準を追加 • モバイルデバイスを考慮 • 弱視、認知障害、学習障害のための基準を追加 51
52. WCAGの歴史：WCAG 2.2（最新） • • • 2023-10-05に勧告 ◦ 2.1の勧告から約5年 ◦ 現状勧告されているWCAGの中で最新 86個の達成基準 ◦ 2.1の1つの基準を廃止*1 ◦ 9個の基準を追加 フォーカス、入力操作と支援、認証、ヘルプについて基準を追加 *1：詳細：How and why is success criteria 4.1.1 Parsing obsolete? 52
53. WCAGの歴史：WCAG 3.0（作成中） • 完成はあと数年後 ◦ リポジトリのコミットを見る限り、2018-04頃から作成に取り掛かっていた 様子*1 ▪ • WCAG 2.1勧告のちょっと前 構造を刷新 ◦ 草案には、VR（仮想現実）やAR（拡張現実）といった単語も見られる *1：リポジトリ：https://github.com/w3c/silver 53
54. WCAG 2.2の読み方 • 実際にWCAG 2.2（日本語訳）を開いていっしょに読んでみましょう 54
55. 例：画像におけるalt属性の必要性を知りたいとします まず、画面左にあるサイドバーから全体の 構成を把握しましょう 55
56. 達成基準と分類 • ガイドラインは達成基準で構成されます*1 ◦ • • 達成基準：a11yを達成するための要件 達成基準は大きく4つに分類されています ◦ 知覚可能 ◦ 操作可能 ◦ 理解可能 ◦ 堅牢 alt属性は、その画像が何なのかを知覚するためのもの ◦ →「知覚可能」を見れば良さそう *1：以降は、WCAG 2.2の場合の話で、他のバージョンには当てはまらない場合があります 56
57. 今回は「非テキストコンテンツ」がそれっぽい それっぽい 57
59. 達成基準：a11yを達成するための要件 59
60. • レベルA：基準の分類。より優先して満たすべき基準はA。そこからAA、AAA と続く。 • 適合レベル ◦ レベルAに適合：レベルAの基準を満たすこと ◦ レベルAAに適合：A + AAの基準を満たすこと ◦ レベルAAAに適合：A + AA + AAA、つまりすべての基準を満たすこと ◦ 「このサイトはWCAG 2.2 レベルAに適合している」などという 60
62. 「非テキストコンテンツ」をクリック →例：画像（文字画像含む）、音声、映像、ASCIIアート、顔文字など 62
63. 「テキストによる代替」をクリック →alt属性などのテキストのこと 63
64. →画像（など）にはalt属性（など）を指定すべきという ことがわかります 64
65. 理解のための追加の文書がある。 65
67. • 67
68. • 68
69. • 例：フォントを用いて画面にレンダリングする 69
70. • 例：合成音声で読み上げる 70
71. • 例：点字ディスプレイで表示する 71
72. • 72
73. • 73
74. • 将来に対する展望も書かれている 74
75. • 事例：テキストと手話を相互変換する取り組みがある https://github.com/sign/translate 75
76. • AIによるテキストの要約は、今日では広く普及している （一方、この文書が最初に登場したのはWCAG 2.0で、2008年ごろ） 76
77. • →なぜその基準が必要なのかわかる 77
78. • →alt属性が使えない場合は、他の方法もあるとわかる 78
79. • 更に読んでみる 79
80. • 具体的なコード例がある 80
81. 研修の目的 / ゴール アクセシビリティの • 「定義・重要性」がわかるようになる • 「基準・ガイドライン」について、自分で調べられる状態になる • 「改善・検証方法」についての演習を通して、 ◦ アクセシブルでないコンテンツの雰囲気を知る ◦ 改善する具体的な方法について、知識のインデックスを作る 81
82. a11y改善演習 • WCAG 2.2から、特に業務で扱いそうな基準をピックアップしました ◦ • 各基準にわざと失敗させた演習サイトを用意しました ◦ • 一部の基準を要約して紹介します 株式会社Komaru：架空のWeb制作会社 進捗確認をしながら進めます：Slackに+1（👍）でリアクションください 82
83. 環境構築：演習サイトのbadブランチを起動する • 「セットアップ」と「起動」の手順を実行します ◦ • できない方はSlackで教えてください 起動できたら ◦ 一通りコンテンツを眺めてみましょう ◦ どのようなコンテンツがありますか？ ▪ ◦ ヒーローヘッダー、ナビゲーション、サービス…… 「ここはa11yが低そうだな」と思われる場所はありますか？ 83
84. さっそくa11yを改善していきましょう 84
85. コントラスト比 • 2つの色の間で計算される比率 • 値が大きいほど、コントラストが高い、色を識別しやすいことを表す • 計算ツールがいろいろある。例：Contrast Checker, WebAIM • 例えばRedとBlackでは： ◦ 5.25:1のコントラスト比（または単に5.25とも書く） 85
86. 1.4.3、1.4.11 コントラスト（AA） • • テキスト*1 ◦ ⭕サイズの大きなテキストに3:1以上のコントラスト比がある ◦ ⭕そうでないテキストに4.5:1以上のコントラスト比がある ◦ サイズの大きなテキスト*2 ▪ 英語の場合：約24px以上の通常の文字、または約18.6px以上の太字 ▪ 日本語の場合：約29px以上の通常の文字、または約24px以上の太字 ⭕非テキスト：以下について、隣接する色に3:1以上のコントラスト比がある*3 ◦ ユーザーインターフェースコンポーネント*4、およびその状態の特定 ◦ コンテンツを理解するのに必要なグラフィック *1：達成基準 1.4.3 コントラスト (最低限)、*2：サイズの大きなテキスト、*3：達成基準 1.4.11 非テキストのコントラスト、*4：単一のコントロールとして利用者が知覚するもの。テキストボックスやラジオボタンが含まれる 86
87. 1.4.6 コントラスト（AAA） • テキスト*1 ◦ ⭕サイズの大きなテキストに4.5:1以上のコントラスト比がある ◦ ⭕そうでないテキストに7:1以上のコントラスト比がある *1：達成基準 1.4.6 コントラスト (高度) 87
88. クイズ：コントラスト • 現状のサイトで、十分なコントラスト（AA）に失敗している箇所はどこですか 88
89. クイズ：コントラスト（回答例） • サイズの大きなテキストではない訪問済みリンク ◦ 背景が画像の場合は、コントラスト比が 最も低くなる場所で計測する • 本文内の各H2テキスト • ラジオボタンにおける状態の認識 ◦ チェック状態 / 非チェック状態の差が 塗り色だけで、そのコントラストが低い • アンケート結果のグラフ 89
90. 改善例：コントラスト • 訪問済みリンクの色を濃くする*1 diff src/styles/variables.css --color-link: #002e33; - --color-link-visited: #d53f7d; + --color-link-visited: #531d46; } *1：スタイルや文言の変更は、本来の業務であれば関係各所に相談のうえで行います。今回は演習なので、我々の判断で自由に行えるものとします 90
91. 改善例：コントラスト • H2のスタイルを修正する diff src/styles/global.css h2 { flex-wrap: wrap; column-gap: 0.5em; width: fit-content; - color: var(--color-accent); + color: var(--color-base); 参考：テキスト (及び文字画像) とその背景の間に、少なくとも 3:1 のコントラスト比を確保する 91
92. 改善例：コントラスト • ラジオボタンのスタイルを修正する diff src/styles/campaign.css @@ -59,7 +59,7 @@ height: 0.7em; - background-color: var(--color-main); + background-color: var(--color-base); border-radius: 50%; 参考：色の使用とフォーカスの可視化との関係性 92
93. 改善例：コントラスト • 例1：グラフのスタイルを変えてコントラスト比を確保する • 例2：数値を記載するなどして、扇形を認識する必要を無くす • 今回は両方採用してみる diff src/index.html - <img src="/assets/graph.jpg" /> + <img src="/assets/graph2.jpg" /> 参考：グラフィカルオブジェクト 93
94. ここまでの改善を実装してみましょう 94
95. 1.4.1 色の使用 • ⭕色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別する ための唯一の視覚的手段になっていない。 95
96. クイズ：色の使用 • 現状のサイトで、この基準に失敗している場所はどこですか？ ◦ ヒント：この基準の失敗例を見てみましょう 96
97. クイズ：色の使用（回答例） • リンクであることを色だけで伝えている ◦ • 周囲のテキストとの十分なコントラストも無い フォームの必須要素を色だけで伝えている 参考：達成基準 1.4.1 の失敗例 － 色覚なしで視覚的にはっきりと分からないリンクを作成する、達成基準 1.4.1 の失敗例 － 色の違いだけで、必須又はエラーフィールドを特定している 97
98. 改善例：色の使用 • リンクに下線をつける diff src/styles/footer.css - a { - diff src/styles/service.css display: block; text-decoration: none; padding: 10px 50px 10px 20px; } max-width: 500px; diff src/styles/navigation.css - text-decoration: none; font-size: 3rem; - text-decoration: none; diff src/styles/works.css position: relative; display: block; min-width: 400px; - text-decoration: none; 参考：文字色の違いが情報を伝えるために使用される場合に、利用可能な追加の視覚的な手がかりを確保する 98
99. 改善例：色の使用 • フォームの必須要素をテキストでも伝えるようにする diff src/index.html <form> - <p>色のついた項目は必須です</p> 氏名：<input name="name" /> <label class="tel"> - <span class="required">電話番号：</span> + <span class="required">電話番号（必須）：</span> 参考：色のついたフォームコントロールのラベルに対して、テキストによる手がかりを含める 99
100. ここまでの改善を実装してみましょう 100
101. 1.4.10 リフロー • 縦スクロールコンテンツ ◦ • 横スクロールコンテンツ ◦ • ⭕画面の幅を320pxにしたとき、横スクロールを必要としないこと ⭕画面の高さを256pxにしたとき、縦スクロールを必要としないこと ただし、利用や意味の理解に2次元のレイアウトが必須である一部のコンテンツ を除く。 ◦ 例：複雑な表など 101
102. 2.5.5、2.5.8 ターゲットのサイズ • ⭕ポインタ入力のターゲットのサイズが44 × 44px以上である（AAA） • ⭕ポインタ入力のターゲットのサイズが24 × 24px以上である（AA） • ただし、いくつか例外ケースがある*1 ◦ 同じ機能の大きいボタンがある ◦ インラインである：リンク、文中のボタンなど ◦ ブラウザが提供する機能をそのまま使っている *1：ここに記載した以外にも例外のケースがある。詳しくはWCAGを参照 102
103. リフロー、ターゲットのサイズ（AAA）に失敗している箇所はどこですか？ 改善例を考え、実装してみましょう 103
104. 改善例：リフロー、ターゲットのサイズ • min-widthを削除する • ボタンを大きくする diff src/styles/works.css a { position: relative; display: block; - min-width: 400px; diff src/index.html - <button type="button">送信</button> + <button type="button">アンケートを送信</button> diff src/styles/campaign.css button { display: block; width: fit-content; + padding: 1em; 104
105. キーボード操作 105
106. コラム：どんな人がキーボードでWebを閲覧する？ • ぼく（特に障がいなし） ◦ できるだけキーボードから手を離したくないと思ったとき ◦ うまくポインティングできないとき ▪ 例）ノートPCのトラックパッドの精度が悪い ▪ 例）揺れる乗り物のうえでPCを使っている ▪ 例）腕を怪我している ▪ 例）マウスを使うスペースがない • 障がいによって手、腕の震えがあり、うまくポインティングできない人 • ロービジョンにより、画面上のポインタを見つけたり、目で追ったりするのが困 難な人 106
107. トレーニング：キーボードでWebページを操作する • フォーカス可能： ◦ 可能：a, button, チェックボックス, ラジオボタン, textareaなど ◦ 不可能：div, span, p, h1など • 次のフォーカス可能な要素にフォーカス：tabまたはoption + tab • 前のフォーカス可能な要素にフォーカス：shift + tabまたはoption + shift + tab • リンクに遷移する：フォーカスを当ててenter • ボタンを押す：フォーカスを当ててspace • チェックボックスを切り替える：フォーカスを当ててspace • ラジオボタンを切り替える：フォーカスを当てて上下左右キー • テキストエリアに入力する：フォーカスを当てて、そのまま文字を入力する • 前 / 次のページに移動：command + 左右キー 107
108. トレーニング：キーボードでWebページを操作する：演習 • まずGoogleを開きます • ここからキーボードのみで操作します • 課題1：カレーのWikipediaを表示してみてください • 課題2.1：以下のタイトルのページを表示してみてください ◦ Checkbox Example (Two State) | APG | WAI | W3C • 課題2.2：そのページ内にあるチェックボックスを操作してみてください • 課題3.1：以下のタイトルのページを表示してみてください ◦ • Radio Group Example Using Roving tabindex | APG | WAI | W3C 課題3.2：そのページ内にあるラジオボタンを操作してみてください 108
109. 2.4.7 フォーカスの可視化 • ⭕キーボードで操作できるUIについて、フォーカスインジケータがある ◦ フォーカスインジケータ：フォーカスが当たった時に表示される枠線 109
110. クイズ：フォーカスの可視化 • 現状のサイトで、この基準に失敗している場所はどこですか 110
111. クイズ：フォーカスの可視化（回答例） • a, button, inputタグ全般 参考：達成基準 2.4.7 の失敗例 － 視覚的なフォーカスインジケータを除去する又は不可視にするような方法で、要素のアウトライン及びボーダーをスタイル指定する 111
112. 改善例：フォーカスの可視化 • フォーカスインジケータの無効化を削除する diff src/styles/global.css -// たまに謎の枠線が表示されてしまうため無効化 -a, -button, -input { - outline: none; -} 112
113. 改善例：フォーカスの可視化 • 可視性の良いフォーカスインジケータを独自に実装することもできる ◦ デフォルトのインジケータのスタイルは、OSやブラウザによって異なる Chrome (Mac) • Chrome (Ubuntu) Firefox (Ubuntu) どのような背景色、コンポーネントに対しても十分なコントラストになるよう に、複数の色を使って実装してみる 参考：コンテンツ制作者が提供する視認性に優れたフォーカスインジケータを使用する、すべてのコンポーネントで十分なコントラスト比を確保するために 2 色のフォーカスインジケータを作成する 113
114. 改善例：フォーカスの可視化 • 可視性の良いフォーカスインジケータを独自に実装する diff src/styles/global.css + +/* normalize.cssを上書きするためbuttonを個別に指定する */ +*, +button[type="button"] { + &:focus-visible { + /* focus-indicator */ + outline: 2px solid var(--color-accent); + outline-offset: 4px; + box-shadow: 0 0 0 8px var(--color-base); + } +} 114
115. ここまでの改善を実装してみましょう 実際にキーボードでコンテンツを操作し、インジケータがどのように見えるか確かめ ましょう 115
116. コラム：画面上からフォーカスインジケータが消えると • キーボード操作のユーザーは、自身の位置を見失います • マウス操作で例えると「ポインタが勝手にどこかへ消えてしまう」くらいの衝撃 です • なのでフォーカスを大切にしましょう 116
117. 2.1.1、2.4.3 キーボード操作 • ⭕コンテンツのすべての機能が、キーボードで操作可能 • ⭕フォーカス順序が、意味及び操作性を損なわない 117
118. クイズ：キーボード操作 • 現状のサイトにはキーボードで操作できない機能があります。それはどこですか 118
119. クイズ：キーボード操作（回答例） • ラジオボタンの操作 • ナビゲーションメニューの開閉 119
120. 改善例：キーボード操作 ラジオボタンの現状 • label { input[type="radio"] { display: none; // もともとのinputは非表示 &:checked { display: none;してしまうと、キー ボードや支援技術からも見えなくな り、操作できなくなってしまう + span { // チェック時のスタイル } } } span { // ここで独自のスタイルを定義 } } 120
121. 改善例：キーボード操作 • • 今回やりたいこと：見た目上は隠したいが、支援技術等には引き続き公開したい ◦ これは通称、Visually-Hiddenと呼ばれる ◦ ぱっと見て「visibility: hidden;」と似ているが、混同しないようにする いろいろな実装方法が考えられるが、今回は以下にあるvisually-hiddenスタイル をコピペして使う*1 ◦ WCAGが提供するvisually-hiddenスタイルの例 *1：Visually-Hiddenによる実装は理論的には正しいですが、支援技術によっては動作しない場合があるかもしれません。そのため、ターゲットとする技術を使って実際にテストし、動作しない場合は別の実装を行うこともできます。詳しくは「改善例：キーボード操作 （補足）」のスライドを参照してください。 121
122. 改善例：キーボード操作 diff src/styles/global.css diff src/index.html +.visually-hidden { <div class="radio"> + clip-path: inset(100%); + clip: rect(1px, 1px, 1px, 1px); - + height: 1px; value="polite" checked /> + overflow: hidden; + + position: absolute; + type="radio" + white-space: nowrap; + name="advantage" + width: 1px; + value="polite" + class="visually-hidden" + checked +} <label> + <input type="radio" name="advantage" <input /> <span>ヒアリングが丁寧</span> 以降ほかのラジオボタンも同様 *1：Visually Hiddenのスタイルは次を参考にした：https://waic.jp/translations/WCAG21/Techniques/css/C7 122
123. 改善例：キーボード操作 • フォーカスインジケータも忘れずに diff src/styles/campaign.css input[type="radio"] { - display: none; + &:focus-visible { + + span { + &::before { + /* focus-indicator */ + outline: 2px solid var(--color-accent); + outline-offset: 4px; + box-shadow: 0 0 0 8px var(--color-base); + } + + } } 123
124. 改善例：キーボード操作 • キーボードで操作できるようになった 124
125. 改善例：キーボード操作 • ナビゲーションメニューの開閉ボタンに関しても同じように修正する diff src/styles/navigation.css .nav_open, .nav_close { button { - display: none; + &:focus-visible { + + span { + /* focus-indicator */ + outline: 2px solid var(--color-accent); + outline-offset: 4px; + box-shadow: 0 0 0 8px var(--color-base); + + } } 125
126. 改善例：キーボード操作 • ナビゲーションメニューの開閉ボタンに関しても同じように修正する diff src/index.html <nav class="navigation"> <label class="nav_open"> - <button>MENU</button> + <button class="visually-hidden">MENU</button> <span>MENU</span> </label> <div class="container"> <label class="nav_close"> - <button>CLOSE</button> + <button class="visually-hidden">CLOSE</button> <span>CLOSE</span> </label> 126
127. 改善例：キーボード操作 • さっそくキーボードで操作してみるが…… ◦ • →ページの先頭でどのようにしてもフォーカスを当てられない さらにTabを押していくと…… Tab フォーカス順序がおかしい 127
128. 改善例：キーボード操作 • ナビゲーション開閉ボタンのフォーカス順序がおかしい ◦ • →DOMの順序がおかしいから 視覚的順序とDOMの順序は一致させるべき 修正 参考：DOM の順序を視覚的順序と一致させる 128
129. 改善例：キーボード操作 • さっそくナビゲーションをキーボードで開いてみるが…… Space 画面上からフォーカスインジ ケータが消えてしまった 129
130. 改善例：キーボード操作 • 何が起きたのか メニューが手前に開いた後も、フォーカス は元のボタンに当たったまま Space →メニューを開いている 間は、フォーカスをメ ニューの内部に限定して ほしい 130
131. 改善例：キーボード操作 • Dialog要素を使ってナビゲーションメニューを実装してみる diff src/index.html diff src/scripts/navigation.js - <div class="container"> navOpenButton.addEventListener("click", () => { + <dialog class="container"> - navContainer.style.display = "block"; + navContainer.showModal(); - </div> }); + </dialog> navCloseButton.addEventListener("click", () => { diff src/styles/navigation.css .container { - navContainer.style.display = "none"; + navContainer.close(); }); position: fixed; top: 0; left: 0; - display: none; 131
132. 改善例：キーボード操作 • Dialog要素はa11yを考慮して作られているので ◦ フォーカスがメニュー内に限定されるようになった ◦ メニューを閉じたときにフォーカスが復元されるようになった ◦ ESCキーでメニューを閉じられるようになった Space Space 132
133. 改善例：キーボード操作（補足） • 今回は簡単のために、既存のボタンを不可視にする方法で独自のボタンを実装し た • そのような方法以外にも、a11yを担保したコンポーネントを実装するパターンが ある • 詳しくは以下の資料を参照 ◦ APG（ARIA Authoring Practices Guide） ◦ One last time: custom styling radio buttons and checkboxes 133
134. ここまでの改善を実装してみましょう 実際にキーボードでコンテンツを操作してみましょう 134
135. 3.2.2 予期しないコンテキスト変化 • ⭕ユーザインタフェース コンポーネントの設定を変更することが、コンテキス トの変化を自動的に引き起こさない。 ◦ コンテキストの変化：コンテンツにおける変化のうち、ウェブページ全体を 一度に見ることのできない利用者が、それに気が付かないことで混乱してし まう恐れのあるもの ◦ 例： ▪ 画面遷移 ▪ コンテンツの変化 ▪ フォーカスの移動 135
136. クイズ：予期しないコンテキスト変化 • 現状のサイトで、本基準に失敗している箇所はどこですか 136
137. クイズ：予期しないコンテキスト変化（回答例） • キャンペーンのアンケートフォーム ◦ ラジオボタンのうち、「その他」を選択するとフォーカスが別のコンポーネ ントに勝手に移動してしまう 137
138. 改善例：予期しないコンテキスト変化 • 勝手にフォーカスを移す処理を削除する diff src/scripts/campaign.js form.addEventListener("change", () => { if (othersRadioButton.checked) { othersTextInput.removeAttribute("disabled"); - othersTextInput.focus(); 138
139. ここまでの改善を実装してみましょう 実際にキーボードでコンテンツを操作してみましょう 139
140. スクリーンリーダー 140
141. コラム：どんな人がスクリーンリーダーでWebを閲覧する？ • 盲目（79.5% • ロービジョン・視覚障がい（21.9% • 他にも ◦ 認知障がい・学習障がい（3.2% ◦ 運動機能障がい（2.4% ◦ 難聴（7.3% ▪ 注意：スクリーンリーダーはテキストを点字ディスプレイに送信する機 能も持っている ▪ 例：盲目かつ難聴で、スクリーンリーダー + 点字ディスプレイを使用 参考：https://webaim.org/projects/screenreadersurvey9/#disabilitytypes 141
142. コラム：どんな人がスクリーンリーダーでWebを閲覧する？ 点字ディスプレイの例 この部分の凹凸が変化する 出典：ブレイルメモスマートAir16 | ケージーエス株式会社 142
143. コラム：どんな人がスクリーンリーダーでWebを閲覧する？ • スクリーンリーダーにおけ る点字ディスプレイの設定 画面 143
144. OSとスクリーンリーダーのシェア状況 • スクリーンリーダー利用者のOS（グラフ左）とスクリーンリーダー（グラフ右） のシェア状況 • Windows環境が大多数*1 出典：OSシェアのグラフ、スクリーンリーダーのシェア、*1：会社の環境に合わせて今回の研修はMac/VOで行っていますが、世の中のスタンダードな環境とは多少異なるということです 144
145. トレーニング：スクリーンリーダーの操作 • 注意 ◦ ここからはPCから音が出ます。 ◦ 各自イヤホン / ヘッドホンをすることをおすすめします。 145
146. トレーニング：スクリーンリーダーの操作（VoiceOver） • VoiceOverのオン/オフ：以下のいずれか ◦ command + F5 ◦ command + Touch IDを素早く3回 ◦ システム環境設定 > アクセシビリティ > VoiceOver > VoiceOverを有効に するチェックボックス • フォーカスの操作は同じ ◦ • フォーカスを移動すると、そこを読み上げる テキストをマウスで選択すると、そこを読み上げる 146
147. トレーニング：スクリーンリーダーの操作（VoiceOver） • VOキー：以下のいずれか ◦ CapsLock ◦ control + option • 次を読み上げ：VO + → • 前を読み上げ：VO + ← • 領域に入る / 出る：VO + shift + ↓ / ↑ 147
148. トレーニング：スクリーンリーダーの操作（VoiceOver） • 見出しやリンク、ランドマークの一覧を見る：VO + u ◦ さらに、 ▪ 一覧を切り替え：左右キー ▪ 項目を移動：上下キー ▪ 項目を選択：enter ▪ 閉じる：esc • ヘルプ：VO + h • 注意：WebナビゲーションはDOMモードで統一します ◦ デフォルトはDOMです ◦ 切替方法：ヘルプ > コマンドヘルプ > Web > WebナビゲーションのDOM / グ ループを切り替える 148
149. トレーニング：スクリーンリーダーの操作：演習 • Googleを開き、検索ボックスにフォーカスを当てます • VoiceOverを有効にします • ここから画面を見ずに、音だけを聞いて操作します • 課題1：カレーのWikipediaを開いてください • 課題2.1：カレーライスのWikipediaを開いてください • 課題2.2：ページ内を読み、日本で初めてカレーを紹介した人物は誰か調べてく ださい 149
150. 2.4.9 リンクの目的 • ⭕リンクのテキスト単独で、その目的が判別できる 150
151. クイズ：リンクの目的 • 現状のサイトで、テキスト単独で目的がわからないリンクがあります。それはど こでしょうか ◦ ヒント：VoiceOverを起動し、リンクの一覧を確かめます 151
152. クイズ：リンクの目的（回答例） • フッターの「こちら」リンク • サービス内のリンクテキストがおかしい ◦ 例：UIデザイン right_arrow 参考：達成基準 2.4.9 の失敗例 － リンクテキストを具体的なテキストに変更するメカニズムなしで、「ここをクリック」又は「続きを読む」などの不明確なリンクを使用している 152
153. 改善例：リンクの目的 • フッターの「こちら」リンク diff src/index.html このサイトはアクセシビリティの学習のために作られました。詳しくは - <a href="https://github.com/sititou70/komaru-corp-a11y">こちら</a> + <a href="https://github.com/sititou70/komaru-corp-a11y"> + + 当サイトのGitHubリポジトリ </a> を参照してください 参考：リンクの目的を説明したリンクテキストを提供する 153
154. 改善例：リンクの目的 • サービス内のリンクテキストにalt属性の不適切な値が含まれてしまう問題 • VOのリンク一覧に表示されている文字列は、リンクのアクセシブルネーム ◦ アクセシブルネーム：ユーザーがWebコンテンツの一部を識別するための文 字列 • ある要素のアクセシブルネームは、その子要素から以下の規則で計算される ◦ Accessible Name and Description Computation 1.2 • アクセシブルネームをDev Toolsから確認する方法がある • ここでは、子要素である画像のalt属性もアクセシブルネームの計算対象に含ま れ、それが不適切であるためおかしくなっている • 次の改善で同時に修正される 154
155. 1.1.1 適切なalt属性 • ⭕利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たす テキストによる代替が提供されている 155
156. 改善例：適切なalt属性 • アンケート結果のグラフ：alt属性がない • VOで読み上げてみると「/graph02.jpg ラベルのない画像」となってしまう。こ れではアンケート結果が利用者に伝わらない • 基本的に、画像にある文字をそのままalt属性に書けば良い diff src/index.html - <img src="/assets/graph2.jpg" /> + <img + src="/assets/graph2.jpg" + alt="満足：70% 不満：30%" + /> 参考：達成基準 1.1.1 の失敗例 － img 要素、area 要素、及び type "image" の input 要素の alt 属性又はテキストによる代替を省略している 156
157. 改善例：適切なalt属性 • サービスのリンク内にあるアイコン画像：alt属性が不適切 ◦ • 「right_arrow」と読み上げられても困る これは純粋な装飾画像なので無視したい ◦ alt=””と書く ◦ 属性自体の省略はできないことに注意 diff src/index.html - <img src="/assets/right_arrow.svg" alt="right_arrow" /> + <img src="/assets/right_arrow.svg" alt="" /> 参考：支援技術が無視すべき画像に対して、img 要素の alt テキストを空にして、title 属性を付与しない 157
158. 改善例：適切なalt属性 • 制作実績のリンク内の画像：alt属性がない • →画像に含まれるテキストはすでにリンク内に存在するためalt=””とする ◦ もし「alt=”五百年の歴史と共に 駒瑠神社”」としたとすると ◦ リンクテキストは「ホームページ制作 五百年の歴史と共に 駒瑠神社 五百年 の歴史と共に 駒瑠神社 公式サイト」と冗長になってしまう diff src/index.html <a href="./" class="observe"> <span>ホームページ制作</span> - <img src="./assets/work01.jpg" /> + <img src="./assets/work01.jpg" alt="" /> 五百年の歴史と共に 駒瑠神社 公式サイト </a> 158
159. 改善例：適切なalt属性 • クイズ：以下のように、もし画像が単独でリンクなら？（時間：30秒） 159
160. 改善例：適切なalt属性 • クイズ：以下のように、もし画像が単独でリンクなら？（時間：30秒） • 答え：「alt=”五百年の歴史と共に 駒瑠神社”」とすべき ◦ • 「alt=””」だと、リンクテキストが空になってしまう 全体としてどうなれば自然か？を意識しましょう 160
161. ここまでの改善を実装してみましょう 実際にリンクテキストが適切になったか確認しましょう 161
162. 2.4.6、1.3.1 適切な見出し • ⭕見出しが主題または目的を説明している • ⭕見出しが適切にマークアップされている 162
163. クイズ：適切な見出し • 見出しが適切でない箇所はどこでしょうか • ヒント：VOで見出し一覧を表示します 163
164. クイズ：適切な見出し（回答例） • 「先月のアンケート結果」見出しが一覧に表示されない • 「 注意：お電話のかけ間違いが多くなっております。十分ご注意ください」が見 出しとして表示されてしまう 参考：達成基準 1.3.1 の失敗例 － コンテンツにおける関係を表さない方法で、構造的なマークアップを使用している、達成基準 1.3.1 の失敗例 － 情報を伝えるために、適切なマークアップ又はテキストを用いずに、テキストの提示の変化を使用している 164
165. 改善例：適切な見出し • 「先月のアンケート結果」見出し ◦ 見出し要素ではなくspanにスタイルを当てたものだった ◦ したがってVOの見出し一覧に現れなかった diff src/index.html - <span class="result">先月のアンケート結果</span> + <h3>先月のアンケート結果</h3> diff src/styles/campaign.css - .result { - font-size: 1.2rem; - font-weight: bold; - } 参考：見出しを特定するために、h1 要素～ h6 要素を使用する 165
166. 改善例：適切な見出し • 「 注意：お電話のかけ間違いが多くなっております。〜〜」見出し ◦ 文章を強調するためにh3要素を使っていた ◦ strong要素を使うように修正する diff src/index.html - <h3> + <strong> 注意：お電話のかけ間違いが多くなっております。十分ご注意ください - </h3> + </strong> 参考：構造をマークアップするために、セマンティックな要素を使用する 166
167. ここまでの改善を実装してみましょう 見出しは意図したとおりになったでしょうか 167
168. コラム：見出しの重要性 • How Users Read on the Web の調査によれば、ほとんどの ユーザーはWebページを流し 読みしている • Screen Reader User Survey #9 Resultsによれば、ユー ザーは見出しによるナビゲー ションをよく使う。これはラ ンドマークやページ内検索よ りも高い割合 グラフの出典：https://webaim.org/projects/screenreadersurvey9/#finding 168
169. 2.5.3、3.3.2、2.4.6 適切なラベル • ⭕ユーザーインターフェースコンポーネントについて、表示されているラベルが アクセシブルネームに含まれる • ⭕利用者の入力を要求する場合は、ラベルまたは説明がある 169
170. 改善例：適切なラベル • 氏名の入力：可視ラベルとアクセシブルネームが一致していない ◦ 可視ラベルがあるにもかかわらず、マークアップが不適切なので、現状のテ キストボックス要素にはアクセシブルな名前がついていない • 晴眼者なら可視ラベルとテキストボックスが近くにあるとわかるが…… • スクリーンリーダーユーザーが困惑する例： ◦ ユーザー「（Tabキーで直接テキストボックスにフォーカスした）」 ◦ スクリーンリーダー「テキストを編集、空」 ◦ ユーザー「あれ、編集すべき項目があるのはわかるけど、何を入力すれば良 いんだ？？？」 170
171. 改善例：適切なラベル • 氏名の入力：可視ラベルとアクセシブルネームが一致していない diff src/index.html - 氏名：<input name="name" /> + <label> + <span>氏名：</span> + <input name="name" /> + </label> 参考：アクセシブルな名前 (accessible name) を視覚的なラベルと一致させる 171
172. 改善例：適切なラベル • 電話番号の入力：それぞれのinputに適切な可視ラベルがない ◦ 直前のテキストが可視ラベルだとすると、tel2とtel3のラベルは「-」という ことになってしまう • テキストボックスを1つにして、続けて入力してもらうようにする diff src/index.html diff src/styles/campaign.css - <span class="required">電話番号（必須）：</span> - - <input name="tel1" required="required" /> - - - <input name="tel2" required="required" /> - - - <input name="tel3" required="required" /> - + <span class="required"> - + .tel { input { width: 3em; } } 電話番号（必須）（ハイフン・スペース無し、半角数字）： + </span> + <input name="tel" required="required" /> 参考：達成基準 3.3.2 の失敗例 － 電話番号のフィールド一式を視覚的にフォーマットしているが、テキストラベルを含んでいない 172
173. 改善例：適切なラベル • ナビゲーションメニュー：「MENU」というラベルがあるが、Dialog要素と紐付 いていない • aria-labelledbyを使うことで、そのDialogが何なのか明確にできる diff src/index.html - <dialog class="container"> + <dialog class="container" aria-labelledby="nav_menu"> - <h2>MENU</h2> + <h2 id="nav_menu">MENU</h2> 173
174. 1.3.5 入力目的の特定 • ⭕適切なautocomplete属性を使用している • これにより ◦ ブラウザは情報を自動入力できるようになる ▪ ◦ 特に、言語や記憶、運動に関して障がいのある人に役立つ 例えば、autocomplete="tel"の要素の前に電話のアイコン「📞」を表示す る支援技術を利用できる ▪ 一部の利用者は、コミュニケーションに画像を使用するのを好む場合が ある 174
175. 改善例：入力目的の特定 diff src/index.html - <input name="name" /> + <input name="name" autocomplete="name" /> - <input name="tel" required="required" /> + <input name="tel" required="required" autocomplete="tel" /> 175
176. ここまでの改善を実装してみましょう 読み上げはどのように変わりましたか 176
177. 2.2.2、2.3.3 アニメーションの抑制 • ⭕動きのある情報が、自動的に開始し、5秒よりも長く継続し、その他のコンテ ンツと並行して提示される場合、それらを一時停止、停止、非表示にすることの できるメカニズムがある。 • ⭕アニメーションが、機能又は伝達されている情報に必要不可欠でない限り、イ ンタラクションによって引き起こされるモーションアニメーションを無効にでき る • 一部の利用者は、動きのあるコンテンツから、注意散漫や吐き気を経験すること がある 177
178. 改善例：アニメーションの抑制 • ヒーローヘッダーの背景動画：停止させるコントロールを作る diff src/index.html <script type="module" src="./scripts/nav.js"></script> + <script type="module" src="./scripts/hero.js"></script> + <button type="button" class="stop">STOP</button> </div> </header> diff src/scripts/hero.js +const bgVideo = document.querySelector(".hero .bg"); +const stopButton = document.querySelector(".hero .stop"); + +stopButton.addEventListener("click", () => { + bgVideo.pause(); +}); 178
179. 改善例：アニメーションの抑制 • ヒーローヘッダーの背景動画：停止させるコントロールを作る diff src/styles/hero.css + button { + position: absolute; + right: 10px; + bottom: 10px; + padding: 0.7em 1em; + border: 2px solid var(--color-text); + } 参考：動きのあるコンテンツ、点滅するコンテンツ、又は自動更新するコンテンツを停止させるコントロールを使用する 179
180. 改善例：アニメーションの抑制 • 制作実績のリンク：スクロールするとアニメーションが実行される • prefers-reduced-motionで抑制できるようにする diff src/styles/works.css diff src/styles/works.css +@media (prefers-reduced-motion) { + @keyframes appear { + } +} &.is-displayed { animation: appear 0.5s both ease; } + @media (prefers-reduced-motion) { + + 参考：モーションの防止に CSS reduce-motion クエリを使用する opacity: 1; } 180
181. ここまでの改善を実装してみましょう • 停止ボタンは動作しますか • 以下の方法でOSのモーション抑制を設定したとき、制作実績のアニメーションは 止まりますか ◦ システム設定 > アクセシビリティ > 視差効果 > 視差効果を減らす 181
182. コードを書く演習は以上です • お疲れ様でした ◦ 座学はもうちょっと続きます • 今回はWCAGの一部を抜粋・割愛して扱いました。 • 実務では、他にも気をつけなければならない点がたくさんあります。 • 気になる方は、a11yの本やガイドラインを読んでみましょう。 182
183. a11yの自動チェック 183
184. Evaluation Tools：自動評価ツール • HTML / CSSバリデータ：基本的な構文等を検査 • Axe（Deque社） ◦ 平均して、WCAG全体の57%の問題点を自動的に発見可能とされる*1 ◦ 以下のツールで内部的に利用されている ▪ Lighthouse ▪ storybook-addon-a11y ▪ eslint-plugin-jsx-a11y ▪ Accessibility Insights for Web • WAVE（WebAIM Community） • IBM Equal Access Toolkit（IBM社） • Firefox A11yインスペクターのチェック機能（Mozilla社） *1：axe-coreのREADMEより 184
185. 自動チェックツールだけでは十分でない • 例：alt属性 ◦ ツールは「alt属性が設定されていない」ことを検出できる ◦ しかし、「alt属性にどのような値を設定すればいいか」はわからない ◦ ▪ 装飾画像なら：空文字 ▪ 文字列を含むなら：その文字列 ▪ etc…… →「その画像がどのような意図を持つか」はコンテンツ制作者にしかわから ない • badブランチをチェックアウトして、自動チェックツールを実行してみましょう ◦ • 今日見てきた問題点はすべて検出されましたか？ 自動チェックと手動チェックを組み合わせるのが大事 185
186. テストコードとa11y 186
187. a11yをテストコードでも活用する • 改善前のテストコード：DOMの構造、クラス名、スタイル、name属性に依存 test("ナビゲーションメニューを開ける", async ({ page }) => { await page.goto("/"); await page.locator(".nav_open button").dispatchEvent("click"); await expect(page.locator(".navigation .container")).toHaveCSS("display", "block"); }); test("アンケート：氏名は任意要素", async ({ page }) => { await page.goto("/"); const input = page.locator(".campaign form input[name=name]"); await expect(input).not.toHaveAttribute("required"); }); 187
188. a11yをテストコードでも活用する • 改善後：a11yロールやラベルで、より堅牢なテストが書ける test("ナビゲーションメニューを開ける", async ({ page }) => { await page.goto("/"); await page.getByRole("button", { name: /MENU/i }).dispatchEvent("click"); await expect(page.getByRole("dialog", { name: /MENU/i })).toHaveAttribute("open"); }); test("アンケート：氏名は任意要素", async ({ page }) => { await page.goto("/"); const input = page.getByRole("textbox", { name: /氏名/i }); await expect(input).not.toHaveAttribute("required"); }); 188
189. a11yをテストコードでも活用する • a11yが向上したので、テストコードからもWebコンテンツにアクセスしやすく なった。 189
190. 実務でのコツ 190
191. a11y改善：コスパの良いものから コスト小 コスト大 効果小 例：利用者がとても少ないコン テンツの軽微な修正 例：一部のコントラスト比を確保するた めに、ブランドカラーやデザイン全体を 変更してもらう 効果大 例：装飾画像にalt=”” 例：すべての入力コンポーネントをキー ボード操作に対応させる もしやるなら、ここから始めていきたい 191
192. 新規開発：素直なコードを心がける • Webには、高いアクセシビリティの仕組みが最初から備わっています。 • それを引き出す一番の方法は、基本に忠実なコードを素朴に書くことです。 • 良いHTMLを書きましょう ◦ 例：文書構造を意識する ◦ 例：信頼できるサイトを参考にしてコードを書く ◦ 例：デザインの時点で、Web文書としては表現しづらいものになっているこ ともある。その場合は、デザイナーと協力して解決する • 標準の技術を検討しましょう ◦ 例：ダイアログを実装するとき、自前実装やUIライブラリよりも、標準の Dialog要素が使えないか検討する 192
193. 新規開発：素直なコードを心がける • シンプルに実装しましょう ◦ 現代におけるWeb技術の表現力はわりと高いですし、日々向上し続けています ◦ それでも、複雑な実装（例：divやspanを多用して、かつaria-xxxを山盛りにし て）をしたくなったら、実装したい機能の方を一度疑ってみましょう • ◦ 例：やりたいことに対して、機能がリッチすぎるかもしれない ◦ 例：システム全体を見直すと、その機能を削除/簡略化できるかもしれない a11yを意識することは、コードやシステムをシンプルに保つための、1つの判断基準に なります。 ◦ UXの向上、工数の削減、可読性や保守性の改善など、a11yの範囲を超えた効果も 期待できる • 作るべきものを、正しい方法で作りましょう 193
194. まとめ：今日は以下のことを学びました • アクセシビリティの ◦ 定義：access + ability ◦ 重要性 ▪ アクセスできない / しにくい人を減らすため ▪ SEO対策のため ▪ さまざまなデバイスに対応するため ▪ UX改善のため ▪ etc…… ◦ 基準・ガイドライン：WCAG 2.2 ◦ 改善・検証方法：コードを書いて学んだ 194
195. The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect. Webの優れている点は、その普遍性にあります。 障がいの有無によらず誰でもアクセスできることが、Webの本質的な側面です。 Tim Berners-Lee, W3C Director and inventor of the World Wide Web →誰でも使えるWebを作っていきましょう！ 195
196. 参考文献 • Web Content Accessibility Guidelines (WCAG) 2.2 • デザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のア プローチ • Form Design Patterns - シンプルでインクルーシブなフォーム制作実践ガイド • ウェブアクセシビリティ導入ガイドブック、デジタル庁 196