サイトアイコン IT & ライフハックブログ|学びと実践のためのアイデア集

検索・絞り込み・並び替えのアクセシビリティ完全ガイド:サイト内検索・フィルターUI・オートコンプリート・結果件数の伝え方まで(WCAG 2.1 AA)

magnifying glass and wind rose on maps

Photo by Monstera Production on Pexels.com

検索・絞り込み・並び替えのアクセシビリティ完全ガイド:サイト内検索・フィルターUI・オートコンプリート・結果件数の伝え方まで(WCAG 2.1 AA)

概要サマリー(先に要点)

  • 検索UIは「見つからない」を減らす最後の導線ですの。アクセシビリティでは、入力しやすさ・結果の分かりやすさ・絞り込み後の状態変化の伝わり方が重要になります。
  • 基本は ①検索欄に可視ラベル ②検索結果件数をテキストで提示 ③フィルターはキーボードで完結 ④並び替えや絞り込みの状態を明示 ⑤0件時の代替導線を用意 の5点です。
  • オートコンプリートや候補表示は便利ですが、実装を誤ると 読み上げで候補が分からない/矢印キーで移動できない/候補が勝手に確定する といった事故が起こりやすいですの。
  • 本記事では、検索フォーム、検索結果一覧、絞り込みパネル、ソートUI、候補サジェスト、モバイルでのフィルター表示まで、実務にそのまま使える形で整理します。

対象読者(具体):ECサイト運用者、自治体/公共サイト担当、SaaS/業務システム開発者、UI/UXデザイナー、フロントエンドエンジニア、QA/テスター、コンテンツ運用担当
アクセシビリティレベルWCAG 2.1 AA 準拠を目標(関連:1.3.1、2.1.1、2.4.3、2.4.6、3.2.2、3.3.x、4.1.2 ほか)


1. はじめに:検索は“迷った人の最後の味方”です

ナビゲーションや目次が整っていても、利用者がいつも設計者の想定どおりに探してくれるとは限りません。商品名が分からない、制度名を知らない、記事がどこにあるか想像できない、ということは日常的に起こりますわ。
そんなとき、検索は「このサイトは使える」と感じてもらえる最後の味方になります。けれど、その検索UIが

  • ラベルがなくて何を入れる場所か分からない
  • 候補が勝手に出て消えてしまう
  • 絞り込み後に何が変わったか分からない
  • 0件のときに行き止まりになる
    という状態だと、せっかくの導線が障壁になります。
    アクセシビリティの観点では、検索は“見つける機能”であると同時に、理解と回復を支える機能でもありますの。この記事では、誰でも探しやすく、迷っても戻れる検索体験を作るための考え方を丁寧にまとめていきますね。

2. 検索フォームの基本:入力しやすく、意味が分かる入口を作る

検索UIの第一歩は、何よりも「ここが検索欄だ」と伝わることですわ。虫眼鏡アイコンだけでは不十分で、可視ラベルを持った検索フォームが基本です。

2.1 推奨する最小構造

<form role="search" aria-label="サイト内検索" action="/search">
  <label for="q">サイト内検索</label>
  <input id="q" name="q" type="search" aria-describedby="q-hint">
  <p id="q-hint">例:返品、送料、請求書、アクセシビリティ</p>
  <button type="submit">検索</button>
</form>

2.2 なぜこれが大切なの?

  • role="search" により、支援技術で「検索領域」だと分かります。
  • <label> があることで、スクリーンリーダーも音声入力も安定します。
  • type="search" は入力体験を少し助けますが、ラベルの代わりにはなりません
  • ヒント文を aria-describedby で紐づけると、検索語の例が自然に伝わりますの。

2.3 プレースホルダーだけに頼らない

「キーワードを入力」とだけ薄く入っている検索欄は、入力した瞬間にヒントが消えます。検索語を知らない人ほど困るので、例示はラベルの近くか補助文で残してあげるのが親切ですわ。


3. 検索結果ページ:件数・条件・並び順を“テキストで”見えるようにする

検索結果が表示されたら、利用者が最初に知りたいのは「何件見つかったか」「いまどんな条件で表示されているか」です。ここが視覚だけに依存していると、スクリーンリーダーや認知特性のある方にとって非常に分かりづらくなりますの。

3.1 結果件数は見出しの近くに置く

<h1>検索結果</h1>
<p id="search-summary">「アクセシビリティ」の検索結果:25件</p>

3.2 条件変更後の状態もテキストで伝える

  • 「カテゴリ:記事」
  • 「公開日:1年以内」
  • 「並び順:新しい順」

この情報が視覚的なチップだけで示されていると、読み上げでは伝わりにくいです。テキストとして列挙し、必要なら role="status" で変更を伝えると安定します。

<div id="result-status" role="status" aria-atomic="true" class="sr-only"></div>
<script>
function announceResult(count){
  document.getElementById('result-status').textContent =
    `検索結果が更新されました。${count}件です。`;
}
</script>

3.3 検索語を含めて説明する

「25件見つかりました」だけではなく、

「『アクセシビリティ』の検索結果:25件」
のように、検索語まで含めると、複数タブや履歴の中でも意味がぶれにくくなりますわ。


4. 絞り込み(フィルター)のアクセシビリティ:狭める操作ほど丁寧に

絞り込みは便利ですが、操作が増えるぶん複雑になりがちです。価格帯、カテゴリ、日付、タグ、在庫、エリアなど、条件が増えるほど「今どんな状態か」が見えなくなりますの。そこで大切なのは、条件の構造を分かりやすく分けることです。

4.1 フィルターグループは fieldsetlegend でまとめる

<fieldset>
  <legend>カテゴリで絞り込む</legend>
  <label><input type="checkbox" name="category" value="article"> 記事</label>
  <label><input type="checkbox" name="category" value="news"> お知らせ</label>
  <label><input type="checkbox" name="category" value="guide"> ガイド</label>
</fieldset>

4.2 なぜ fieldset が効くの?

スクリーンリーダーでは、個々のチェックボックスだけでなく「何のグループか」が分かることが重要です。legend があると、「カテゴリで絞り込む」という文脈が維持されますの。

4.3 適用方法は“即時反映”か“適用ボタン”かを明確に

  • チェックした瞬間に即時反映
  • 複数選択後に「絞り込む」ボタンで適用
    どちらでも構いませんが、混在させると混乱します。
    即時反映なら、結果件数の更新を status で伝える。
    適用ボタン方式なら、ボタンラベルを明確にして、押した後に結果へ誘導する。
    この一貫性が大切ですわ。

5. 並び替え(ソート):いまの順番が何かを常に分かるようにする

並び替えは「どの順で見せるか」を変えるだけですが、検索結果の意味が大きく変わります。だからこそ、現在の並び順は明示的に伝える必要がありますの。

5.1 セレクトボックスが最も安全

<label for="sort">並び替え</label>
<select id="sort" name="sort">
  <option value="relevance">おすすめ順</option>
  <option value="newest">新しい順</option>
  <option value="oldest">古い順</option>
  <option value="price-low">価格の低い順</option>
  <option value="price-high">価格の高い順</option>
</select>

5.2 ボタン群にする場合の注意

タブのような見た目のソートUIもありますが、選択状態が明確でないと、視覚でも読み上げでも分かりにくいです。ボタン群にするなら、

  • 現在値をテキストでも明示
  • aria-pressedaria-current の適用を慎重に
  • 同じ並び順が複数箇所に出ないように
    が必要になります。基本はセレクトの方が堅牢ですわ。

6. オートコンプリートと候補表示:便利だけれど最も壊れやすいUI

検索窓に文字を入れると候補が出るUIは、とても便利です。でもアクセシビリティの観点では、ここが一番事故を起こしやすい領域でもありますの。

6.1 よくある問題

  • 入力中に候補が急に増えて驚く
  • 矢印キーで選べない
  • Enterを押すと、検索ではなく勝手に候補が確定する
  • スクリーンリーダーで、候補がいくつあるか分からない
  • 候補をクリックできても、キーボードで到達できない

6.2 実務での安全策

候補表示を自作するのはかなり難しいので、成熟したライブラリかネイティブに近い実装を採るのが安全ですわ。どうしても自作する場合は、次を守ります。

  • 入力欄と候補リストの関係を明示
  • 候補数の変化を status で伝える
  • 矢印キーで候補移動、Enterで確定、Escで閉じる
  • 候補がなくても検索自体は継続できる
  • 候補に依存しない(候補を選ばなくても送信可能)

6.3 候補を“補助”にとどめる

オートコンプリートは便利ですが、検索の本体ではありません。候補を選ばなければ進めない設計は避けたいですわ。


7. 0件のアクセシビリティ:行き止まりを作らないことが大切です

検索結果が0件だったとき、何も出さないのは最もつらい体験です。アクセシビリティでは、0件のときこそ次の一歩を用意する必要があります。

7.1 良い0件メッセージの型

  • 何が起きたか
  • どう試せばいいか
  • 別ルートは何か

例:

「『アクセシビリティチェックツール無料』に一致する結果はありませんでした。別の言葉で検索するか、『アクセシビリティ』カテゴリから探してください。」

7.2 よく効く代替導線

  • 言い換え候補
  • 人気キーワード
  • カテゴリ一覧
  • お問い合わせリンク
  • よく見られているページ

0件は失敗ではなく、案内不足を補う場面だと考えると設計しやすいですわ。


8. モバイルでの絞り込みUI:シートやモーダルにするときの注意

スマホでは、フィルターを画面外のパネルや下から出るシートに入れることが多いです。ここでありがちな事故は、モーダルとして開いたのに

  • フォーカスが中に入らない
  • 背景にTabが逃げる
  • 閉じたら元に戻れない
  • 適用後に結果がどこへ行ったか分からない
    というものです。

8.1 フィルターシートの基本

  • 開いたら最初の操作要素へフォーカス
  • Escまたは「閉じる」で閉じられる
  • 閉じたらトリガへ戻る
  • 適用後は結果一覧の見出しにフォーカス、または件数を status で通知

8.2 “絞り込み中”が分かる表示

モバイルでは、画面を閉じたあと条件が見えなくなりがちです。

  • 「絞り込み中:カテゴリ2件、価格1件」
    のようなサマリーを、一覧の上部にテキストで出すと親切ですわ。

9. よくある落とし穴と修正策

落とし穴 何が起きる? 修正策
検索欄が虫眼鏡だけ 何の入力欄か分からない 可視ラベルを付ける
結果件数が画像や色だけ 状態が分からない テキストで件数を表示
絞り込みの見出しがない 何の条件か分からない fieldsetlegend
並び替えがアイコンだけ 現在値が不明 セレクト+ラベル
候補が勝手に確定 誤操作 Enterの意味を明確に分ける
0件で何も案内しない 行き止まり 言い換え・カテゴリ・人気導線を出す
モバイルフィルターが閉じられない 操作不能 閉じる・Esc・フォーカス復帰

10. 5分スモークテスト:検索UIの最小確認

  1. 検索フォームに可視ラベルがある
  2. キーボードだけで検索→結果確認→絞り込み→並び替えが完了できる
  3. 結果件数がテキストで表示される
  4. 条件変更後に何が変わったか分かる(件数/条件表示/通知)
  5. フィルターグループに見出しがある(fieldset/legend
  6. 並び替えの現在値が分かる
  7. 0件時に代替導線がある
  8. モバイルのフィルターシートでフォーカスが迷子にならない
  9. オートコンプリートがなくても検索できる

11. 対象読者にとっての価値(具体)

  • スクリーンリーダー利用者:検索欄・結果件数・絞り込み状態が明確になり、探索が格段にしやすくなります。
  • キーボード利用者:絞り込みや並び替えがTabだけで完了し、迷いが減ります。
  • 認知特性のある方:条件の現在地や0件時の代替導線があると、行き止まり感が減って安心です。
  • 高齢者・モバイル利用者:大きな操作要素、分かりやすい文言、状態の明示で誤操作が減ります。
  • 運用チーム:検索導線が整うと、問い合わせや離脱が減り、コンテンツ資産が活かされやすくなりますの。

12. アクセシビリティレベルの評価(本記事の到達点)

  • WCAG 2.1 AA の主要関連項目
    • 1.3.1 情報及び関係性:検索フォーム、フィルターグループ、結果構造
    • 2.1.1 キーボード:検索・絞り込み・候補移動・適用の完結
    • 2.4.3 フォーカス順序 / 2.4.6 見出し及びラベル:現在地とラベルの明確化
    • 3.2.2 入力時:選択時に予期しない変更を起こさない
    • 3.3.2 ラベルまたは説明:検索ヒント、フィルター説明
    • 4.1.2 名前・役割・値:候補リスト、状態通知、選択の露出
  • 検索UIを整えることは、AA準拠だけでなく、情報到達率と完了率を大きく改善する実務施策です。

13. まとめ:検索は“見つける自由”を支えるアクセシビリティです

  1. 検索欄は可視ラベル付きで、誰でも意味が分かる入口にする。
  2. 結果件数・条件・並び順をテキストで明示し、状態変化を取りこぼさない。
  3. フィルターは fieldsetlegend で整理し、キーボードで完結できるようにする。
  4. オートコンプリートは補助にとどめ、候補に依存しない。
  5. 0件時こそ、言い換え・カテゴリ・人気導線で回復を助ける。
  6. モバイルのフィルターUIは、フォーカス管理と結果への復帰まで設計する。

検索は、迷った人のための道具です。
だからこそ、その道具が誰にとっても扱いやすいことは、とても大切ですわ。あなたのサイトやサービスが、“探せば見つかる”安心を届けられる場所になりますように。心を込めて応援していますね。


モバイルバージョンを終了