予測できるWeb操作とは、リンク、ボタン、入力欄などを使ったときに、何が起こるかを操作前に理解でき、操作後の結果も確認できる状態です。
リンクを選んだ直後に予想外の画面へ移動する、入力中にフォーカスが別の場所へ移る、送信できたのか分からないといった挙動は、利用者を迷わせます。
こうした戸惑いを減らす設計は、障害の有無や利用環境を問わず役立ちます。特に、画面の一部を拡大している人、キーボードで操作する人、読み上げを利用する人、複雑な変化を追いにくい人にとって、操作の一貫性と明確な通知は欠かせません。基本から確認したい場合は、Webアクセシビリティの考え方と改善の始め方も参考になります。
予測できる操作を三つの段階で考える
予測しやすさは、操作前、操作中、操作後に分けると点検しやすくなります。
| 段階 | 利用者が知りたいこと | 設計例 |
|---|---|---|
| 操作前 | このリンクやボタンは何をするのか | 「資料をダウンロード」「申し込み内容を確認」のように、結果をラベルで示す |
| 操作中 | 自分の操作が受け付けられたか | 押下状態、処理中表示、フォーカス表示を分かる形で保つ |
| 操作後 | 何が完了し、次に何をすればよいか | 完了、エラー、遷移先、次の手順を画面上と支援技術の両方に伝える |
見た目が分かりやすいだけでは、予測可能とは限りません。表示されていない場所で状態が変わる場合や、視覚以外の方法でページを利用する場合にも、同じ結果を把握できる必要があります。
WCAGの「予測可能」と関連する達成基準
WCAGは、Webコンテンツを利用しやすくするための国際的なガイドラインです。W3CのWCAG 2.2理解文書では、「理解可能」の原則にあるガイドライン3.2を「予測可能」として整理しています。
この記事の内容に直接関係する達成基準は、次の四つです。
| 達成基準 | レベル | 実務での要点 |
|---|---|---|
| 3.2.1 フォーカス時 | A | 入力欄やリンクがフォーカスを受けただけで、別画面を開くなどの状況変化を起こさない |
| 3.2.2 入力時 | A | 選択や入力によって状況が変わる場合は、自動で変えず、必要なら事前に挙動を知らせる |
| 3.2.3 一貫したナビゲーション | AA | 複数ページで繰り返すナビゲーションを、原則として同じ相対順序で示す |
| 3.2.4 一貫した識別 | AA | 同じ機能を持つ部品は、ページが変わっても一貫した名前や表現で示す |
四つの基準はレベルAとAAに分かれています。適合レベルを確認するときは、すべてを一括して「AAの基準」と扱わず、各基準のレベルを区別します。
予測しやすい画面を作る五つの実践ポイント
リンクとボタンの結果をラベルで伝える
「こちら」「詳しく見る」「クリック」のような文言だけでは、リンク先や実行される処理を判断できません。周囲の文章を読まなくても目的が分かるラベルにします。
- 内容ページへのリンク：「料金プランを確認する」
- 別画面へ進むリンク：「申し込みフォームへ進む」
- ファイルへのリンク：「製品資料をダウンロードする」
- 確定処理を行うボタン：「この内容で注文を確定する」
同じ文言でも、リンクは移動、ボタンは実行という役割があります。見た目だけでなく、HTML上の要素とラベルを実際の役割に合わせます。
フォーカスや入力だけで画面を切り替えない
フォーカスは、キーボードなどで現在操作の対象になっている位置です。入力欄がフォーカスを受けただけでヘルプ画面を開いたり、選択肢を変えただけで別ページへ移動したりすると、利用者は操作の途中で現在地を失います。
画面遷移や送信は、「適用」「次へ」「送信」などの明示的な操作で実行できるようにします。入力と同時に状況を変える必要がある場合は、何が起こるかを操作前に説明します。
ナビゲーションと機能名をそろえる
ヘッダーやメニューの項目は、ページごとに順序を入れ替えないようにします。同じ検索機能を、あるページでは「検索」、別のページでは「探す」と呼ぶような不規則な変更も避けます。
一貫性は、すべてのページを同じ見た目にすることではありません。同じ機能を見つける手掛かりを、ページが変わっても保つことです。
状態変化を見た目と支援技術の両方に伝える
処理中、完了、エラーなどの状態は、色やアニメーションだけに頼らず、短い文でも示します。画面を読み上げる仕組みは、スクリーンリーダーの仕組みと実装ポイントで詳しく解説しています。
通常の完了通知には、たとえば次のようなステータス領域をあらかじめ用意し、処理後に文言を更新します。
<p id="status-message" role="status">
登録が完了しました。確認メールを送信しました。
</p>role="status"は、現在の作業をむやみに中断しない通知に向いています。WAI-ARIA仕様で緊急性の高い通知に位置付けられるrole="alert"は、通常の完了メッセージと使い分けます。
フォームでは入力方法と修正方法を示す
入力欄には、項目名、入力形式、必須か任意かを分かる形で示します。エラーが起きたら、「どの項目で」「なぜ受け付けられず」「どう直せばよいか」を伝えます。
エラー表示のタイミングは、入力を不必要に遮らないように選びます。フォーム全体の設計は、入力支援のWebアクセシビリティ入門も参照してください。
よくある問題と改善方法
| 問題 | 利用者が迷う理由 | 改善方法 |
|---|---|---|
| リンク先が「こちら」だけで示される | リンクだけを拾い読みすると目的が分からない | リンク先の内容や実行結果をラベルに含める |
| フォーカスしただけで画面が変わる | 操作を確定していないのに現在地を失う | 状況変化は明示的な実行操作の後に起こす |
| 選択肢を変えると自動送信される | 確認や修正をする前に処理が進む | 送信ボタンを設けるか、挙動を事前に説明する |
| 送信後に反応がない | 完了、処理中、失敗のどれか判断できない | 画面上の文とステータス通知で結果を伝える |
| 同じ機能の名前がページごとに違う | 学習した操作方法を別ページで使えない | 同じ機能には一貫したラベルと代替テキストを使う |
公開前の確認項目
- リンクやボタンのラベルだけで、移動先や処理内容を判断できるか
- フォーカスを移しただけで、新しい画面や別の場所へ移動しないか
- 入力や選択だけで自動送信や予想外のページ遷移が起きないか
- 繰り返し表示するメニューの順序と、同じ機能の名前がそろっているか
- 処理中、完了、エラーの状態が、色以外の方法でも分かるか
- キーボード操作と読み上げ環境で、操作の順序と結果を確認したか
- フォームのエラーが、場所、原因、修正方法まで伝えているか
予測しやすさは、派手な機能を追加することではなく、操作と結果の対応を崩さないことから生まれます。サイト全体の基準を確認する場合は、WCAG 2.2の基礎と実務での取り組み方を確認し、設計、実装、検証で同じ判断基準を共有してください。