訪問者がボタンを押しても、何も起きていないように見える。リクエストがサーバーへ送られている途中なのかもしれません。すでに処理が終わっているのかもしれません。あるいは接続に失敗したのかもしれません。くるくる回る飾りだけでは、その不確かさは解消できません。待ち時間もインターフェースの一部です。最終結果と同じように、伝え方を丁寧に考える必要があります。
遅れていることだけでなく、何をしているかを伝える
まずは、その人が選んだ操作から考えましょう。「比較を準備しています」という表示は、回転するインジケーターだけよりも多くの情報を伝えます。待ち時間が何のために生じているのかがわかるからです。説明は、対象となるコンテンツの近くに置きましょう。小さな一部分だけを更新しているときに、ページの残りまで説明もなく真っ白にするべきではありません。
根拠のない正確さを装わないでください。パーセント表示が役立つのは、システムが意味のある進捗を測定できる場合だけです。途中でリセットされるカウントダウンや、99パーセントで止まる表示は、インターフェースに守れない約束をさせてしまいます。残り時間がわからないなら、期限を作り上げるのではなく、何が進行中なのかを伝えましょう。
受付と完了を区別する
ボタンを押すこと、リクエストが受け付けられること、依頼した処理が完了することは、同じ出来事ではありません。色やアニメーションを選ぶ前に、それぞれのメッセージが何を意味するのかを定義しましょう。たとえば、処理のためにファイルを受け付けても、そのファイルの確認が済んだことにはなりません。問い合わせを保存しても、誰かが返答したことにはなりません。
成功を示すのは、必要な確認が得られてからにしましょう。結果が不確かな場合は、安心させるための緑のチェックマークを表示するのではなく、その違いを保ってください。状態を明確にしておくと、後でサポートに問い合わせる際にも役立ちます。訪問者は推測するのではなく、ページに実際に何と表示されたかを説明できます。
視覚以外でも更新を受け取れるようにする
画面の端で起きた小さな変化は、見落とされることがあります。W3Cによるステータスメッセージの解説では、ユーザーのフォーカスを移動させずに伝える、結果、待機、進捗に関する更新を扱っています。適切なロールやプロパティを使うと、利用者を新しい文脈へ移動させることなく、支援技術がそのメッセージを提示できます。
関連する複数の更新を受け取る領域について、MDNは、変更がまだ完了していないことを示す方法としてaria-busyを説明しています。更新が完了したら、値をfalseに戻してください。この属性自体が視覚的な読み込み表示になるわけではありません。また、属性を追加しただけで、実際の読み上げや画面上のテキストを確認するテストが不要になるわけでもありません。
安全に進める次の手順を用意する
待ち時間が行き止まりになってはいけません。できる限り訪問者の入力を保持し、失敗は普段の言葉で説明し、その処理に適した次の操作を提示しましょう。「もう一度お試しください」が常に安全とは限りません。最初のリクエストが成功している可能性があれば、再送信によって重複が生まれることがあります。繰り返しを促す前に、結果を確認してください。
キャンセルが可能な場合は、その効果を明確にしましょう。画面上のアニメーションを止めることと、サーバー側の処理を取り消すことは同じではありません。ページへ戻る手段は便利ですが、利用者が費やした手間を、知らせずに無駄にしてはいけません。ここでも役に立つフォームのエラーメッセージの原則が当てはまります。状況と、役に立つ次の手順を説明しましょう。
成功した結末だけでなく、扱いにくい途中の状態もテストする
すぐに応答する場合、時間がかかる場合、失敗する場合、結果が不確かな場合を確認しましょう。メッセージが適切なタイミングで表示されるか、繰り返しのクリックを想定して処理しているか、キーボードフォーカスが適切な位置に保たれるかを見てください。動きを抑えた表示も確認しましょう。回転や脈打つような効果がなくても、意味が伝わる必要があります。
ウェブサイトの継続的な保守では、その裏で動くサービスが変わったときに、これらの状態も見直しましょう。目標は、すべての待ち時間を楽しくすることではありません。訪問者の3つの疑問に正直に答えることです。何が起きているのか。何がわかっているのか。そして、次に何ができるのか。