🎇華金勉強会 /アクセシビリティについて考える会

アクセシビリティについて考える会

目的

  • LIPSを「より多くの人」に使ってもらいたい
    • 障害がある人でも使いやすくするには、どういった対応が必要なのか、ガイドラインが整備されているのでそれを読んでみる

アクセシビリティガイドラインについて

 

アクセシビリティとは

  • アクセスのしやすさのこと、＝製品、サービスの利用のしやすさでもある
    • どんな障害がある人でもその製品、サービスが使えるようにしたもの
      • いわゆる「身体障害者」だけでなく、高齢者も障害を持っている事が多い（視覚、肢体不自由）
  • ユーザビリティよりもアクセシビリティの方が幅広い利用状況、多様な利用者を前提としている

ウェブアクセシビリティ

  • ウェブのアクセシビリティのこと。ウェブページにある情報、機能の利用しやすさ。
  • さまざまな利用者が、さまざまなデバイスを使い、さまざまな状況でコンテンツを利用できるようにするのが望ましい

どんな障害があるか/どんな支援技術があるか

視覚

  • 色の区別
  • テキストが読めない
  • 画面が見えない
    • 文字拡大、色調補正、点字ディスプレイ、スクリーンリーダー

運動

  • ボタンを正確に押せない
  • 複雑な操作がしづらい
  • タッチ操作ができない
    • 拡大表示、音声入力/操作、スイッチ

認知/神経

  • 長文が読みづらい
  • 文字が理解しづらい
  • UIを理解できない

聴覚

  • 聞き取りづらい
  • 音を認知できない
  • 字幕がないと理解できない
    • 字幕表示

ウェブアクセシビリティのガイドライン：WCAG2.0

  • ウェブアクセシビリティを配慮するには、ガイドラインが存在してる
  • 2008年のWCAG（Web Content Accessibility Guidelines） 2.0が一般的。
    • JIS規格もあるが、JIS X 8341-3:2016でWCAG2.0と協調するように改正された
    • ので、WCAG2.0を準拠すれば問題ないと思われる

WCAG2.0の内容について

WCAG 2.0 への適合を理解する
すべての WCAG 2.0 の達成基準は、客観的にコンテンツがその基準を満たしているかどうかを判断できるように、テスト可能な基準として記述されている。達成基準のテストでは、自動的なテストと人間による判断を組み合わせる必要がある。コンテンツをテストするのは、様々な障害のある人がウェブをどのように使っているのかを理解している人でなければならない。 ここでいうテストやテスト可能というのは、機能面のテストのことを指している。つまり、コンテンツが想定していた通りに機能することを確認するということである。あるいは、ここでは、達成基準を満たしていることを確認するといってもよい。コンテンツがすべての達成基準を満たしていたとしても、それでも様々な障害のある利用者がそのコンテンツを使うことができるとは限らない。そのため、必要とされる機能面のテストに加えて、ユーザビリティテストを実施することも推奨している。ユーザビリティテストの目的は、利用者が想定した目的に沿ってそのコンテンツをどこまで使うことができるかを確認することである。ユーザビリティテストを実施する際には、テスト参加者に障害のある利用者を含めることを推奨する。 基準への適合とは、その基準の「要件」に合っている、あるいは満たしていることを意味する。WCAG 2.0 において、「要件」となるのは達成基準である。WCAG 2.0 に適合するためには、達成基準を満たす必要がある。つまり、達成基準に反するコンテンツがないということである。 注記: ある達成基準について、適用対象となるコンテンツを含まないコンテンツにおいては、その達成基準は満たされているということを意味する。 ほとんどの標準には、適合レベルは一つしかない。しかし、より高いレベルのアクセシビリティを要求したり可能にしたりする様々な状況に対応するために、WCAG 2.0 には三つの適合レベルがあり、そのため達成基準にも三つのレベルがある。 コンテンツが WCAG 2.0 に「適合している」とみなされるためには、満たさなければならない五つの要件がある。この節では、それらの要件に関する簡単な注釈を提供する。なお、この節は、今後寄せられる質問に対処するため、あるいは様々な適合要件を満たす方法の新しい事例を提供するために、時間とともに拡充されていく予定である。 1. 適合レベル: 以下に挙げる適合レベルの一つを完全に満たしていること。 レベル A:レベル A (適合の最低レベル) で適合するには、 ウェブページがレベル A 達成基準のすべてを 満たすか、又は 適合している代替版 を提供する。 レベル AA: レベル AA で適合するには、ウェブページはレベル A 及びレベル AA 達成基準のすべてを満たすか、又はレベル AA に適合している代替版を提供する。 レベル AAA: レベル AAA で適合するには、ウェブページがレベル A、レベル AA、及びレベル AAA 達成基準のすべてを満たすか、又はレベル AAA に適合している代替版を提供する。 注記 1: ウェブページは、記載したレベルでのみ WCAG 2.0 に適合できるが、コンテンツ制作者は、その適合レベルよりも高いレベルの達成基準の達成状況を (表明の中で) 示すことが推奨される。 注記 2: コンテンツの中には、レベル AAA 達成基準のすべてを満たすことのできないものもあるため、サイト全体の一般的な方針としてレベル AAA での適合を要件とすることは推奨されない。 最初の要件は、適合レベルに関するものである。基本的には、ページ上のすべての情報が適合している、もしくは、そのページから利用可能な 適合している代替版 があるということである。また、この要件は、少なくともレベル A の達成基準すべてを満たさなければどのレベルでも適合することはできないということも説明している。 注記が指摘しているのは、特定のレベルでの適合に留まらずに、より高いレベルの適合に向けても取り組み、もし自分たちが望むのであればその進捗状況を報告することをコンテンツ制作者に推奨するということである。 また、「適合している代替版」を提供する達成方法を紹介している「 適合している代替版を理解する 」も参照のこと。 2.
https://waic.jp/docs/UNDERSTANDING-WCAG20/conformance.html#uc-conformance-requirements-head
 

原則

「ウェブのアクセシビリティ」を達成するには、以下の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 コンテンツに制限時間を設定するときは、以下のうち少なくとも１つを満たしていること
  • 制限時間が解除できる
  • 制限時間を調整できる（デフォルトの１０倍を超える大幅な時間制限の調整が可能
  • 制限時間が延長できる
  • 例外：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回を超える閃光を放つものがない、又は閃光が一般閃光閾値及び赤色閃光閾値を下回っている。

実際どうやって達成していくのか

WCAG 2.0 解説書
この文書、「WCAG 2.0 解説書」は、 Web Content Accessibility Guidelines (WCAG) 2.0 (日本語訳) [WCAG20] を理解して実践するために不可欠な案内書である。WCAG 2.0 の関連文書群の中の一つだが、この文書のコンテンツはガイダンスを提供する参考文書であり、WCAG 2.0 に適合するための要件を定める規定文書ではない。WCAG、関連技術文書、教育用素材へのイントロダクションは、 Web Content Accessibility Guidelines (WCAG) Overview を参照のこと。 WCAG 2.0 には、WCAG 2.0 に適合するための達成基準がある。個々の達成基準は、テスト可能な記述内容になっており、特定のウェブコンテンツに適用した際に適合もしくは不適合であると判断できるようになっている。「WCAG 2.0 解説書」が提供するのは、それぞれの達成基準に関する詳細な情報で、達成基準の意図、達成基準の中で用いられている重要な用語、そして、WCAG 2.0 の達成基準が様々な種類の障害のある利用者にどのように役に立つのかが記されている。また、この文書は、様々なウェブコンテンツ技術 (例えば、HTML、CSS、XML) を用いて達成基準を満たしているウェブコンテンツの事例、そして達成基準を満たしていないウェブコンテンツのよくある事例も提供している。 この文書は、それぞれの達成基準を満たすための特定の達成方法も示している。それぞれの達成方法をどのように実装するかの詳細は、 WCAG 2.0 達成方法集で提供されているが、この「WCAG 2.0 解説書」では各達成方法と達成基準との関係に関する情報を提供している。達成方法は、達成基準への対応レベルによって分類されている。「十分な達成方法」とは、(それ単体もしくは他の達成方法との併用により、) ある達成基準を満たすのに 十分であると考えられる達成方法であり、それ以外は参考達成方法で用いるかどうかは任意である。いくつかの達成方法は、ある特定のウェブコンテンツ技術を用いる場合にはそれが唯一の既知の手法であるかもしれないが、どの達成方法も WCAG 2.0 に適合する上で 必須 というわけではない。「参考達成方法」とは、(テスト可能ではない、あるいは、完全な支援ができないので、) それ自体では達成基準を満たすのに十分ではないが、アクセシビリティをさらに向上させるために、コンテンツ制作者には可能であればそれらを用いることが推奨される。 達成基準を満たす達成方法に加えて、「よくある失敗例」も文書化されている。これらの「よくある失敗例」は WCAG 2.0 への不適合を引き起こすものとして知られている制作方法である。制作者は、WCAG 2.0 の達成基準を満たすためにそれらの方法を避けなければならない。 この文書は、W3C Web Accessibility Initiative (WAI) が提供する WCAG 2.0 関連文書群の一つである。この文書は、WCAG 2.0 が W3C 勧告として公開されたのと同時に、ワーキンググループノートとして公開されたものである。WCAG 2.0 とは異なり、「WCAG 2.0 解説書」の情報は随時更新されていく予定である。WCAG、関連技術文書、教育用素材へのイントロダクションは、 Web Content Accessibility Guidelines (WCAG) Overview を参照のこと。
https://waic.jp/docs/UNDERSTANDING-WCAG20/Overview.html
解説書、達成方法集が便利そう。
 
どの段階での対応が必要そうか

デザインが必要そうな項目

  • 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

  • 自動チェックツールとかある？
Google先生がトータルチェックツールとして出してるLightHouseでAccessibilityの項目も存在しそう
ちなみに　https://lipscosme.com/
よくはなさそう…
アプリのユーザー補助機能をテストする | Android デベロッパー | Android Developers
ユーザー補助機能をテストすることで、ユーザーの立場でアプリを体験し、見逃しがちな使い勝手の問題を見つけることができます。また、障がいのあるユーザーのみにとどまらず、すべてのユーザーにとって有用で使いやすいアプリにするためのヒントが得られます。 最良の結果を得るためには、このドキュメントで説明する以下のアプローチをすべて使用してください。 手動テスト: Android ユーザー補助サービスを使用してアプリを操作します。 分析ツールによるテスト: ツールを使用してアプリのユーザー補助機能の改善点を見つけ出します。 自動テスト: Espresso と Robolectric でユーザー補助機能テストを有効にします。 ユーザーテスト: 実際にアプリを操作したユーザーからフィードバックを受けます。 手動テストでは、アプリをユーザーの視点で確認できます。Android AccessibilityService オブジェクトによって、アプリからユーザーへのコンテンツ表示方法や、ユーザーによるコンテンツ操作方法が変わります。ユーザー補助サービスを使用してアプリを操作することにより、ユーザーの立場でアプリを体験できます。 TalkBack は Android に組み込まれているスクリーン リーダーです。TalkBack を有効にすると、ユーザーは画面を見ずに Android デバイスを操作できます。視覚障がいのあるユーザーは、アプリの使用に TalkBack を必要とする可能性があります。 TalkBack をオンにする TalkBack を初めて有効にする場合は、チュートリアルが開始されます。チュートリアルをもう一度見るには、 デバイスの設定アプリを開きます。 [ユーザー補助] に移動し、[TalkBack] を選択します。 TalkBack 画面の上部にある [OFF] をタップして TalkBack を有効にします。 確認ダイアログで権限を確認し、[OK] を選択します。 注: [設定] > [ユーザー補助] > [TalkBack] >
https://developer.android.com/guide/topics/ui/accessibility/testing?hl=ja#analysis
Androidだと実装タイミングで怒られる（ContentDescriptionにnullいれちゃだめですね