アクセシビリティにわか、頑張ってみた
どうも！エン・ジャパンのデザイナー、Oh！平泉です！
現代社会でのデザインにおいて避けては通れない、アクセシビリティ道…。
アクセシビリティとは製品やサービス、情報などを利用できる人や状況の幅の広さを指します。
アクセシビリティを向上させると、製品やサービスにアクセスできる人を増やせるだけでなく、元々使えていた方にも更にやさしいプロダクトにすることができます。
エンゲージ/engageを、もっとやさしいプロダクトにしていきたい！
ということで、アクセシビリティの聖書「Webアプリケーションアクセシビリティ」を片手に、エンゲージの企業用プロダクト「engage」の各種設定画面のリニューアル、やってみました！
読み上げ設定に対してデザイナーも責任を持つ
世の中には、読み上げ機能を使って耳で内容を把握している方がいます。
デザイナーのみなさま、読み上げ内容を自分で考えたこと、ありますか？
もちろん！私は聖書を読むまでありませんでした！
これまではエンジニアの皆様が、良きように設定してくださっていたそうですが、読み上げを聞く体験もUIの一環と考え、デザイナーの私も一丁前に口を出すことにしました。
読み上げ文言をfigmaで管理
聖書によると、アイコンとセットのテキストの読み上げでは、アイコンも読み上げられてしまい理解を阻害することがあるそうです。
「イメージ、設定、ボタン」や「はぐるま、設定、ボタン」と読み上げられてしまうこともあるのだとか。
「なんのこっちゃ」という感じですね。
そんな認識違いを埋めるべく、Figmaで読み上げ文言を定義しました。
Figmaで読み上げ文言を定義してみて分かったことは下記の2点。
読み上げ文言はデザイナーとエンジニア、双方が編集できる環境で定義した方が良いということ
見たままを入れるだけなので冗長なのでは？とも思えるが、あえて明文化することで認識のズレを再認識できるということ
次回はFigmaではなくConfluenceで仕様を管理してみようと思います。
見えているUIと読み上げの差異
まずは画像アップロードの話から。
読み上げ機能を使っている人が使わない、ドラッグ＆ドロップ機能。読み上げ内容からドラッグ＆ドロップ機能に関する説明を外しました。
使わない機能の読み上げを外すことで、読み上げ時間が短くなり、より操作しやすくなったと言えます。
お次は、”2行以上は「…」で省略“といった、UI界ではあるあるの仕様。
画面幅によって表示される文字数が異なる場合、読み上げが極端に短くなると困ってしまうため、一定の読み上げ量を担保しなければなりません。
そのため、表示は2行で文字数可変、読み上げは100文字、といった固定の仕様にしました。
UI上でどんな役割を果たしているかを読み上げたほうが親切
見出しでネタバレしてますが、ここでクイズです。
Q.engageではアップロードした画像をどのように読み上げるのが適切と判断したでしょうか？
❶abcdefg.jpg（アップロードした画像のファイル名）
❷登録済みの会社のロゴ画像
私は❶が良いのではないかと提案しました。アップロードする時の画像選択時にファイル名を確認してるんだから❶やろ！なんて親切なプロダクトなんだ！
A.正解は❷です！
engageでは下記のエンジニアさんの意見を元に、アップロードした画像は「登録済みの会社のロゴ画像」と読み上げることにしました。
まず前提として、「UI上でどんな役割を果たしているかを読み上げたほうが親切である」があります。
その上で、❶の読み上げがファイル名の場合は↓のように理解に2ステップかかってしまいます。
ステップ1、「test.jpg」→このファイル何だっけ
ステップ2、ああ、前にアップロードした会社の画像が表示されているのか
理解完了
また、ファイル名が適当だった場合にわかりにくかったり、長いファイル名だった場合に冗長になってしまうという側面もあります。
その一方、❷の読み上げがUI上の役割の場合、理解にかかる工数は下記の通り1ステップであると言えます。
ステップ1、「登録済みの会社のロゴ画像」→ああ、読み上げどおり登録済みの会社のロゴ画像が表示されているのか
理解完了
足並みを揃える大切さ
世の中にはアクセシビリティ対応がなされていないプロダクトがまだまだ多いです。
読み上げ機能を使っている猛者達は、その逆境の中で逞しく生き抜いているので、張り切って親切にしすぎると他のプロダクトとの違いに困惑してしまうそう。大方のパターンが世の中にはあるので、それを阻害しないことが大事なのだとか。
「アクセシビリティめっちゃやってるぜ〜！」と先進してイキりたい所ですが、周りと足並みを揃えないといけないもどかしさがありますね。
同様の理由で棄却された、その他イキりアイディアをここにてお焚き上げ
テキストフィールドにフォーカスが当たっている時、「現在、テキストフィールド上にいます。テキストをこのフィールドに入力してください。」と読み上げる。（現状、多くのプロダクトが、空のテキストフィールドを選択しているときに、テキストフィールドにフォーカスが当たっていることを読み上げないことに気づいたため）
「会社名/店舗名」の読み上げ文言設定において、「/（スラッシュ）」を「、」に差し替える。
プレースホルダーに表示する氏名の記入例を、名前だと認識しやすく
エン・ジャパンのプロダクトは、「エン 太郎」で記入例が統一されています。しかし、「エン」は姓として連想しづらいため、「姓、例、エン、名、例、太郎」と読み上げられた際に、「『せい れい えん めい』って何だろう？」と混乱してしまうことが予想されます。その点を考慮し、engageは「山田 エン太郎」にしました。
おまけ
余談ですが、エンジニアさんがiPhoneの日付表記の読み上げについて自由研究してくださったので共有します。
「/」で区切る（例：2024/12/24）
読み上げ：にせんにじゅうよん スラッシュ じゅうに スラッシュ にじゅうよん
「-」または「.」で区切る（例：2024-12-24、2024.12.24）
読み上げ：にせんにじゅうよねん じゅうにがつ にじゅうよっか
日付表記ってスラッシュを使いがちですが、「-」か「.」で区切るのが良さそうですね。世紀の大発見です。
アイコンのみで配置しない
通信速度制限などによりアイコンが読み込めなくなる可能性があるので、アイコンのみでの使用は避けた方が良いそうです。（by聖書）
見慣れたUIにも疑問を持つ
アクションを行う場所に工夫を凝らす
フィードバックはアクションを行う場所の近くに配置する
テキストエリアやトグルボタンなど、何かを入力した際のエラーなどのフィードバックは、それぞれの要素の付近に表示すべきだそうです。（by聖書）
プレースホルダーの中に重要な情報を入れない
世の中には、短期記憶が難しい方もいます。プレースホルダーの中にテキストエリアのタイトルやヒントを表示しているUIをよく見かけますが、プレースホルダーだと入力した際に見えなくなってしまうので、避けるべきとのことでした。（by聖書）
プレースホルダーには、非表示になっても困らない内容として、記入例を表示することにしました。
エラーを起こさない
どんと来い、超常現象
「全角で入力してください」
こんなエラーが返ってきてイライラしたこと、ありませんか？私は100億回ほどあります。
世の中には、体が不自由なことにより、キーボードを打つのが大変なので、コピペで入力する人もいます。（by 略）
engageでは、コピペした情報でエラーを起こさないよう工夫をしました。
はい、それがこちらになります。電話番号の入力欄。
全角、半角、ハイフンの有無のブレに対応できるようにしました。
最初からエラー条件を出しておく
エラー条件はなるべく減らしたいものですが、システムの都合上、どうしても発生していまいますよね。
入力した後、後出しジャンケンのような「聞いてないよ」のエラーが出るのは避けたいところ。
engageでは「聞いてないよ」を避けるべく、最初から情報を提示するよう心がけました。
色、サイズの工夫
爆誕！Essence！
今回紹介した各種設定画面を含め、今後のengageは、色のコントラストやフォントサイズ、ボタンのサイズなど、アクセシビリティの基準をクリアしたEssenceという名のデザインシステムを適用します。
デザインチームの創造神、homma氏によるEssence爆誕秘話は別のnote記事にて紹介予定ですのでぜひチェックをお願いいします！
最後に
最高の仲間！仲間に感謝👊👊👊
ここまで読んでくださった方はお分かりかと思いますが、エン・ジャパンではスクラムやチームで殴り合い真剣バトルしてより良いプロダクトを生み出すべく切磋琢磨しております。
今回参考にした聖書も、チームの勉強会で読みました。難しい本はみんなで強制的に読むに限りますね！
デザイナー募集中
もし興味を持ってくださりましたら、ぜひご応募いただけたらと思います！
