タブUIシステム
目的
タブUIシステムは、ユーザーが同じコンテキスト内で関連するコンテンツペインを切り替えるためのナビゲーション要素であるタブを設計・構造化するための方法論を提供します。タブは段階的な情報開示の重要なパターンであり、ページのリロードなしに情報を論理的なグループに整理することで認知負荷を軽減します。体系的なアプローチにより、タブが明確なアクティブ状態、論理的なグループ化を持ち、デバイス間で適切に適応することを保証します。
ユースケース
- プロダクト詳細ページ: 仕様、レビュー、配送詳細、FAQをスキャン可能なセクションに整理します。
- アカウント設定: ユーザープロファイル、セキュリティ、通知、請求設定をグループ化します。
- ダッシュボード: 異なるデータビュー(例:「概要」「分析」「履歴」)を切り替えます。
- 検索結果: 結果をタイプ別にフィルタリングします(例:「すべて」「画像」「動画」「ニュース」)。
- 複雑なフォーム: 大きなフォームをテーマ別のセクションに分割します(厳密な順序で完了する必要がない場合)。
使用すべきでない場合
- 順次ステップ: ユーザーが特定の順序でコンテンツを完了する必要がある場合は、代わりに
step-progress-systemを使用します。 - グローバルナビゲーション: タブはページ内のコンテンツを管理するためのものです。異なるページ間の移動には
site-navigation-systemを使用します。 - 情報の比較: ユーザーが2つのセクションのコンテンツを同時に表示する必要がある場合は、タブを使用しないでください。アコーディオンまたはサイドバイサイドレイアウトを検討してください。
- 項目が少なすぎる場合: 項目が2つだけでコンテンツが短い場合は、両方を表示するか、シンプルなトグルを使用することを検討してください。
- 項目が多すぎる場合: 6〜7個を超えるタブがあると、インターフェースがごちゃごちゃします。サイドバーナビゲーションまたはドロップダウンベースのフィルターを検討してください。
入力
- コンテンツインベントリ: ラベルとそれに対応するコンテンツパネルのリスト。
- 使用コンテキスト: タブが配置される場所(例:メインコンテンツエリア、サイドバー、モーダル内)。
- 優先度レベル: ページのプライマリフォーカスか、セカンダリの詳細か。
- 既存のシステム: 流動的スペーシング、タイポグラフィスケール、インタラクティブ状態の定義。
出力
- タブ解剖学仕様: トリガー(タブ)、タブリスト(コンテナ)、パネル(コンテンツ)の視覚的定義。
- 状態マトリクス: デフォルト、ホバー、アクティブ、フォーカス、無効状態の定義された視覚的処理。
- レスポンシブ戦略: オーバーフロー処理のルール(スクロール可能、折り返し、アコーディオン/セレクトへの折りたたみ)。
- アクセシビリティ設計書: ARIAロール、キーボードマッピング、フォーカス管理ルール。
ワークフロー
1. コンテンツの関係性を定義する
すべてのタブが同じ階層レベルにあり、同じ親エンティティに関連していることを確認します。ラベルは短く(1〜3語)、一貫した大文字小文字を使用します。
2. 視覚解剖学を確立する
visual-hierarchy-systemを適用してタブリストを定義します。
- アクティブタブ: 最も目立つようにします。色、フォントウェイト、視覚的なインジケーター(下部のボーダーや背景塗りつぶしなど)の組み合わせを使用します。
- 非アクティブタブ: インタラクティブでありながらセカンダリに見えるようにします。
- コンテンツパネル: 通常、アクティブタブと視覚的なコンテナまたは配置を共有して「接続された」感覚を生み出します。
3. インタラクションロジックを定義する
- 即時切り替え: コンテンツはインタラクション時に即座に変更される必要があります。
- ホバー vs. クリック: タブはホバーで決して切り替わってはならず、明示的なクリックまたはタップが必要です。
- デフォルト状態: ユーザーが特定の状態に戻ってくる場合を除き、通常は最初のタブがデフォルトでアクティブです。
4. スペーシングとタッチに最適化する
fluid-spacing-systemとinteractive-state-systemを適用します。
- タッチターゲット: 各タブトリガーはWCAG 2.2 SC 2.5.8(最小24x24px)を満たす必要があります。プライマリタブUIでは44x44pxを推奨します。
- 内部ギャップ: タブ間には一貫したスペーシングを使用します(通常
--space-sまたは--space-m)。 - アクティブインジケーター: 「アクティブ」ラインまたは背景がはっきり見える十分な太さであることを確認します。
5. レスポンシブ対応を計画する
タブリストが狭いビューポートをどのように処理するかを決定します。
- 水平スクロール: 最も一般的なモバイルパターンです。タブリストを水平にオーバーフローさせ、微妙なフェードまたは矢印でさらにコンテンツがあることを示します。
- アコーディオン変換: 長いコンテンツの場合、モバイルでタブをアコーディオンレイアウトに変換します。
- セレクトメニュー: ユーティリティ重視のタブの場合、モバイルでタブリストを
<select>要素に置き換えます。
決定ルール
- 「ラベル」ルール: ラベルの長さが大きく異なる場合は、左揃えのタブを使用します。ラベルが一貫して少ない場合は、中央揃えまたは両端揃えのタブを使用します。
- 水平 vs. 垂直:
- 水平: コンテンツ上部の整理に標準的です。
- 垂直: 深いリスト(設定)や、水平スペースが限られているが垂直スペースが豊富な場合に最適です。
- 「7つ」ルール: 水平タブは7項目に制限します。それ以上必要な場合は、情報アーキテクチャを再評価するか、垂直レイアウトを使用します。
- アクティブインジケーター: アクティブ状態を示すために、色だけではなく常に追加の手段(例:2px〜3pxの下線、または太字へのフォントウェイト変更)を使用します。
制約
- アクセシビリティ: ARIA APGタブパターンに従います—コンテナに
role="tablist"、各トリガーにrole="tab"とaria-selectedおよびaria-controls、各パネルにrole="tabpanel"とaria-labelledby(対応するタブを指す)を設定します。アクティブなタブのみtabindex="0"を持ち、非アクティブなタブはtabindex="-1"を使用します(ロービングtabindex)。 - アクティベーションモデル: 高速で軽量なパネルには自動アクティベーション(矢印キーでフォーカスを移動し、即座にパネルコンテンツを切り替える)を推奨します。切り替えが高コストなネットワークリクエストをトリガーする場合は、手動アクティベーション(矢印キーはフォーカスのみ移動、
Enter/Spaceで確定)を使用します。 - キーボードナビゲーション: 左右矢印キー(垂直タブの場合は上下矢印キー)でタブ間を移動、
Home/Endで最初/最後のタブにジャンプ、Tabキーでタブリストからアクティブパネルにフォーカスを移動します。 - コントラスト: アクティブ状態と非アクティブ状態はWCAG AA(テキストで4.5:1)を満たす必要があります。
- レスポンシブ性: タブがページ全体の水平スクロールを引き起こしてはなりません。タブリスト自体がオーバーフローを処理する必要があります。
よくある失敗パターン
- 隠れたアクティブ状態: 見づらい微妙な色変更を使用し、ユーザーがどのセクションを表示しているかわからなくなる。
- コンテンツのジャンプ: タブパネルの高さが大きく異なり、ユーザーがタブを切り替えるたびにフッターが上下に跳ねる。
- ナビゲーションへの誤用: タブを別のページへのリンクに使用し、即時コンテンツ切り替えに対するユーザーの期待を裏切る。
- モバイルでの切り詰め: モバイルでタブラベルを切り詰め、残りを確認する方法を提供しない。
- フォーカス状態の欠如: キーボードユーザー向けの可視フォーカスリングの設計を忘れる。
検証基準
- すべてのタブが同じコンテキストに関連している。
- アクティブ状態が視覚的に区別できる(色だけではない)。
- 各タブトリガーが少なくともWCAG 2.2の24x24pxのタッチターゲット最小値を満たしている(44x44px推奨)。
- ARIAロール(
tablist、tab、tabpanel)が正しく割り当てられ、aria-selectedとロービングtabindexが実装されている。 - ARIA APGタブパターンに従ったキーボードナビゲーション(矢印キー、Home/End)がサポートされている。
- レスポンシブ動作(スクロール、アコーディオン、セレクト)が定義されている。
- コンテンツパネルがタブと一貫した視覚的関係を維持している。