1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに 🌟

Fluent UI 2 の Switch は、見た目は小さなトグルですが、実務では「いつ反映される設定か」を明確に伝える重要なコンポーネントです。
特に Checkbox と混同すると、オンにした瞬間に反映されるのか保存ボタンでまとめて反映されるのかが曖昧になり、事故の原因になります。

この記事では、Fluent UI 2 の Switch を中心に、次を整理します。

  • Fluent UI 2 とは何か
  • これまでの Fluent UI 2 シリーズ記事(リポジトリ内既存分)の紹介
  • Switch と Checkbox の違い(特に即時適用と明示的送信の違い)
  • Fluent UI Blazor と Fluent UI 2(React / Web Components 文脈)における Checkbox の違い
  • Switch のガイダンス / レイアウト / アクセシビリティ / コンテンツ設計

参照した一次情報:

Fluent UI 2 とは

Fluent UI 2 は、Microsoft Fluent 2 デザインシステムに沿って UI を設計・実装するためのガイダンスとコンポーネント群です。
見た目をそろえるだけではなく、情報設計、操作の一貫性、アクセシビリティ、コンテンツ設計まで一体で扱うことを重視します。

そのため Switch も「On/Off の見た目」だけではなく、次を満たすように設計します。

  • 変更タイミング(即時適用か、後で送信か)が利用者に伝わる
  • ラベルだけで意味が通る
  • キーボードや支援技術でも状態変化を把握できる

Fluent デザインシステム全体像は、公式サイト(Fluent 2)が基点になります。
この前提を押さえたうえで、まず Switch と Checkbox の違いを確認します。

これまでの Fluent UI 2 シリーズ記事一覧 📚

※ 本記事執筆時点で、public/ 内の既存 Fluent UI 2 関連記事を調査して列挙しています。

今回のゴール ✅

  • ✅ Switch と Checkbox の設計意図を誤解なく区別できる
  • ✅ 「即時適用」と「明示的送信」の違いを説明できる
  • ✅ Fluent UI Blazor と Fluent UI 2(React / Web Components)で Checkbox の扱いの違いを説明できる
  • ✅ Switch の a11y / コンテンツ設計を実務レベルでチェックできる

Switch と Checkbox の違い(最重要)

Fluent UI 2 の文脈では、次の違いが実務上の分岐点です。

観点 Switch Checkbox
⚡ 反映タイミング 即時適用(切り替えた瞬間に状態を反映) 送信ステップ向き(Fluent UI 2 ガイドでは選択後の送信を伴う文脈が中心。単独トグル用途もあり)
🎯 主用途 機能の有効/無効、表示切り替え、ライブ設定 複数選択、同意、後でまとめて確定する選択
🧠 メンタルモデル 「今この設定を切り替える」 「候補を選んでから確定する」
🧾 画面設計 切り替え後の影響がすぐ見える配置が向く フォーム文脈・送信ボタンとの組み合わせが向く
♿ 状態伝達 On/Off の現在状態を明確に提示 checked/unchecked(必要なら mixed)を提示

「保存ボタンを押すまで反映されない設定」に Switch を使うと、利用者は即時反映だと誤解しやすくなります。
逆に「切り替えた瞬間に反映される設定」に Checkbox を使うと、反映タイミングが曖昧になります。

即時適用と明示的送信の使い分け

  • 即時適用(Switch)
    例: ダークモード、通知の有効化、サイドバー表示切り替え
  • 明示的送信(Checkbox)
    例: 一括削除対象の選択、プロフィール公開項目の選択、購読カテゴリ選択

実装レビューでは、次を必ず確認しておくと安全です。

  1. 操作直後にシステム状態が変わるなら Switch
  2. 複数項目を選んで最後に送信するなら Checkbox
  3. 切り替え失敗時の戻し方(楽観更新か、結果待ちか)を UI で説明できているか

補論: Fluent UI Blazor と Fluent UI 2(React / Web Components)での Checkbox の違い

Checkbox は同じ名前でも、設計の重心が少し違います。

観点 Fluent UI 2(React / Web Components) Fluent UI Blazor
🧭 重心 ガイドライン主導(いつ使うか・どう伝えるか) フォーム実装主導(バインド・検証・状態管理)
🧩 実装スタイル React は Checkbox を使用して構成し、Web Components は <fluent-checkbox> を直接配置 FluentCheckbox@bind-Value などを設定
🔁 状態モデル 基本は二値、文脈に応じた表現を重視 Value + CheckState / ThreeState で制御しやすい
🏷️ ラベル設計 ラベル文言・グループ説明のガイドが中心 Label / AriaLabel / Name など API 設定が中心
🧪 実務の着眼点 誤解しない操作モデルを選ぶ 入力バインドと送信フローを安全に組む

使用方法の違い(コードイメージ)

import { Checkbox } from "@fluentui/react-components";

export function Preferences() {
  return (
    <>
      <Checkbox label="メール通知を受け取る" />
      <Checkbox label="製品アップデートを受け取る" />
    </>
  );
}
<fluent-checkbox>メール通知を受け取る</fluent-checkbox>
<fluent-checkbox>製品アップデートを受け取る</fluent-checkbox>
<FluentCheckbox @bind-Value="ReceiveMail" Label="メール通知を受け取る" />
<FluentCheckbox @bind-Value="ReceiveProductNews" Label="製品アップデートを受け取る" />

@code {
    bool ReceiveMail = true;
    bool ReceiveProductNews = false;
}

Fluent UI 2 Switch のガイダンス

Switch は「状態をただ選ぶ」よりも、「設定を切り替える」文脈に向いています。
設計時は次を先に決めると迷いにくいです。

  1. 切り替えた瞬間に何が変わるか(表示、動作、通知など)
  2. 変更結果をどこで確認できるか(直下、トースト、補助テキスト)
  3. 失敗時にどう戻すか(自動で戻す / エラー表示して再試行)

Switch を使うべき場面

  • 即時に有効/無効を切り替える設定
  • 現在状態(On/Off)が利用者の目的に直結する設定
  • 反映結果をその場で把握できる設定

Switch を避けるべき場面

  • 最後にまとめて送信するフォーム項目
  • 複数候補から複数選ぶ選択
  • 変更に確認ダイアログが必須で、即時反映しない操作

レイアウト(Layout)

Switch はラベルとのセットで意味が決まるため、レイアウトは「見た目」より「意味伝達」を優先します。

  • ラベルは必ず近接させる(離して配置しない)
  • 複数の Switch を縦に並べるときは、間隔と説明文の規則を統一する
  • 設定カテゴリごとにグルーピングし、見出しで文脈を先に示す
  • 即時反映で副作用がある項目は、補助説明をすぐ下に置く
import { Switch, Field } from "@fluentui/react-components";

export const NotificationSettings = () => (
  <>
    <Field label="メール通知">
      <Switch label="障害通知をすぐ受け取る" />
    </Field>
    <Field label="表示設定">
      <Switch label="ダークモードを有効にする" />
    </Field>
  </>
);

アクセシビリティ(厚め)♿

Switch は二値コントロール(binary control)なので、支援技術に対して「何の設定が」「今どういう状態か」を正しく伝える必要があります。
実務では次をチェックリスト化すると品質が安定します。

1) role と状態属性

  • role="switch" を使う
  • 状態は aria-checked="true|false" で伝える
  • switch では mixed を使わない(必要なら Checkbox を検討)

2) ラベル関連付け

  • 視覚ラベルとプログラム上の名前を一致させる
  • aria-label のみで済ませず、可能なら視覚ラベルを表示する
  • ラベル文言だけで「オンで何が起きるか」が伝わるようにする

3) キーボード操作

  • Tab でフォーカス到達できること
  • Space で切り替えできること
  • フォーカス可視化(outline / ring)を消さないこと

4) コントラストと状態知覚

  • On/Off を色だけで区別しない(位置・テキスト・補助説明も併用)
  • フォーカス表示のコントラストを確保する
  • Disabled 状態でも「操作不可」であることが分かる視覚差を持たせる

5) 状態変化の伝達

  • 切り替え後に重要な副作用がある場合は補助メッセージで伝える
  • 非同期保存なら「保存中」「保存失敗」の状態を明示する
  • 必要に応じて aria-live 領域で結果通知する

スクリーンリーダー検証では、「フォーカス時の読み上げ(ラベル + 状態)」と「切り替え後の状態更新」が連続して確認できるかを必ず見てください。

コンテンツ設計(厚め)📝

Switch の文言は、操作の正誤を左右します。実務では次が効きます。

1) 肯定形ラベルを使う

  • 良い例: 通知を有効にする
  • 悪い例: 通知を無効にしない

否定形は、On/Off の意味を頭の中で反転する必要があり、誤操作につながります。

2) 文言だけで状態が判別できるようにする

  • ラベルを読んだだけで「On にすると何が起きるか」が分かる
  • オン/オフ のテキスト依存ではなく、機能名をラベルに含める

3) 曖昧表現を避ける

  • NG: 有効化
  • OK: メール通知を有効にする

4) 影響範囲を書く

  • 重要設定には補助文言を付ける
    例: オンにすると全プロジェクトへ即時反映されます

5) 連続配置時の文体を統一する

  • すべて「〜する」で統一する
  • 名詞止めと動詞形を混在させない
  • 同一グループ内で主語の粒度をそろえる

Switch と Checkbox を誤用しないための実務チェック

リリース前レビューで、次の 5 つを通すと事故を減らせます。

  • この項目は切り替え直後に反映されるか
  • 反映タイミングを UI 文言で説明できているか
  • 後で送信する項目を Switch にしていないか
  • ラベルを読んだだけで On/Off の意味が分かるか
  • キーボード操作と読み上げ結果が確認できているか

まとめ / おわりに

SwitchCheckbox の差は、見た目よりも反映タイミングにあります。
即時適用なら Switch、明示的送信なら Checkbox。この軸を守るだけでも、UI の誤解は大きく減らせます。

また、Fluent UI 2 ではガイドライン主導、Fluent UI Blazor では API 主導で実装する場面が多いため、同じ「Checkbox」でも設計の着眼点が変わります。
最後は必ず、a11y(role/状態/ラベル/キーボード)とコンテンツ(肯定形・曖昧回避・影響範囲明示)まで含めて確認してみてください。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?