ウェブディレクターのための Web A11Y 勉強会 (Season 2) #12 [最終回]

ウェブディレクターのための 
Web A11Y 勉強会 
Season 2
#12 (2019-03-14)
最終回！

自己紹介
@caztcha
 
ウェブユーザビリティ / アクセシビリティ / 情報アーキテクチャ (IA)
HCD-Net 認定人間中心設計専門家
ウェブアクセシビリティ基盤委員会 (WAIC) 翻訳ワーキンググループ
https://website-usability.info

今日のメニュー
• WCAG 2.1 とは？ (おさらい)
• WCAG 2.1 で追加された達成基準を読む
(Level A & AA)
• 2.5.4 Motion Actuation (A) [モバイル]
• 4.1.3 Status Messages (AA) [認知/学習]
• この勉強会のまとめ

WCAG 2.1 とは？ (おさらい)

WCAG 2.1 とは？
• WCAG (Web Content Accessibility Guidelines) の新
バージョン。2018年6月5日に勧告。
https://www.w3.org/TR/WCAG21/
• 旧バージョン (2.0) で十分にカバーできていなかった領域
(ロービジョン、モバイル、認知/学習障害への配慮) が強
化されている。
• 17の新しい達成基準が追加。従来の達成基準はそのまま
(番号の変更はなし)。

WCAG 2.1 で追加された
達成基準を読む (Level A & AA)

達成基準 2.5.4  
Motion Actuation / 動きによる起動
(レベル A) [モバイル]
デバイスの動きや利用者の動きで操作できる機能は、ユーザインタフェースコンポー
ネントでも操作でき、かつ予期しない起動を防ぐために動きへの反応を無効化する
ことができる。ただし、以下の場合は例外とする。
• サポートされたインタフェース : アクセシビリティサポーテッドなインタフェース
を通じて機能を操作するのに動きが用いられる。
• 必要不可欠 : その機能にとって動きが必要不可欠であり、上記の基準に従うと、
動作が成り立たない。
達成基準 2.5.4 原文 : https://www.w3.org/TR/WCAG21/#motion-actuation

デバイスを傾けて、次の / 前のステップに進む。デバイスを振って、アンドゥ (操作の取り消し) をする。
このような動きを行なうことが困難なユーザーもいることに、配慮する必要があります。

[まとめ] 達成基準 2.5.4 Motion Actuation
デバイスのモーションセンサーを活用するアプリケーションの場合、デバイスを傾け
たり振ったりすることができないユーザーが、利用できない恐れがあります。
代替手段として UI コンポーネント (ボタンなど) からも使えるようにしましょう。
かつ、誤動作防止のためにモーションセンサーをオフにできるようにしましょう。

達成基準 4.1.3  
Status Messages /ステータスメッセージ 
(レベル AA) [認知/学習]
マークアップ言語を使って実装されたコンテンツでは、ステータスメッセージ
は、役割 (role) 又はプロパティを通してプログラムによる解釈が可能であり、
フォーカスを受けとらなくても支援技術によってユーザに提示することができ
る。
達成基準 4.1.3 原文 : https://www.w3.org/TR/WCAG21/#status-messages

お名前 [必須 ]
メールアドレス [必須 ]
foo
……
送信
未記入の項目があるか、書式が適切でない項目があります。詳細は、各入力項目を
ご確認ください。
未記入です。
不適切な書式です。
role=“alert”
aria-live=“assertive”

[まとめ] 達成基準 4.1.3 Status Messages
ある操作に対するフィードバックで、状況を伝えるメッセージが出る場合、それを見る
ことができないユーザーにも支援技術 (スクリーンリーダーなど) を介して伝達される
ように実装しましょう。
WAI-ARIA の以下の属性を用いることで、実装することができます。
• role=“status”
…メッセージが、操作の結果 (成功した旨など) やアプリケーションの状態を伝える場合。
• role=“alert”
…メッセージが、警告やエラーを伝える場合。
• aria-live=“polite” または “assertive”

この勉強会の目標
日々のウェブコンテンツ制作実務に
おいてアクセシビリティの担保を継続
的に回せること。そのための基礎作り。

サイトオーナー (発注者) が意識せず
とも自ずとアクセシビリティが担保
されている状態。
実現したいこと

昨年度の Season 1、今年度の Season 2 を通じて、アクセシビリティに
関するナレッジや意識が、広く深く根付いたと思います。
• WCAG 2.0 の達成基準レベル A の読み合わせ
• WCAG 2.0 の達成基準レベル AA の読み合わせ
• WCAG 2.1 の新達成基準 (レベル A および AA) の読み合わせ
• 「インクルーシブなペルソナ拡張」を用いた UI 評価ワーク
これだけのことを
やり遂げました！

アクセシビリティを理解し、実践できることを、
みなさんご自身の「強み」にしてゆきましょう。

インクルーシブなペルソナ拡張
Inclusive Persona Extension
様々な障害や利用状況ごとに、
「ウェブ利用時の障壁」と「解決方法」
をまとめています。
実案件でもご活用ください。ご参考

視覚障害 (全盲)
ウェブ利用時の障壁
• 目が見えない。視覚的な情報が理解できない。
• スクリーンリーダーによる音声読み上げ (または点字出力) がないと利用でき
ない。
• 自由にポインティング (マウスでのクリックや指でのタップ) ができない。
解決方法
• 文字情報は画像ではなくテキストで作る。
• 画像やアイコンに対して、代替テキストを提供する。
• 映像コンテンツに対して、代替コンテンツ (音声解説など) を提供する。
• 見出し構造やランドマークを適切にマークアップする。
• キーボード操作だけで過不足なく利用できるようにする。
• リンクやボタンのラベルを具体的に記述する。
• フォームの入力要素にはラベル (label 要素) を付ける。
• テーブル (表) はシンプルな構造にし、見出しセルを th 要素にする。
• インタラクションに伴う状況の変化がスクリーンリーダーでも伝わるようにする
(WAI-ARIA)。
• ページの読み込みと併せて勝手に音声を出さない。
Inclusive Persona Extension by Website Usability Info

視覚障害 (ロービジョン )
• 目が見えにくい。
• 明瞭に見えない (ぼやける、重なる)。
• まぶしい。
• ちらつく。
• 視野を広く見ることができない。
• 視野の中心が欠ける。
• 焦点が定まらない (震える)。
• 見えにくさによっては、スクリーンリーダーによる音声読み上げに頼ることも
ある。
解決方法
• ズーム (画面表示の拡大) を妨げない。
• ユーザーインターフェースの慣例 (おなじみのパターン) に従う。
• 文字色と背景色のコントラストを十分に保つ。
• ユーザーエージェントの機能で色を反転表示しても、情報が伝わるようにする。
• ユーザーが独自のスタイルシートを使うことを妨げない。
• 情報のチャンク (塊やつながり) に配慮してレイアウトする。
• 偶発的なトリガー (マウスオーバーやフォーカス) でコンテンツを変更しない。
• 音声読み上げ順と視覚的なレイアウトを合致させる。

色覚特性
• 色が識別しにくい。
• P型 (赤の視感度がないか低い)
• D型 (緑の視感度がないか低い)
• T型 (青の視感度がないか低い)
• A型 (色の識別ができず明暗でしか判別できない)
• ウェブページをグレースケールで印刷する場合、情報識別を色に依存している
コンテンツだと判別できない。
• モノクロの電子書籍リーダーで (電子書籍からのリンクなどで) ウェブページ
を開く場合、情報識別を色に依存しているコンテンツだと判別できない。
解決方法
• 色だけで情報を識別させない。
• リンク (特に文中のリンク) には下線を付ける。
• 文字の大きさや太さなど、色以外の要素を用いてテキストのビジュアルヒエ
ラルキー (視覚的な優先度) を表現する。
• 図 (グラフなど) においては、色以外の形状も、視覚的な判別の手がかりとし
て付ける。
• グレースケール表示でもコンテンツを理解/利用できるようにする。
(グレースケール印刷 )

聴覚障害
• 音が聞こえない、または聞こえにくい。
• 公共の場 (交通機関、図書館、など) にいて、音を出せない (Bluetooth イヤ
ホンのバッテリー切れ、イヤホン忘れ、といった状況も含む)。
• コンテンツに用いられている言語が母語ではないユーザーが、音声を正しく聞
き取れない。
解決方法
• 音声コンテンツに対して、トランスクリプト (書き起こし文) を併せて提供する。
• 音声付き動画コンテンツに対して、キャプション (字幕) を併せて提供する。
(公共の場 ) (非母語話者 )

運動障害
• 自由にポインティング (マウスでのクリックや指でのタップ) ができない。以
下の手段に頼る必要がある。
• PC キーボード
• マウススティック
• 各種スイッチ (ボタン)
• 音声認識ソフト
• 視線入力装置
• …etc.
• デバイスの持ち替え (自由に向きを変えること) が難しい。
解決方法
• キーボード操作だけで過不足なく利用できるようにする。
• キーボード操作によるフォーカス位置を視認できるようにする。
• リンクやボタンなどは、精緻なポインティング操作ができなくてもクリック / タッ
プ / 実行できるよう、十分な大きさにする。
• リンクやボタンのラベルを具体的に記述する。テキストで記述し、適切にマークアッ
プする。
• デバイスの向きが「ポートレート (縦)」「ランドスケープ (横)」どちらでも過不足
なく利用できるようにする。
•

認知 / 学習障害
• 情報を認知したり記憶することが難しい。
• 外的な刺激によって集中が妨げられる。
• 文字を読むのが難しい。(ディスレクシア)
解決方法
• コンテンツはなるべく平易な言葉で表現する。
• 見出しを提示してコンテンツの概要をつかみやすくする。
• 読まなくても理解できるよう、視覚表現 (画像、図、アイコン、シンボルなど) を適
宜用いる。
• コンテンツに時間制限がある場合、ユーザーが任意で解除または調整できるように
する。
• コンテンツ内の動きや点滅は、5 秒以内にとどめるか、ユーザーが任意で停止でき
るようにする。
• コンテンツ表現において、1 秒に3 回以上の閃光は用いない。
• 視認性のよいフォントを用いる。
• 文字サイズや行間を十分な大きさにして、可読性を高くする。Inclusive Persona Extension by Website Usability Info

加齢
• 精緻なポインティング (マウスでのクリックや指でのタップ) ができない。
• 小さな文字や薄い文字が見にくい。(老眼)
• 耳が遠い。
• 情報を認知したり記憶することが難しい。
• 思い込みで判断しやすい。
解決方法
• リンクやボタンなどは、精緻なポインティング操作でなくてもクリック / タップ /
実行できるよう、十分な大きさにする。
• 文字サイズや行間を十分な大きさにして、可読性を高くする。
• コンテンツはなるべく平易な言葉で表現する。
• 見出しを提示してコンテンツの概要をつかみやすくする。
• 読まなくても理解できるよう、視覚表現 (画像、図、アイコン、シンボルなど) を適
宜用いる。

モバイル
• 画面が小さく、情報を得るための視野が狭い。
• 文字が小さくなりがちで、読みにくい。
• 屋外で使用する場合、自然光のまぶしさでコンテンツが見にくい。
• 指でタップするので、マウスに比べて精緻なポインティングが難しい。
• ハードウェアのキーボードに比べて文字のタイピングが面倒。
• マウスを前提としたインタラクション (マウスオーバーなど) を利用できない。
解決方法
• ユーザー体験 (UX) の観点からコンテンツの優先順位を明確にし、伝えたいことを
上位に提示する。
• 文字サイズや行間を十分な大きさにして、可読性を高くする。
• ズーム (画面表示の拡大) を妨げない。
• リンクやボタンなどは、精緻なポインティング操作でなくてもタップ / 実行できる
よう、十分な大きさにする。
• 文字入力 (タイピング) の発生をなるべく少なくする。
• マウスオーバー (hover) 依存のインタラクションを実装しない。

おつかれさまでした。

ウェブディレクターのための Web A11Y 勉強会 (Season 2) #12 [最終回]

Recommended

Recommended

More Related Content

Similar to ウェブディレクターのための Web A11Y 勉強会 (Season 2) #12 [最終回]

Similar to ウェブディレクターのための Web A11Y 勉強会 (Season 2) #12 [最終回] (20)

More from Kazuhiko Tsuchiya

More from Kazuhiko Tsuchiya (7)

ウェブディレクターのための Web A11Y 勉強会 (Season 2) #12 [最終回]