Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Rikiya Ihara / magi

February 15, 2024
Tweet

More Decks by Rikiya Ihara / magi

Other Decks in Design

Transcript

  1.   2 Webデザイン会社ビジネス・アーキテクツに勤務ののち、 製品を通じた多様な働き方の実現を目指し 2017年にfreeeに参加。 デザインチームのマネジメント、 およびアクセシビリティ普及啓発を行う。 ほか、外部コンサルタントとして Ubie、STUDIO、CULUMUの アクセシビリティ改善を推進。

    ウェブアクセシビリティ基盤委員会(WAIC)委員、 人間中心設計推進機構(HCD-Net) 評議委員。 著書(共著)、監訳書に 「Webアプリケーションアクセシビリティ」 「デザイニングWebアクセシビリティ」、 「コーディングWebアクセシビリティ」 「インクルーシブHTML+CSS&JavaScript」がある。 伊原 力也 Rikiya Ihara @magi1125
  2. 3 いくつかお知らせ • 今日は8章のみの話になります。7章については以下動画をご覧ください ▪ ウェブアクセシビリティ社内教育のすゝめ 〜品質か、営業か〜 ▪ 自社サービスのアクセシビリティ向上、良いパターンとアンチパターン •

    書籍がお手元にあることを前提にした解説になります • 後半はUIデザインの前提知識を要求する話になります ◦ ご不明な点があれば、お気軽に @magi1125 までDM or リプライください。 ベストエフォートで回答します
  3. 8 そもそもの「ガイドラインの限界」 • ガイドラインの前提: そのUIが存在する必要があるなら、このようにアクセシブルにせよ • ガイドラインには「UIを無くせ」や「違うUIに変更せよ」とは書けない • ガイドラインにおける「アクセスできる」ことと、 支援技術利用時に「タスクが完了できる」ことはイコールではない

    • 複雑なUIは、実装でアクセシブルにしても複雑なまま ▪ カルーセル、モーダルダイアログ、ドラッグ&ドロップ、 マウスオーバーでの追加表示、スナックバーやトースト… • 設計によってはアクセシブルにすることがそもそも不可能な場合もある
  4. 13 多様な利用状況の存在を知る • デザイナーがPCやモバイルデバイス向けのUIを設計できるのは、 自分の延長線上として利用状況のイメージを持てるから • 逆に言えば「私たちは知らないものに対してデザインすることはできない」 ◦ 視力、色覚、聴力に課題がなければ「知覚できるのか?」は想像しにくい ◦

    マウスやタッチ操作に課題がなければ「操作できるのか?」は想像しにくい ◦ 支援技術やアクセシビリティ機能を知らなければ、使い方は想像しにくい • この状態から抜け出すためには、支援技術を操作して体験し、 使い方のイメージを感覚として身に付けることが必要
  5. 14 ぜひ付録を見ながら支援技術を触って欲しい • 支援技術を日々使っている当事者に話を聞いたり、 使っている様子を見せてもらうのはもちろん大事。しかしそれには準備が必要 • いっぽう、自分の手元で支援技術を試して、想像してみるのは今すぐできる • 30分ぐらいずつでも触ってみる、支援技術を通してアプリを使ってみる •

    それだけで、何が起きるのか?何が必要なのか?の解像度は飛躍的に上がる • 「こんなにもさまざまな方法でOSやWebが使えるんだ!」という面白さもある ※実は付録も8章に入っていたが、長すぎたので分割された ※紙の本だと、付録の文字サイズが少し小さい。それでもすべて入れたかった
  6. 15 付録の構成の秘密 • 使い方をイメージしやすい→イメージしにくいの順番になっている ◦ ポインティングデバイスと支援技術: 物理補助、OS設定、マウスキー、 タッチデバイスにマウス接続、視線入力やカメラ入力、クリックの置換 ◦ キーボード操作と支援技術:

    物理補助、OS設定、スクリーンキーボード、 タッチデバイスでキーボード接続 ◦ 操作方式を変更する支援技術: 音声コントロール、スイッチコントロール ◦ 画面表示と支援技術: 文字や画面の拡大、スクリーンリーダー
  7. 28 支援技術には共通の課題がある • アクセスできるようになるかわりに、トレードオフが起きる • まとめると、この2点になる ◦ 操作に多くの手順や時間を要する ◦ 画面が一望できず推定と記憶に頼る

    • この2点を覚えておくと応用が効く ◦ 支援技術では必ずこの課題が生じるので、この2点を覚えておけば、 そこから個別のケースを思い出せる
  8. 29 操作に多くの 手順や時間を要する ※すべての支援技術で起きる 操作しにくさを時間で解決する • 物理的な補助器具を使う • OSの設定で反応を遅くする •

    時間経過による自動操作を使う • 音声で操作や認識を行う 操作精度を繰り返しでカバーする • 入力方向が限定される • 細かな操作が難しい • 滞留コントロールの操作が難しい 操作をモードに分けて対処する • アクセシビリティオプションで段階的な操作に分ける • 操作デバイスを1つに集約してモード切替を行う • 正確なポイントのために精度向上モードに入る 段階的な操作に変換する • 操作方法を事前に計画する • クリック時のアクションを先に指定する • スクロールを都度指示する • キーボードのみで全体を操作する 画面が一望できず 推定と記憶に頼る ※文字や画面の拡大(拡)、 スクリーンリーダー(SR)で起きる 部分的な拾い読みで構造を推定する • [拡]表示領域を動かし倍率を変化させる • [SR]ジャンプ機能を使って構造を推定する 情報の取捨選択に時間をかける • [拡]重要度の低い薄い文字でも注視する • [SR]重要度の判断には読み上げが必要になる 画面が変化したことの理解に時間をかける • [拡]視界外の変化に気付けない、予想外の変化に戸惑う • [SR]カーソル外の変化に気付けない 記憶に頼って利用時の文脈を維持する • [拡]記憶が薄れる前に表示範囲を動かす • [SR]音が揮発して記憶が薄れやすい 支援技術のトレードオフ一覧
  9. 31 支援技術利用時の課題を「増幅」するアンチパターン • 「操作に多くの手順や時間を要する」と 「画面が一望できず推定と記憶に頼る」を、より増幅するアンチパターンがある ◦ 1画面に多くの状態を持つ ◦ テキストが省略された画面 ◦

    小さく密集した操作対象 ◦ ユーザーの要求ではない動作 ◦ 確認や報告が多い ◦ 入力が多く手間どる • 利用をあきらめてしまったり、利用可能にするための実装が複雑化するもの
  10. 34 1画面に多くの状態を持つ • 状態: 1画面内に操作対象が散らばり、多数の状態の組み合わせが存在する • 問題: 操作対象の行き来が負担になる、拡大時やSRでは状態把握が難しくなる ◦ 切り替えウィジェットの濫用|対策:

    1画面1フォームにする ◦ 複数ペイン構成の濫用|対策: 一覧と詳細を独立させる ◦ モーダルダイアログの濫用|対策: 別の形に置き換える (インライン表示、ディスクロージャー、モード切替、詳細画面化)
  11. 38 ユーザーの要求ではない動作(1/2) • 状態: ユーザーが明示的にアクションしていないのに自動的に動作するUI • 問題: 何が起きているかわからない、想定外の状況への対処が大きな負担になる ◦ ユーザーの操作を伴わずに自動で動く|対策:

    自動で動かさない (4.7節「アニメーション」、5.3節「カルーセル」) ◦ マウスオーバーだけで要素を追加表示|対策: 追加表示しない or 気合実装 (2.2節「キーボード操作の基本」、4.8節「モバイルデバイス」、5.4節「シンプルなツールチップ」) ◦ キーボードフォーカスが自動で移動|対策: 自動で動かさない (3.4節「ユーザーが予測できる動作」) ◦ 変化した結果が画面にとどまらずに消滅|対策: 別の方法を模索する (5.2節「通知」)
  12. 39 ユーザーの要求ではない動作(2/2) ◦ スクロールスナップ|対策: 使わない ◦ 無限スクロール|対策: 読み込みボタン置く or 気合実装

    ◦ 予想外のモーダルダイアログ|対策: 本当に必要なのか?を再考 ◦ 新規タブ|対策: 不用意に使わない、ルールを定め明示する
  13. 41 確認や報告が多い • 状態: 確認・結果報告・エラーダイアログがたくさん出る • 問題: 操作対象の行き来が負担になる、拡大時やSRでは状態把握が難しくなる • 対策:

    いくつかの方法を組み合わせてダイアログを削減する ◦ 確認・結果報告:入力を即時反映し、かつ元の状態に戻せるようにする ▪ 「誤った操作」がなくなるので確認も結果報告も不要になる ◦ 確認: 別の方法で意思確認する(事前チェックボックス、2段階操作など) ◦ 結果報告: 処理によって変化が起きる画面に遷移する、インライン表示する ◦ エラー: 閉じると分からなくなるので原則使わない
  14. 43 入力が多く手間どる • 状態: 入力が多い • 問題: 支援技術利用時は入力の負担が大きく、利用をあきらめることに直結する • 対策:

    入力を減らす ◦ システム側に複雑性を移動する(外部連携、自動化、初期値設定、サジェスト等) ◦ ガッツを見せる(誤解やクレームを恐れず仕様を割り切る)
  15. 46 • シンプルなモデル • 明快な呼び名 • シングルカラム優先 • 1画面に1トピック •

    最大限のテキスト • 大事なものは常に上 • キーボードのみ、クリックのみ • 一貫性 • 主導権はユーザーに • 複雑性の移動 • モードレスネス
  16. 47 • シンプルなモデル • 明快な呼び名 • シングルカラム優先 • 1画面に1トピック •

    最大限のテキスト • 大事なものは常に上 • キーボードのみ、クリックのみ • 一貫性 • 主導権はユーザーに • 複雑性の移動 • モードレスネス • 1画面に多くの状態を持つ • テキストが省略された画面 • 小さく密集した操作対象 • ユーザーの要求ではない動作 • 確認や報告が多い • 入力が多く手間どる • 操作に多くの手順や時間を要する • 画面が一望できず推定と記憶に頼る • ポインティングデバイスと支援技術 物理補助、OS設定、マウスキー、 タッチデバイスにマウス接続、 視線入力やカメラ入力、クリックの置換 • キーボード操作と支援技術 物理補助、OS設定、スクリーンキーボード、 タッチデバイスでキーボード接続 • 操作方式を変更する支援技術 音声コントロール、スイッチコントロール • 画面表示と支援技術 文字や画面の拡大、スクリーンリーダー
  17. 48 • シンプルなモデル • 明快な呼び名 • シングルカラム優先 • 1画面に1トピック •

    最大限のテキスト • 大事なものは常に上 • キーボードのみ、クリックのみ • 一貫性 • 主導権はユーザーに • 複雑性の移動 • モードレスネス 1画面に 多くの状態を持つ テキストが 省略された画面 小さく密集した操作対象 ユーザーの 要求ではない動作 確認や報告が多い 入力が多く手間どる 操作に多くの手順や 時間を要する 画面が一望できず 推定と記憶に頼る 強く関係するもの