Webアプリケーションアクセシビリティ解説ウェビナー「8章 アクセシブルなUI設計の原理を導く」

野ッカーという新しいアイデア
https://note.com/nikonote/n/n10043591c070

Transcript

2. 　 2 Webデザイン会社ビジネス・アーキテクツに勤務ののち、 製品を通じた多様な働き方の実現を目指し 2017年にfreeeに参加。 デザインチームのマネジメント、 およびアクセシビリティ普及啓発を行う。 ほか、外部コンサルタントとして Ubie、STUDIO、CULUMUの アクセシビリティ改善を推進。 ウェブアクセシビリティ基盤委員会（WAIC）委員、 人間中心設計推進機構（HCD-Net） 評議委員。 著書（共著）、監訳書に 「Webアプリケーションアクセシビリティ」 「デザイニングWebアクセシビリティ」、 「コーディングWebアクセシビリティ」 「インクルーシブHTML+CSS&JavaScript」がある。 伊原 力也 Rikiya Ihara @magi1125
3. 3 いくつかお知らせ • 今日は８章のみの話になります。7章については以下動画をご覧ください ▪ ウェブアクセシビリティ社内教育のすゝめ 〜品質か、営業か〜 ▪ 自社サービスのアクセシビリティ向上、良いパターンとアンチパターン • 書籍がお手元にあることを前提にした解説になります • 後半はUIデザインの前提知識を要求する話になります ◦ ご不明な点があれば、お気軽に @magi1125 までDM or リプライください。 ベストエフォートで回答します
4. 4 本内容は、書籍 「Webアプリケーションアクセシビリティ」 の8章から抜粋してお届けします Amazonで販売中！ 以下QRコードもご利用ください
5. 5 1. はじめからアクセシブルにするには 2. 多様な利用状況の存在を知る 3. 利用状況から共通の課題を知る 4. アンチパターンと対策を知る 5. アクセシブルなUI設計の原理 目次
6. 　 1. はじめからアクセシブルにするには
7. 7 「今日から始める現場からの改善」の限界 • 本書は「よく起きがちなアクセシビリティの課題にどう対処するか」 という流れで解説を進めてきた ◦ デザインした/実装した → チェックする → 改善する • これは、最初の取り掛かりとしては必要な流れ • しかし、実はこれは最も良い順番ではありません（！）
8. 8 そもそもの「ガイドラインの限界」 • ガイドラインの前提： そのUIが存在する必要があるなら、このようにアクセシブルにせよ • ガイドラインには「UIを無くせ」や「違うUIに変更せよ」とは書けない • ガイドラインにおける「アクセスできる」ことと、 支援技術利用時に「タスクが完了できる」ことはイコールではない • 複雑なUIは、実装でアクセシブルにしても複雑なまま ▪ カルーセル、モーダルダイアログ、ドラッグ＆ドロップ、 マウスオーバーでの追加表示、スナックバーやトースト… • 設計によってはアクセシブルにすることがそもそも不可能な場合もある
9. 9 「チェックする」の限界 • 設計の時点ですでにアクセシビリティが低いものに対し、 あとからチェックで課題を洗い出す順番だと、課題はいつまでも生じ続ける ◦ 「今はひとまずチェックで引っかかった課題を解消しよう」と考えがち ◦ チェックと対処の繰り返しだけでは、本質の理解に至るのは困難 ◦ 「アクセシビリティはどこから指摘が来るかわからないモグラたたき的な存在」 という印象は拭えないまま
10. 10 「改善する」の限界 • 間違ったイメージで、不適切な「アクセシビリティ対策」をしてしまうことがある ◦ 画像の代替テキストを長文にする ◦ スクリーンリーダー向けに過剰な隠しテキストを入れる ◦ スクリーンリーダーでの読み上げ順を調整する目的でtabindex属性を使う ◦ 画面の変化を必要以上にaria-live属性で通知する • 間違ったイメージで、これらをチェックリスト上はOKにしてしまうことがあり得る
11. 11 限界を超え、はじめからアクセシブルにするには • 多様な利用状況の存在を知る • 利用状況から共通の課題を知る • アンチパターンと対策を知る ※既存改善を進めるなかで疑問が生じ「はじめから」を意識するため、この章は最終章になっている
12. 　 2. 多様な利用状況の存在を知る
13. 13 多様な利用状況の存在を知る • デザイナーがPCやモバイルデバイス向けのUIを設計できるのは、 自分の延長線上として利用状況のイメージを持てるから • 逆に言えば「私たちは知らないものに対してデザインすることはできない」 ◦ 視力、色覚、聴力に課題がなければ「知覚できるのか？」は想像しにくい ◦ マウスやタッチ操作に課題がなければ「操作できるのか？」は想像しにくい ◦ 支援技術やアクセシビリティ機能を知らなければ、使い方は想像しにくい • この状態から抜け出すためには、支援技術を操作して体験し、 使い方のイメージを感覚として身に付けることが必要
14. 14 ぜひ付録を見ながら支援技術を触って欲しい • 支援技術を日々使っている当事者に話を聞いたり、 使っている様子を見せてもらうのはもちろん大事。しかしそれには準備が必要 • いっぽう、自分の手元で支援技術を試して、想像してみるのは今すぐできる • 30分ぐらいずつでも触ってみる、支援技術を通してアプリを使ってみる • それだけで、何が起きるのか？何が必要なのか？の解像度は飛躍的に上がる • 「こんなにもさまざまな方法でOSやWebが使えるんだ！」という面白さもある ※実は付録も8章に入っていたが、長すぎたので分割された ※紙の本だと、付録の文字サイズが少し小さい。それでもすべて入れたかった
15. 15 付録の構成の秘密 • 使い方をイメージしやすい→イメージしにくいの順番になっている ◦ ポインティングデバイスと支援技術： 物理補助、OS設定、マウスキー、 タッチデバイスにマウス接続、視線入力やカメラ入力、クリックの置換 ◦ キーボード操作と支援技術: 物理補助、OS設定、スクリーンキーボード、 タッチデバイスでキーボード接続 ◦ 操作方式を変更する支援技術: 音声コントロール、スイッチコントロール ◦ 画面表示と支援技術: 文字や画面の拡大、スクリーンリーダー
16. 16 「画面＋マウス」と、スクリーンリーダーのあいだ • 画面を見ず、マウスも使わないスクリーンリーダーでの操作は、 最も「想像し得ない」使い方。ある種のショック療法としてよく用いられている • しかし、強烈すぎるあまり、アクセシビリティ＝スクリーンリーダーの誤解も… • 一般的な利用とスクリーンリーダー、そのあいだのグラデーションの使い方を 試していくことが、「知っている利用状況」の引き出しを増やすことにつながる • さまざまな支援技術を試すことで、支援技術というしくみがわかり、 そこには共通点があることがわかる
17. 17 マウスキー
18. 18 スクリーンキーボード
19. 19 フルキーボードアクセス
20. 20 スマートフォンにマウスとキーボードを接続
21. 21 ヘッドポインタ＋代替ポインタアクション
22. 22 滞留コントロール
23. 23 音声コントロール
24. 24 スイッチコントロール
25. 25 画面の拡大（高倍率）
26. 26 スクリーンリーダー
27. 　 3. 利用状況から共通の課題を知る
28. 28 支援技術には共通の課題がある • アクセスできるようになるかわりに、トレードオフが起きる • まとめると、この２点になる ◦ 操作に多くの手順や時間を要する ◦ 画面が一望できず推定と記憶に頼る • この２点を覚えておくと応用が効く ◦ 支援技術では必ずこの課題が生じるので、この２点を覚えておけば、 そこから個別のケースを思い出せる
29. 29 操作に多くの 手順や時間を要する ※すべての支援技術で起きる 操作しにくさを時間で解決する • 物理的な補助器具を使う • OSの設定で反応を遅くする • 時間経過による自動操作を使う • 音声で操作や認識を行う 操作精度を繰り返しでカバーする • 入力方向が限定される • 細かな操作が難しい • 滞留コントロールの操作が難しい 操作をモードに分けて対処する • アクセシビリティオプションで段階的な操作に分ける • 操作デバイスを1つに集約してモード切替を行う • 正確なポイントのために精度向上モードに入る 段階的な操作に変換する • 操作方法を事前に計画する • クリック時のアクションを先に指定する • スクロールを都度指示する • キーボードのみで全体を操作する 画面が一望できず 推定と記憶に頼る ※文字や画面の拡大(拡）、 スクリーンリーダー(SR)で起きる 部分的な拾い読みで構造を推定する • [拡]表示領域を動かし倍率を変化させる • [SR]ジャンプ機能を使って構造を推定する 情報の取捨選択に時間をかける • [拡]重要度の低い薄い文字でも注視する • [SR]重要度の判断には読み上げが必要になる 画面が変化したことの理解に時間をかける • [拡]視界外の変化に気付けない、予想外の変化に戸惑う • [SR]カーソル外の変化に気付けない 記憶に頼って利用時の文脈を維持する • [拡]記憶が薄れる前に表示範囲を動かす • [SR]音が揮発して記憶が薄れやすい 支援技術のトレードオフ一覧
30. 　 4. アンチパターンと対策
31. 31 支援技術利用時の課題を「増幅」するアンチパターン • 「操作に多くの手順や時間を要する」と 「画面が一望できず推定と記憶に頼る」を、より増幅するアンチパターンがある ◦ 1画面に多くの状態を持つ ◦ テキストが省略された画面 ◦ 小さく密集した操作対象 ◦ ユーザーの要求ではない動作 ◦ 確認や報告が多い ◦ 入力が多く手間どる • 利用をあきらめてしまったり、利用可能にするための実装が複雑化するもの
32. 32 再掲：そもそもの「ガイドラインの限界」 • ガイドラインの前提： そのUIが存在する必要があるなら、このようにアクセシブルにせよ • ガイドラインには「UIを無くせ」や「違うUIに変更せよ」とは書けない • ガイドラインにおける「アクセスできる」ことと、 支援技術利用時に「タスクが完了できる」ことはイコールではない • 複雑なUIは、実装でアクセシブルにしても複雑なまま • 設計によってはアクセシブルにすることがそもそも不可能な場合もある
33. 33 「そのUIはその形で存在する必要がある」の前提を疑う • そもそも表示しないようにする、操作や入力を行わずに済むように考える。 UIを無くせば、アクセシビリティの問題も発生しない • UIを無くすことは難しくても、シンプルな形に置き換えられないかと考える。 そこから解決の道が見える • ガイドラインには「UIを無くせ」や「違うUIに変更せよ」とは書けない • ガイドラインの向こう側に行けるのは、唯一、設計者だけ
34. 34 1画面に多くの状態を持つ • 状態： 1画面内に操作対象が散らばり、多数の状態の組み合わせが存在する • 問題： 操作対象の行き来が負担になる、拡大時やSRでは状態把握が難しくなる ◦ 切り替えウィジェットの濫用｜対策: 1画面1フォームにする ◦ 複数ペイン構成の濫用｜対策: 一覧と詳細を独立させる ◦ モーダルダイアログの濫用｜対策: 別の形に置き換える （インライン表示、ディスクロージャー、モード切替、詳細画面化）
35. 35 テキストが省略された画面 • 状態： セクション見出し、アイコンラベル、フォームラベル、リンクラベルの省略 ◦ 2.1節、2.3節、2.4節、3.1節、3.2節、4.1節、4.4節、4.5節、4.9節で登場する • 問題: テキストの手がかりがないと構造の把握が難しくなる • 対策: 省略しないようにする？ ◦ 省略しないようにするには、表示要素自体を減らすことが必要
36. 36 小さく密集した操作対象 • 状態： ボタン、リンク、フォームコントロールが小さい。 それらのマージンが小さく接近している • 問題： 画面が見えづらいと認識しづらい、精密なポイントができないと操作困難 • 対策: 大きくしてマージンを広げる？ ◦ 大きくしてマージンを広げるには、表示要素自体を減らすことが必要
38. 38 ユーザーの要求ではない動作（1/2） • 状態： ユーザーが明示的にアクションしていないのに自動的に動作するUI • 問題： 何が起きているかわからない、想定外の状況への対処が大きな負担になる ◦ ユーザーの操作を伴わずに自動で動く｜対策: 自動で動かさない （4.7節「アニメーション」、5.3節「カルーセル」） ◦ マウスオーバーだけで要素を追加表示｜対策: 追加表示しない or 気合実装 （2.2節「キーボード操作の基本」、4.8節「モバイルデバイス」、5.4節「シンプルなツールチップ」） ◦ キーボードフォーカスが自動で移動｜対策: 自動で動かさない （3.4節「ユーザーが予測できる動作」） ◦ 変化した結果が画面にとどまらずに消滅｜対策: 別の方法を模索する （5.2節「通知」）
39. 39 ユーザーの要求ではない動作（2/2） ◦ スクロールスナップ｜対策: 使わない ◦ 無限スクロール｜対策: 読み込みボタン置く or 気合実装 ◦ 予想外のモーダルダイアログ｜対策: 本当に必要なのか？を再考 ◦ 新規タブ｜対策: 不用意に使わない、ルールを定め明示する
41. 41 確認や報告が多い • 状態： 確認・結果報告・エラーダイアログがたくさん出る • 問題： 操作対象の行き来が負担になる、拡大時やSRでは状態把握が難しくなる • 対策: いくつかの方法を組み合わせてダイアログを削減する ◦ 確認・結果報告：入力を即時反映し、かつ元の状態に戻せるようにする ▪ 「誤った操作」がなくなるので確認も結果報告も不要になる ◦ 確認： 別の方法で意思確認する（事前チェックボックス、２段階操作など） ◦ 結果報告： 処理によって変化が起きる画面に遷移する、インライン表示する ◦ エラー： 閉じると分からなくなるので原則使わない
43. 43 入力が多く手間どる • 状態： 入力が多い • 問題： 支援技術利用時は入力の負担が大きく、利用をあきらめることに直結する • 対策： 入力を減らす ◦ システム側に複雑性を移動する（外部連携、自動化、初期値設定、サジェスト等） ◦ ガッツを見せる（誤解やクレームを恐れず仕様を割り切る）
44. ペーパーレス年末調整2018をリリース！配偶者控除改正に伴うSmartHRの対応もご確認ください！
45. 　 5. アクセシブルなUI設計の原理
46. 46 • シンプルなモデル • 明快な呼び名 • シングルカラム優先 • 1画面に1トピック • 最大限のテキスト • 大事なものは常に上 • キーボードのみ、クリックのみ • 一貫性 • 主導権はユーザーに • 複雑性の移動 • モードレスネス
47. 47 • シンプルなモデル • 明快な呼び名 • シングルカラム優先 • 1画面に1トピック • 最大限のテキスト • 大事なものは常に上 • キーボードのみ、クリックのみ • 一貫性 • 主導権はユーザーに • 複雑性の移動 • モードレスネス • 1画面に多くの状態を持つ • テキストが省略された画面 • 小さく密集した操作対象 • ユーザーの要求ではない動作 • 確認や報告が多い • 入力が多く手間どる • 操作に多くの手順や時間を要する • 画面が一望できず推定と記憶に頼る • ポインティングデバイスと支援技術 物理補助、OS設定、マウスキー、 タッチデバイスにマウス接続、 視線入力やカメラ入力、クリックの置換 • キーボード操作と支援技術 物理補助、OS設定、スクリーンキーボード、 タッチデバイスでキーボード接続 • 操作方式を変更する支援技術 音声コントロール、スイッチコントロール • 画面表示と支援技術 文字や画面の拡大、スクリーンリーダー
48. 48 • シンプルなモデル • 明快な呼び名 • シングルカラム優先 • 1画面に1トピック • 最大限のテキスト • 大事なものは常に上 • キーボードのみ、クリックのみ • 一貫性 • 主導権はユーザーに • 複雑性の移動 • モードレスネス 1画面に 多くの状態を持つ テキストが 省略された画面 小さく密集した操作対象 ユーザーの 要求ではない動作 確認や報告が多い 入力が多く手間どる 操作に多くの手順や 時間を要する 画面が一望できず 推定と記憶に頼る 強く関係するもの
49. 49 • シングルカラム優先 • 1画面に1トピック • 大事なものは常に上 • キーボードのみ、クリックのみ • モードレスネス 対立があるもの
50. 50 あえて正面から向き合う
51. ひとつの到達点
52. 野ッカーという新しいアイデア｜ai
53. 53 本内容は、書籍 「Webアプリケーションアクセシビリティ」 の8章から抜粋してお届けしました Amazonで販売中！ 以下QRコードもご利用ください