まずタスクと小さな情報設計から始める
情報設計とは、コンテンツと機能をどのようにグループ化し、命名し、接続するかを指す。訪問者のタスクをリスト化し、各タスクの開始ページ、次のページ、成功の終了状態をマップする。これにより、メニュー項目が本当に役立つか、訪問者が解読しなければならない社内用語かが分かる。主要なナビゲーションはそれらのタスクを開始するセクションに絞る。
ナビゲーションはサイトマップではない。GOV.UKはサービスのあらゆる部分ではなく、役立つトップレベルのセクションを列挙することを推奨している。順序が必須の旅程がある場合、グローバルメニューから推測させるのではなく、コンテンツやタスクリストで示すべきだ。
訪問者が同じ回答やタスクを期待するときにページをまとめ、単に担当チームの所有だからといってまとめない。
濃密なヘッダーにする代わりに、ランディングページと文脈リンクで詳細を提供する。
到達先を予測させるラベルを使う
ラベルはその先に続く内容への約束である。“Pricing”、“Documentation”、“Get support”、“Manage account” のように目的地に合致する馴染みのある名称を優先する。訪問者が内容を予測できない限り “Resources” や “Explore” のようなあいまいなラベルは避ける。文言と順序は一貫させる。
Googleは文脈外でも理解できる簡潔で関連するリンクテキストを勧めている。一般的な “click here” やキーワードを詰め込んだリンクはどちらも良くない。アイコンのみのコントロールには、その動作を説明するアクセシブルな名前を付ける。
遷移先がプラン表示なら “View plans” ではなく “Learn more” を使うのは避け、結果を名前にする。
表示中のページは視覚的かつプログラム的にマークする；W3Cは表示ページに対して aria-current=page を説明している。
到達先はクロール可能で構造を明確にする
ナビゲーションの到達先は通常、実際の Web アドレスに解決する href を持つ HTML のアンカーであるべきだ。Google は、レンダリングされたマークアップがその構造を保持する場合、動的に挿入されたアンカーも概ねクロールできると述べている。クリックハンドラやカスタム属性だけでは信頼できる代替にならない。フレームワークのソースだけでなく、レンダリング後の出力を検査すること。
主要ナビゲーションの周りには意味的な構造を使う。W3C は nav 要素と、通常のサイトナビゲーションにはリストを推奨している。ページに複数のナビゲーション領域がある場合は、スクリーンリーダー利用者がプライマリナビゲーションとフッターやローカルナビゲーションを区別できるようにそれぞれにラベルを付けること。
重要なデスクトップとモバイルの到達先がクライアントサイドのレンダリング後にアンカーと href を持っていることを確認する。
URL 検査は Google のクロール、インデックス、配信情報を提供するが、訪問者がページを見つけられることを証明するものではない。
モバイルメニューを完結したインタラクションとして設計する
レスポンシブナビゲーションは折りたたまれることがあるが、残る到達先は画面サイズを超えて同じ文言、順序、ターゲットを保つべきだ。W3C はサブナビゲーションの項目を折りたたむことを許容しつつ、一貫性を求めている。ヘッダーが混雑しているからといって重要な経路をデスクトップ限定にしてはならない；優先度の低い素材を移動するか階層を再考する。
表示・非表示のメニューには、そのリンク群を制御するボタンを使い、開いているかどうかを伝えること。W3C の disclosure-navigation の例は aria-expanded と aria-controls を使用し、Tab、Shift+Tab、Escape を文書化している。これは指導的な例なので、あなたのユーザーが使う組み合わせでコンポーネントをテストすること。
親ページとその子リンクの両方が必要な場合、ページへのリンクとそれを展開するコントロールを区別する。
ポインタのホバーで表示されるものはキーボードフォーカスとタッチでも発見可能でなければならない。
方向付けとキーボード移動をサポートする
キーボードアクセスは仕上げのためのオプションではない。WCAG 2.1 Success Criterion 2.1.1 は、パス依存の入力を除き、キーボードインターフェースで操作できることを要求している。ヘッダーでは、訪問者が Tab でコントロールを移動し、フォーカスを確認し、リンクやボタンを起動し、トラップされずに離れられるべきだ。
繰り返し現れるヘッダーリンクはページの横断を遅くすることがある。キーボードユーザーにとって main コンテンツまでのルートを与える skip link（バイパスリンク）が有効だ。GOV.UK はそれがキーボード使用時まで視覚的に隠しておく方法を説明している。リンクが有意義なターゲットに着地することをテストする。
ブラウザのフォーカス指標を明確な代替なしに削除しない。拡大時にも視認可能な代替が必要だ。
ヘッダーから遷移先ページへ Tab、Shift+Tab、Enter、Space、Escape を使って移動してみる。
リリース前後に見つけやすさをテストする
代表的な人に、解約手順やプラン比較など現実的なタスクを完了してもらう。彼らがどこに行こうと期待するか、どのラベルを誤読するか、ナビゲーションが失敗したために検索に頼るかを観察する。意図したラベルに誘導しないようにし、各障害とそれを取り除くための最小変更を記録する。
タスクテストと技術的チェックを組み合わせる。W3C の Easy Checks はマウスなしでのテスト、フォーカス可視性、タブ順、キーボードトラップ、ドロップダウンの検査を推奨している。狭い幅や大きな文字サイズでもコアタスクを繰り返す。自動チェックはマークアップの問題を検出できるが、ラベルが意味を持つかどうかは判断できない。
テスト前に意図する到達点と対応デバイス・入力方法を記録する。
関係者の好みに頼るのではなく、同じタスクで旧ルートと新ルートをテストする。
ナビゲーションの変更を可用性に敏感なリリースとして扱う
ヘッダーはロードされても重要な経路が事実上利用不可のままになり得る：チェックアウト、ログイン、サポートルート、ドキュメントページが壊れた状態、古いリンク、誤ったリダイレクトの背後にあることがある。リリース前に重要な到達先を棚卸し、デスクトップとモバイルの経路をテストし、レンダリングされたリンクが意図したページに到達することを確認する。認証や地域依存のパスには認可済み環境を使う。
SIU の役割は事前的な修復：プレフライトを実行し、デプロイ後に重要経路を検証し、修正を元に戻せるようにしておくこと。メニュー構成のバージョン管理を行い、復旧できる担当者を明記し、復旧したパスを検証する。これによりリリースの影響を制限できるが、ユーザビリティ調査やライブステータス監視に代わるものではない。
重要な到達先が欠けている、誤っている、またはキーボードとタッチで到達できない場合は公開をブロックする。
再構築前に前の構成、担当者、トリガー、検証手順を文書化しておく。