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