利用者がサービス名を入力して「検索」を押すと、空の画面が表示される。処理上は検索が終わっています。しかし実際には、訪問者が自分の関心を最も明確に示したその瞬間に、サイトとの対話が途切れてしまったのです。私たちはこの場面を利用者の間違いとしてではなく、一つの独立した利用シナリオとして設計することを提案します。利用者は何を理解し、次に何ができるでしょうか。
まず、サイトのどこを検索するのかを決める
虫眼鏡の付いた入力欄は、実際にできること以上の期待を抱かせがちです。検索対象が記事のタイトルだけで、サービスや文書、ページ本文のすべてではないなら、そのことを入力欄の近くで明示する必要があります。ほかのコンテンツが検索対象に入らないのであれば、単に「検索」とするより「ジャーナル内を検索」のほうが正確です。小規模なサイトでは、制約の見えない複雑な検索フォームより、きちんと整理された記事アーカイブのほうが役立つこともあります。
開発に入る前に、よくありそうな検索語をいくつか用意しましょう。正確な名称、大まかなテーマ、別の表記、サイト内に存在しない語などです。それぞれの場合にどのコンテンツを表示すべきかを決めておきます。これは編集方針としての合意であって、アルゴリズムがあらゆる意図を推測できるという約束ではありません。
検索語を保持し、状態の違いを区別する
検索後も、入力したテキストは欄内に残しておきましょう。利用者は最初から入力し直す代わりに、一語だけ修正できます。検索語が未入力の状態、読み込み中、一致する結果がない状態、技術的なエラーには、それぞれ異なるメッセージが必要です。サーバーに接続できない状態を「見つかりませんでした」で隠してはいけません。その場合、結果が存在するかどうかはまだ分からないからです。
絞り込み機能のある検索では、現在適用されている条件を表示します。選択したカテゴリに該当するコンテンツがゼロでも、サイト全体に存在しないとは限りません。入力済みのテキストを消さずに使える「絞り込みを解除」という独立した操作を用意しましょう。そうすれば、訪問者は押した後に何が変わるのかを理解できます。
大量の助言ではなく、誤解を招かない選択肢をいくつか示す
結果がない場合の簡潔な表示には、検索語そのもの、検索範囲の説明、そして二つの次の行動を含められます。表現を変えるか、関連するテーマのセクションを開くかです。無関係なカードを何十枚もいきなり並べる必要はありません。近いテーマを提示するなら、完全に一致する検索結果ではなく、おすすめとして示しましょう。
制作スタジオのサイトを仮の例に考えてみます。「再始動」という語では何も見つからなくても、サイトの保守や更新に関するセクションは存在するかもしれません。それらを別の進み方として提案することはできます。ただし、検索への回答をすり替えたり、検索語に合わないものを見つかった結果として扱ったりしてはいけません。リンクのラベルは、リンク先の内容が分かるものにする必要があります。私たちの分かりやすいリンクについての記事でも、この点を扱っています。
入力欄だけでは検索機能は完成しない
MDNでは、input type="search"を検索語の入力欄として説明しています。この入力欄の種類を指定しただけでは、インデックスは作成されず、語句とコンテンツをどのように照合するかも決まりません。そのロジックは別途実装する必要があります。また、入力欄には分かりやすいラベルも必要です。空の入力欄の中に表示する例だけを、その目的を説明する唯一の手段にするべきではありません。
ページを再読み込みせずに結果が更新される場合、件数や結果がないことを伝える短いメッセージは、フォーカスを強制的に移動させずに支援技術で認識できるようにする必要があります。W3Cが達成基準4.1.3の解説で扱っているのは、まさにこうしたメッセージです。ただし、結果一覧の全体を一つのメッセージとして読み上げるべきだという意味ではありません。
虫眼鏡の有無ではなく、一連の操作を確かめる
幅の狭い画面とキーボード操作で、利用の流れを一通り試しましょう。検索語を入力し、検索を実行し、語句を修正し、絞り込みを解除し、結果を開いてから戻ります。ボタンが画面上のキーボードに隠れないか、長いタイトルが隣の要素に重ならないか、文字を一つ入力するたびにメッセージが目の前で動いたりしないかを確認します。
サイトで使用している各言語の検索語も個別に試し、言語別セクション間の検索範囲の境界を曖昧にしないようにしましょう。優れた検索が、すべてを推測できる必要はありません。その実用的な価値は、結果がゼロでも、利用者が回答の範囲を把握し、それまでの入力や操作を失わず、次に何をすればよいか分かることにあります。