ユーザビリティとアクセシビリティの違い｜フォームで学ぶ設計・検証

ユーザビリティは、特定の利用者が目的を達成しやすいかを考える視点です。アクセシビリティは、障害のある人を含め、情報や機能へアクセスして利用できるようにする視点です。二つは重なりますが、一方の確認だけでもう一方を評価し終えたことにはなりません。

違いを利用者の二分法にしない

「一般の人にはユーザビリティ、障害のある人にはアクセシビリティ」と分けると、障害のある人の使いやすさを議論から外してしまいます。画面を見ずに操作する人も、目的を無理なく達成できる必要があります。利用環境や支援技術によって、同じ画面の使い勝手が異なることにも注意します。

W3C WAIの解説は、アクセシビリティとユーザビリティなどの重なりを扱っています。設計では、基準に沿った確認と、障害のある利用者も含む実際の利用場面の検証を組み合わせます。

たとえばフォームの項目が読めても、何を書けばよいか分からなければ目的を達成しにくくなります。逆に、説明文が分かりやすくても、キーボードだけでは送信できないなら利用の障壁が残ります。見た目の好みと、利用できる条件も分けて確認します。

相談フォームを同じ課題で点検する

架空の相談フォームを使い、「希望日時を入力して相談を申し込む」という課題を設定します。次の表は修正案の例であり、これを満たせば全体が適合するという判定表ではありません。

説明の意味、操作順、支援技術への伝わり方をそれぞれ確かめます。WAIのフォームラベルの解説も、入力項目に対応したラベルを扱っています。プレースホルダーの表示だけをラベルの代わりにする設計は避けます。

画像の代替テキストは役割で判断する

画像すべてに長い説明を付ければよいわけではありません。画像がその文脈で何を伝えているかを判断します。WAIの装飾画像の解説では、装飾画像に空の代替テキストを使う方法が示されています。

情報画像で、周辺の文章が十分に内容を伝えている場合もあります。同じ説明を重ねるか省くかは、利用者が情報を失わず理解できるかで決めます。空のaltは「説明を忘れた」のではなく、装飾として扱う判断の結果です。機能を担う画像を装飾扱いして、操作名を失わせないようにします。

自動検査・手動確認・利用者テストを組み合わせる

利用者テストでは、正解を誘導する説明を避け、支援した箇所も記録します。画面を見ずに操作する人や、入力に時間がかかる人など、想定する利用状況に合う参加者を検討します。困りごとを指摘してもらった後は、修正内容を再確認できる機会を設けます。

簡易チェックを適合宣言に置き換えない

WCAG 2.2には成功基準と適合の要件があります。簡単なチェック項目を通したこと、自動検査の警告がゼロだったこと、一人が操作できたことだけで、サイト全体の適合を宣言することはできません。評価する版、レベル、ページ・状態の範囲、方法を定め、必要な確認を行います。

修正記録には、対象画面、操作条件、問題、期待結果、確認日を残します。指摘件数を減らすことだけでなく、相談を完了できるか、誤入力から復帰できるかも確認してください。速度だけを重視すると、慎重に確認する利用者の行動を不当に低く評価するおそれがあります。

一つの利用課題から改善を続ける

修正の優先順位は、課題の完了を妨げる影響と、利用者が回避できるかを見て決めます。たとえば送信できない問題は、説明文の細かな調整より先に解消する候補です。対応した後も、別の操作方法で新たな障壁が生まれていないかを確かめます。

まずフォームの一連の操作を、入力前・入力中・エラー・完了まで通して確認します。改善はオンボーディングの初回価値体験にもつながります。便利さと利用者の負担を合わせて考える際は、顧客体験価値の設計を参照してください。