アプリをアクセシブルにするユーザープリファレンス設計

特定のユーザビリティによるアクセシビリティの欠如

おおよそ大多数のユーザーの満足度を高めるためにやっているUIデザインが、ある視点から見るとアクセシビリティに問題があるケースがある。たとえば、

• トーストUIが通知した内容が、知覚する前に消えてしまった
• 確認画面や確認ダイアログを設けなかったところ、誤って行われた操作をキャンセルできなかった

WCAGの達成基準に照らし合わせると、前者は達成基準 2.2.1 タイミング調整可能、後者は達成基準 3.3.4 エラー回避にそれぞれ関係する^[1]。

アプリを操作をしていて、優先度が低い通知であればトーストUIで事足りる場合は多いし、自動的に消えないのは逆に「消す操作」を要求されることになるので不便に思うこともあるだろう。確認ダイアログも何度も現れるのはうっとおしいし、その確認操作の数秒が積み重なることによる損失はもしかしたら小さくないかもしれない。

あるユーザーから見た良いユーザービリティがアクセシビリティを低下させてしまう場合がある。一見すると折衷案を出すのに頭を抱えてしまいそうになるが、「ユーザープリファレンスを設けることによって解決させる」という方法を提案したい。

設定を好みに変更できること

ユーザープリファレンスとはアプリにおけるユーザーが任意に変更可能な設定のことで、一般的なソフトウェアやSaaSでは「設定」や「ユーザー設定」などの名前になっている。プリファレンスという言葉を選んだ理由として、英語ではこれらの設定が「Preference」という名前になっていることが多く、Preferenceの意味には「好み」や「選択」といった意味があり、単純なSettingsではない「設定」なので、この記事ではあえてカタカナで「プリファレンス」という言葉を使うことにする。

先の問題は、プリファレンスをその名の通り「好み」に合わせて変更できればよい、というのが答えだ。トーストUIは「自動的に消える」か「操作をしないと消えない」に変更できれば解決するし、さらには自動的に消える秒数までユーザーが任意に変更できればさらに多くのユーザーの需要に応えられるだろう。確認ダイアログも、必要とする人は常に出るように設定できるとよいわけだし、普段使っているアプリで「次回からダイアログを表示しない」というチェックボックスを見たことがある人は少なくないんじゃないだろうか。アレだ。

このユーザープリファレンスは一般的なソフトウェアやOSではずっと昔からあるのもので、よくよく注目してみるとそれらが良く設計されていることがわかる。「アクセシビリティ」というカテゴライズがされていない設定でも、いろいろな事象やユーザーに配慮して設けられたものだということが伺い知れる。ウェブサイトやウェブアプリの設計をしていると、ローカルのソフトウェアやOSのデザインは別の世界と思われてしまうのかもしれないが、本当に多くのヒントが隠されているのがわかる。

プリファレンスの設計

では、プリファレンスはどうやって設計するのか？簡単に検討しないといけないことを挙げてみる。

• どこでユーザーはプリファレンスを変更するのか（画面設計）
• いつユーザーはプリファレンスを変更するのか（行動モデルの設定）
• ユーザーはプリファレンスの存在に気づけるか（ナビゲーション設計）
• プリファレンスはどこに保存されるのか（データベース設計^[2]）
• プリファレンスが変更されると、どのタイミングで反映するか（ステート管理）
• プリファレンス自体をアクセシブルにできるかどうか
• 何をプリファレンスにするのか

アプリの至るところにプリファレンスになり得る変数が潜んでいる。全体の設計を見直す必要があるかもしれない。なので、できるのであれば「一番最初に考える」と楽だ。プリファレンス用のモデルを設けて他と同様に設計スタートすれば、そこまで難しいことにはならないはずだ。もし新規サービスや既存サービスの刷新を検討しているなら、今がチャンスかもしれない。

アクセシビリティに貢献するプリファレンス

その情報に複数の迂回や代替手段で知覚できることがアクセシビリティであるとすると、複数の手段を提供できることになるプリファレンスはそもそもアクセシビリティとの親和性が非常に高い。

• 通知が自動的に消えるまでの秒数
• 通知の履歴の保存件数
• 確認ダイアログを常に表示するかどうか
• 操作確定後のキャンセルを設ける^[3]
• 画面を開いた直後に音声・映像の自動再生をするかどうか
• 画面を開いた直後に音声をミュートするかどうか
• アニメーションを少なくするかどうか
• カスタムメニュー
• コンポーネントの位置・ペインの幅
• テキストのサイズ
• カラーモード（ハイコントラストモード/色反転/ダークモードなど）
• 言語

ここで気づいた人は気づいたかもしれないが、デバイスやOSやブラウザの設定から継承できるものも多くある。「フォントサイズは相対値がよい」「アニメーションはprefers-reduced-motion^[4]で制御できるようにしよう」という方法論は、プリファレンスを自前で実装しない、アプリ自体に実装しないケースには重要で必要になってくる。基本的にプリファレンス自体を設けない文化^[5]のウェブサイト・ホームページ開発では、これを念頭においてデザインをする必要がある。

一方で、アプリにおいてOSやブラウザのプリファレンスを必ず継承しないといけないかというとそうではない。独自にフォントサイズやダークモードの設定ができるサービスも多くある。多言語対応もこのプリファレンスのひとつと言っていいだろう。デフォルト値はOSやブラウザを継承するが、あとはアプリで独立した設定ができる。ただし、ここまで細かくできているのは設計力・実装力があるからで、中途半端になるくらいならOSやブラウザから継承するほうがいいケースもある。

多様性に対応するには多様性しかない

いろんな状況に対応するには、いろんな手段を提供するしかない。設計の壁にぶつかったとき、「折衷案」なんていう中途半端なものを作らず「どちらも採用」をしたらいいのだ。コストの問題はもちろんあるが、そこを如何に解決できるかがデザイナー・エンジニアの腕の見せどころじゃないだろうか。

脚注

1. 3.3.4 エラー回避については、確認メカニズムが絶対なのではなく、取り消しや修正が可能であればこの基準は達成したとみなせる。

2. クラウドのデータベースに限らず、ローカルストレージやCookieという手段もあるだろう

3. 例: Gmailのメールの送信または送信取り消し機能

4. メディアクエリのひとつprefers-reduced-motion

5. HTMLやCSSの性質的にブラウザやOSのプリファレンスを継承する設計にそもそもなっていたわけなので、そういう文化だったのはごく自然だったと言える。ただ、フォントサイズ変更とハイコントラストモードだけはなぜか一部で流行していたり（しかも悪い実装で）、プリファレンスの継承を阻害する実装が横行（ほとんどは開発者の無知による）していたのでアクセシビリティの問題が未だに尾を引いているわけだけど…。