アクセシビリティ アプリを企画する時点で考えること

「PWA Night vol.35 ～アクセシビリティ〜」での登壇資料です

Google Slidesで閲覧するにはこちら

1. アクセシビリティ アプリを企画する時点で 考えるべきこと 2022.01.19 PWA Night @ymrl
2. 自己紹介 • ymrl（やまある） • freee株式会社 プロダクトデザイン部 デザインリード • フロントエンドエンジニア兼UIデザイナー • freeeの社内向けデザインシステムを作る（デザイン・実装・運用）傍ら、 Webアクセシビリティの向上施策や社内教育をしています
3. アクセシビリティとは • Webのアクセシビリティ: あらゆる状況であっても使えるWebを目指す ◦ 誰もが、ほぼ同じコストで、ほぼ同じ量の情報を得られ、 同じ目標を達成できる • Webはそもそもアクセシビリティが高い ◦ だれでも、どこからでも、いつでもアクセスできる ◦ オープンな技術で構成されていて、カスタマイズもしやすい • 「障害者・高齢者対応」ではない ◦ もちろん、障害者や高齢者にとっては特に大きな意味をもつ
4. アクセシビリティについて詳しく freee株式会社の研修資料を公開しているのでそっちを見てください https://developers.freee.co.jp/entry/a11y-training
5. 本題
8. きょうの話 • Webアクセシビリティの話題のうち、PWAと関係ありそうなものを紹介 • 「PWAとして提供したい」というときに何に気をつければいいのか ◦ 特にアプリケーションの企画時点で考えておきたいもの ▪ たぶん、いまPWAやる人は何かを立ち上げる人が多いと思うので • 普通のWebの話とほとんど変わらないです ◦ むしろ、ネイティブアプリとのほうがよっぽど差異がありそう
9. PWAのアクセシビリティ、たぶんこんな感じ • ふつうのWebと比較して: ◦ 最新のブラウザがターゲットとなるので、チューニングしやすい （レガシーブラウザを無視する姿勢でいいのか？という問題はある） • ネイティブアプリと比較して: ◦ Webアクセシビリティの知見は、ネイティブと比較するとたくさんある （ネイティブアプリは、ほぼプラットフォーマーのドキュメント頼り） ◦ プラットフォームごとの対応方法の違いをあまり意識しなくていいはず
10. なぜ企画時から考えないといけないのか • 法的制約 ◦ アメリカ合衆国ではアクセシビリティ関連の訴訟が頻発 ◦ 日本でも障害者差別解消法が改正、民間事業者にも合理的配慮が義務化 • あとからアクセシビリティを要件に入れようにも、改善が困難なものがある ◦ アプリケーションの根幹に関わるもの、いろんな場所の前提となるもの ◦ エンジニア・デザイナーの小手先の工夫ではどうしようもないもの
11. WCAG (Web Content Accessibility Guidelines) • W3CによるWebアクセシビリティのガイドライン • 内容がそのままISOやJISになっている • 最新版は WCAG 2.1 ◦ 今年には WCAG 2.2 が勧告予定（現在はWorking Draft） ◦ WCAG 3.0 の策定もはじまっている • わりと難解なので、WCAGをベースにガイドラインを策定している freeeやCyber Agentの資料をあわせて読むといい
12. WCAGの達成基準 • A、AA、AAAの3段階のレベル分け ◦ Aは必ず達成してほしい、AAAは達成が比較的難しい • Webアクセシビリティの4原則 ◦ 知覚可能 — 個々の情報が「存在すること」を知覚できる ◦ 理解可能 — 個々の情報が何を表現しているのか理解できる ◦ 操作可能 — クリックや文字入力を受け付けるものを操作できる ◦ 堅牢 — 上記3つが、Webブラウザの種類や世代を超えて実現している
13. 参考URLリスト • WCAG 2.1 ◦ 原文 https://www.w3.org/TR/WCAG21/ ◦ 日本語訳 https://waic.jp/docs/WCAG21/ • WCAG 2.2 ◦ Working Draft https://www.w3.org/TR/WCAG22/ ◦ 変更分の日本語訳 https://accessible-usable.net/2021/05/entry_210529.html • freee アクセシビリティー・ガイドライン https://a11y-guidelines.freee.co.jp/ • Ameba Accessibility Guidelines https://a11y-guidelines.ameba.design/
14. ここからの説明 • WCAGの達成基準のうち、アプリ立ち上げ時に特に考慮されるべきものを ピックアップして紹介します • WCAGの文面は以下のページによるものです ◦ WCAG 2.1: ウェブアクセシビリティ基盤委員会による日本語訳 https://waic.jp/docs/WCAG21/ ◦ WCAG 2.2: ▪ Working Draft (21 May 2021) https://www.w3.org/TR/2021/WD-WCAG22-20210521/ ▪ Accessible & Usable による日本語訳 https://accessible-usable.net/2021/05/entry_210529.html
15. 表示の向き
16. 達成基準 1.3.4 表示の向き (AA) コンテンツは、その表示及び操作を、縦向き (portrait) 又は横向き (landscape) などの単一の向きに制限しない。ただし、その表示の向きが必要不可欠な場合は 例外とする。
17. 表示の向き • 端末の向きを変えられないユーザーが存在する ◦ 例: 肢体不自由で、自力で端末を保持できず、固定して使用している • 端末の向きを強制しないようにする ◦ Webではあんまりやらないけど、ネイティブアプリではやりがち ▪ 作り込んでしまってからでは対応しづらい ◦ webmanifest での orientation 指定は関係あるかも （すいません、ここは検証できてません）
18. リフロー
19. 達成基準 1.4.10 リフロー (AA) コンテンツは、情報又は機能を損なうことなく、かつ、以下において 2 次元スク ロールを必要とせずに提示できる: • 320 CSS ピクセルに相当する幅の縦スクロールのコンテンツ。 • 256 CSS ピクセルに相当する高さの横スクロールのコンテンツ。 利用や意味の理解に 2 次元のレイアウトが必須である一部のコンテンツを除く。
20. リフロー • 画面を拡大しているユーザーが閲覧に不自由ないようにする ◦ 弱視のユーザーは画面をむっちゃ拡大して使っている ◦ 1280×1024px の画面を 400% にすると 320×256px になる ◦ 横スクロール（縦書きなら縦スクロール）が出ないようにする • これってレスポンシブレイアウトってやつじゃん！ ◦ レスポンシブレイアウト＝デスクトップでもスマホでも快適 ▪ そしてそれが、弱視で画面を拡大している人にとっても快適になる ◦ 最近のスマホは320pxよりも広いけど、そこに最適化しすぎない
21. キーボード・マウス操作
22. 達成基準 2.1.1 キーボード (A) コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要す ることなく、キーボードインタフェースを通じて操作可能である。ただし、その 根本的な機能が利用者の動作による始点から終点まで続く一連の軌跡に依存して 実現されている場合は除く。
23. 達成基準 2.1.3 キーボード (例外なし) (AAA) コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要す ることなく、キーボードインタフェースを通じて操作可能である。
24. キーボード操作はすごく大事 • タッチパネルやマウスが使えなくても、キーボードなら使える場合がある ◦ 例: 全盲で画面を全く見ず、音声読み上げで操作している ◦ 例: キーボードを口に咥えた棒で操作している ◦ スマートフォンもキーボードで操作できる • 独特な操作を必要とするとき、キーボード操作で代替できるか？ ◦ 例: スワイプ操作で「前へ」「次へ」や「削除」のアクションをする
25. 達成基準 2.5.1 ポインタのジェスチャ (A) マルチポイント又は軌跡ベースのジェスチャを使って操作する機能はすべて、軌 跡ベースのジェスチャなしのシングルポインタで操作することができる。ただ し、マルチポイント又は軌跡ベースのジェスチャが必要不可欠である場合は例外 とする。
26. (WCAG 2.2) 2.5.7 Dragging Movements (AA) All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential. ドラッグ動作を用いて操作する機能はすべて、ドラッグなしのシングルポインタ で完遂することができる。ただしドラッグが必要不可欠である場合は例外とす る。
27. マウスやタッチスクリーンの、ドラッグやジェスチャー • マウス、トラックボール、トラックパッド、タッチパネル等でのドラッグや ジェスチャーは、得意不得意が現れやすい • キーボード操作以外でも、代替する手段があるのが望ましい
28. 認証・セッション
29. 達成基準 2.2.1 タイミング調整可能 (A) コンテンツに制限時間を設定する場合は、次に挙げる事項のうち、少なくとも一つを満たしている • 解除:制限時間があるコンテンツを利用する前に、利用者がその制限時間を解除することができる。又は、 • 調整:制限時間があるコンテンツを利用する前に、利用者が少なくともデフォルト設定の 10 倍を超える、大幅 な制限時間の調整をすることができる。又は、 • 延長:時間切れになる前に利用者に警告し、かつ少なくとも 20 秒間の猶予をもって、例えば「スペースキーを 押す」などの簡単な操作により、利用者が制限時間を少なくとも 10 倍以上延長することができる。又は、 • リアルタイムの例外:リアルタイムのイベント (例えば、オークション) において制限時間が必須の要素で、そ の制限時間に代わる手段が存在しない。又は、 • 必要不可欠な例外:制限時間が必要不可欠なもので、制限時間を延長することがコンテンツの動作を無効にす ることになる。又は、 • 20 時間の例外:制限時間が 20 時間よりも長い。
30. 達成基準 2.2.5 再認証 (AAA) 認証済のセッションが切れた場合は、再認証後でもデータを失うことなく利用者 が操作を継続できる。
31. 達成基準 2.2.6 タイムアウト (AAA) データの損失を引き起こす恐れのある利用者の無操作の残り時間が警告される。 ただし、利用者が 20 時間以上何もしなくてもデータが保持される場合は、この 限りではない。
32. セッションの有効時間 • 障害のあるユーザーは、そうでないユーザーよりも読んだり操作したりに 時間がかかる場合が多い • なので、セッションの有効時間は20時間あったほうがいい ◦ 20時間以上継続して起きてる人はいないだろうみたいな推測らしい ◦ 必要に応じて再度パスワードを求めるなどするのもよさそう • セッション長くするのは、セキュリティ観点ではどうあるべきなのかも 考えて決めないといけなくて、難しい
33. 達成基準 1.1.1 非テキストコンテンツ (A) 利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる 代替が提供されている。ただし、次の場合は除く: （中略） • CAPTCHA：非テキストコンテンツが、コンピュータではなく人間がコンテンツにアクセ スしていることを確認する目的で用いられているとき、テキストによる代替は、その非テ キストコンテンツの目的を特定し、説明している。なおかつ、他の感覚による知覚に対応 して出力する CAPTCHA の代替形式を提供することで、様々な障害に対応している。 （後略）
34. (WCAG 2.2) Accessible Authentication For each step in an authentication process that relies on a cognitive function test, at least one other authentication method is available that does not rely on a cognitive function test, or a mechanism is available to assist the user in completing the cognitive function test. 認知機能テストに依存する認証プロセスの各ステップにおいて、認知機能テスト に依存しない少なくとも1つの他の認証方法が利用可能である、または、利用者 が認知機能テストを完遂することを支援するメカニズムが利用可能である。
35. CAPTCHAとかパズル認証とか • ロボットではないことを証明するためのやつ • reCAPTCHAでは音声による代替手段が用意されている。ただし英語 • パズル認証は、とにかく視覚障害者からの評判が悪い ◦ （視覚障害当事者の同僚のかわりに認証だけやるの、何度かやった）
36. そのほか • いろいろあります
37. 手戻りをなくすには
38. よかったらfreeeのチェックリスト使ってください • freee社内で実際に運用しているチェックリストを配布しています https://a11y-guidelines.freee.co.jp/checks/checksheet.html • 「デザイン」のチェック項目を使えば、実装より前の段階で気付くべきもの がわかるようになっているはず • ガイドラインの本文で紹介しましたが、たぶんチェックリストのほうが とっつきやすいです
39. 39 UXチームがUIデザインを作成→エンジニアが開発→QAチームがテストの流れがあるので、 
 デザイナーがデザイン、エンジニアがコード、QAがプロダクトのアクセシビリティチェックを行う 
 チェックのタイミング（プロダクト開発）
 デザイナー エンジニア QA デザインの アクセシビリティチェック コードの アクセシビリティチェック プロダクトの アクセシビリティチェック freeeの研修スライド（アクセシビリティー研修 Basic） https://developers.freee.co.jp/entry/a11y-training https://docs.google.com/presentation/d/1_QbqhPfaAd0xry-1ajOW5xnWfVzDmGJPh4f3fX2wjn0/edit#slide=id.gf55b9bce77_0_257l
40. 立ち上げ時に（本当に）やるべきこと • 「アクセシビリティをやるぞ！」という宣言をする • チームメンバーと合意をつくる
41. ぜひ、アクセシブルな Progressive Web Application を 作ってください