アクセシビリティについて考える会
目的
- LIPSを「より多くの人」に使ってもらいたい
- 障害がある人でも使いやすくするには、どういった対応が必要なのか、ガイドラインが整備されているのでそれを読んでみる
アクセシビリティガイドラインについて
アクセシビリティとは
- アクセスのしやすさのこと、=製品、サービスの利用のしやすさでもある
- どんな障害がある人でもその製品、サービスが使えるようにしたもの
- いわゆる「身体障害者」だけでなく、高齢者も障害を持っている事が多い(視覚、肢体不自由)
- ユーザビリティよりもアクセシビリティの方が幅広い利用状況、多様な利用者を前提としている
ウェブアクセシビリティ
- ウェブのアクセシビリティのこと。ウェブページにある情報、機能の利用しやすさ。
- さまざまな利用者が、さまざまなデバイスを使い、さまざまな状況でコンテンツを利用できるようにするのが望ましい
どんな障害があるか/どんな支援技術があるか
視覚
- 色の区別
- テキストが読めない
- 画面が見えない
- 文字拡大、色調補正、点字ディスプレイ、スクリーンリーダー
運動
- ボタンを正確に押せない
- 複雑な操作がしづらい
- タッチ操作ができない
- 拡大表示、音声入力/操作、スイッチ
認知/神経
- 長文が読みづらい
- 文字が理解しづらい
- UIを理解できない
聴覚
- 聞き取りづらい
- 音を認知できない
- 字幕がないと理解できない
- 字幕表示
ウェブアクセシビリティのガイドライン:WCAG2.0
- ウェブアクセシビリティを配慮するには、ガイドラインが存在してる
- 2008年のWCAG(Web Content Accessibility Guidelines) 2.0が一般的。
- JIS規格もあるが、JIS X 8341-3:2016でWCAG2.0と協調するように改正された
- ので、WCAG2.0を準拠すれば問題ないと思われる
WCAG2.0の内容について
原則
「ウェブのアクセシビリティ」を達成するには、以下の4つの原則が重要となってくる
- 知覚可能
- 操作可能
- 理解可能
- 堅牢
- 様々なユーザーエージェントで確実に解釈できること
WCAG2.0に書いてある内容(ガイダンスのレイヤー)
上の4原則を各々達成するために、以下の構成になっている
- 原則に基づいたガイドライン(計12個)
- ガイドラインの達成基準
- 具体的メリット
- 達成基準事例
ガイドラインの達成基準には、A(最低レベル)〜AAA(最高レベル)までの適合レベルが存在する。
注意すべき点:最高レベルで適合しているコンテンツであっても、すべての種類の障害に対応できるわけではない
WCAG2.0詳細
- 最低ラインとしてのレベルAのもののみ記述(最低ラインがAより高い場合はそれを記載する)
- わかりづらい表現がわりと多いですが、実装、対応タイミングで達成基準の事例を見るとだいぶ理解しやすいと思います(のでわからなかったらすみません
原則1: 知覚可能
1.1 非テキストコンテンツにはテキストによる代替を提供すること(画像、図等)
拡大印刷、点字、音声、平易な言葉に適宜変換するため
1.1.1 非テキストコンテンツには同等の目的を果たす、テキストによる代替が提供されること
1.2 時間依存メディアには代替コンテンツを提供すること(動画、音声への対応)
時間依存メディア=音声、動画、音声と動画、音声or動画とインタラクションの組み合わせのパターン
1.2.1 音声のみ、映像のみ(録画、録音):同等の情報を提示する代替手段が提供されていること
1.2.2 キャプション:キャプションが提示されること
1.2.3 音声解説、またはメディアによる代替:音声解説が提供されていること
1.3 情報及び構造を損なうことなく、様々な方法で表示できるコンテンツを作成する(よりシンプルなレイアウト等)
すべての情報がソフトウェアで判断できる形で利用可能=支援技術でレンダリング可能
1.3.1 情報、構造、関係がプログラムで決定できる、あるいはテキストで利用可能であること
- 見出しやインデント等での順序
- 特別なステータスを持つ単語はフォントファミリーの変更、太字、斜体、下線をつける
- 色情報に関しては、点字ディスプレイだと利用できないことがある
1.3.2 順序が意味に影響を及ぼす場合には、正しく読む順序がプログラムにより解釈可能であること
1.3.3 コンテンツを理解し操作するための説明は、形、大きさ、視覚的な位置、方向、又は音のような、構成要素が持つ感覚的な特徴だけに依存していない。
1.4 コンテンツを利用者によって見やすく、聞きやすいものにすること(色、音量の制御)
1.4.1 色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別するための唯一の視覚的手段になっていない。
1.4.2 ウェブページ上の音声が自動再生される場合、音声を一時停止もしくは停止するメカニズム、または音量レベルを調節できるメカニズムのいずれかを提供する
原則2: 操作可能
2.1 キーボード操作可能であること
2.1.1 キーボードインターフェースを通じて操作可能であること
2.1.2 キーボードインターフェースのみでフォーカスをはずすことが可能であること
2.2 利用者がコンテンツをよみ、使用するために十分な時間を提供すること(制限時間)
2.2.1 コンテンツに制限時間を設定するときは、以下のうち少なくとも1つを満たしていること
- 制限時間が解除できる
- 制限時間を調整できる(デフォルトの10倍を超える大幅な時間制限の調整が可能
- 制限時間が延長できる
- 例外:20時間より長い
- 例外:リアルタイムでなければならぬもの(オークション)
- 例外:制限時間が不可欠なもの
2.2.2 動きのある、点滅している、スクロールする、又は自動更新する情報は、利用者が一時停止、非表示、または更新頻度が調整することができる
2.3 発作を引き起こすようなコンテンツを設計しないこと
2.3.1 どの1秒間においても3回を超える閃光を放つものがない、又は閃光が一般閃光閾値及び赤色閃光閾値を下回っている。
2.4 ルートの案内、コンテンツを探す、現在位置を確認できるナビゲーションが提供されていること
2.4.1 繰り返されているコンテンツのブロックをスキップするメカニズムが利用できる
2.4.2 ウェブページにタイトルがあること
2.4.3 フォーカス可能なコンポーネントは、意味及び操作性を損なわない順序でフォーカスを受け取る
2.4.4 それぞれのリンクの目的が、テキスト単独、またはプログラムによる解釈が可能なリンクのコンテキストから判断できること
原則3: 理解可能
3.1 テキストのコンテンツを読みやすく理解可能にすること
3.1.1 ウェブページのデフォルトの自然言語がどの言語であるか、プログラムによる解釈が可能であること
3.2 ウェブページの表示、挙動を予測可能にすること
3.2.1 いずれのコンポーネントも、フォーカスを受け取ったときにコンテキストの変化を引き起こさない。
3.2.2 ユーザインタフェース コンポーネント の設定を変更することが、コンテキストの変化を自動的に引き起こさない。ただし、利用者が使用する前にその挙動を知らせてある場合を除く。
3.3 利用者の間違いを防ぎ、修正の支援をすること
3.3.1 入力エラーが自動的に検出された場合は、エラーとなっている箇所が特定され、そのエラーが利用者にテキストで説明される。
3.3.2 コンテンツが利用者の入力を要求する場合は、ラベル又は説明文が提供されている。
原則4: 堅牢 -支援技術を含む様々なユーザーエージェントが確実に解釈できる堅牢さが必要
4.1 ユーザーエージェントとの互換性を最大化すること
4.1.1 マークアップ言語
- 完全な開始、終了タグがある
- 仕様に準じて入れ子にする
- 重複した属性がない
- IDが一意
4.1.2 名前、役割は解釈が可能である
補足
必須項目
下記基準に対しては、基準を満たしていないとページの利用を妨げる可能性があるため、以下のものは対応が必須である
- 1.4.2 ウェブページ上の音声が自動再生される場合、音声を一時停止もしくは停止するメカニズム、または音量レベルを調節できるメカニズムのいずれかを提供する
- 2.1.2 キーボードインターフェースのみでフォーカスをはずすことが可能であること
- 2.2.2 動きのある、点滅している、スクロールする、又は自動更新する情報は、利用者が一時停止、非表示、または更新頻度が調整することができる
- 2.3.1 どの1秒間においても3回を超える閃光を放つものがない、又は閃光が一般閃光閾値及び赤色閃光閾値を下回っている。
実際どうやって達成していくのか
解説書、達成方法集が便利そう。
どの段階での対応が必要そうか
デザインが必要そうな項目
- 1.3 情報及び構造を損なうことなく、様々な方法で表示できるコンテンツを作成する
- 1.4 コンテンツを利用者によって見やすく、聞きやすいものにすること
- 2.3 発作を引き起こすようなコンテンツを設計しないこと
- 2.4 ルートの案内、コンテンツを探す、現在位置を確認できるナビゲーションが提供されていること
- 3.3 利用者の間違いを防ぎ、修正の支援をすること
文言が必要そうな項目
- 1.1 画像に対する代替コンテンツ
- 1.2 音声、映像に対するキャプション
プログラムでの対応が必要そうな項目(検討の結果デザイン等も必要になるかも)
- 2.1 キーボード操作可能であること
- 2.2 利用者がコンテンツをよみ、使用するために十分な時間を提供すること
- 3.1 テキストのコンテンツを読みやすく理解可能にすること
- 3.2 ウェブページの表示、挙動を予測可能にすること
- 4.1 ユーザーエージェントとの互換性を最大化すること
実際にやっていくとしたら、実装→支援ツールを用いて実際に利用してみて使えるか、のサイクルを回す必要がある。
iOS/Androidの対応
iOS
Android - Design
Android - 開発
参考資料
Q&A
- 対応しないと罰則ってあるの?
2021年5月には民間企業による障害者への合理的配慮提供を努力義務から義務にする改正が行われている。今の所罰則という話はなさそうだが、今後でてもおかしくないかも。
- 自動チェックツールとかある?
Google先生がトータルチェックツールとして出してるLightHouseでAccessibilityの項目も存在しそう
よくはなさそう…
Androidだと実装タイミングで怒られる(ContentDescriptionにnullいれちゃだめですね