はじめに 🌟
Fluent UI 2 の Accordion は、関連する情報をひとかたまりにしつつ、必要なときだけ開いて読めるようにするコンポーネントです。情報量が多い画面でも、利用者が見る範囲を自分で選べるため、認知負荷を下げやすいのが大きな利点です。
一方で、使いどころを誤ると「大事な情報が隠れてしまう」「複数の項目を行き来しないと理解できない」といった問題も起きます。特に業務 UI や設定画面では、見た目の整理と情報設計を分けて考えることが大切です。
本記事では、公式の Usage ガイドをもとに、Fluent UI 2 の Accordion をいつ使うべきか、どう設計するべきか、React ではどう実装するかをまとめます。
関連記事として、Fluent UI 2 全体のアクセシビリティを整理した記事もあります。あわせて読むと判断しやすいです。
それでは、まず Fluent UI 2 における位置づけから見ていきます 🌟
Fluent UI 2 とは
Fluent UI 2 は、Microsoft のデザインシステム Fluent 2 に沿った UI コンポーネント群と設計指針です。単に見た目をそろえるための部品集ではなく、情報の優先順位、操作の一貫性、アクセシビリティまで含めて考えられているのが特徴です。
そのため Accordion も、「折りたためる UI 部品」としてではなく、どの情報を見せ、どの情報を一旦たたむかという情報設計の文脈で使う必要があります。
本記事のゴールは、その判断ができるようになることです。
今回のゴール ✅
- ✅ Fluent UI 2 における Accordion の役割を理解する
- ✅ どんな場面で Accordion が向いているか判断できるようになる
- ✅
defaultOpenItems、multiple、collapsibleの使い分けを把握する - ✅ レイアウト、見出し、アクセシビリティの注意点を理解する
- ✅
@fluentui/react-componentsを使った React 実装例をつかむ
ここからは、まず Accordion が向いている場面を整理します。
Accordion が向いている場面
Fluent UI 2 の公式 Usage ページでは、Accordion は related content（関連する内容）を開閉できるようにまとめるものと説明されています。FAQ のように、「今は見なくてもよいが、必要になったら参照したい情報」を整理するのに向いています。
また、利用者が見たいセクションを自分で選べるため、一度に全部を読ませないという意味で認知負荷の軽減にもつながります。
たとえば、次のような場面では使いやすいです。
- 設定画面の補足説明
- FAQ
- 詳細オプション
- セクションごとのヘルプ
- 初期表示では省略したい関連情報
公式ガイドでも、現在のタスクに必須の情報を Accordion の中に入れてはいけないとされています。入力に必要な注意事項、直前の判断に必要な条件、エラー解消に必須の説明などは、折りたたまずに見える場所へ置くべきです。
つまり Accordion は、「隠してよい情報」を整理するための道具です。次は、その前提になる既定の振る舞いを見ていきます。
Closed by default
Fluent UI 2 の Accordion は、既定では各項目が閉じた状態です。これは「最初から全部見せる」のではなく、必要な情報だけを利用者に選んで開いてもらう設計に合っています。
ただし、公式ガイドには、目立たせたい情報や最初に自動で見せたい情報があるなら、どの項目を既定で開くか指定してよいとあります。React では defaultOpenItems を使うと、この意図を実装できます。
判断の目安は次のとおりです。
| 状況 | どうするか | 理由 |
|---|---|---|
| まず全体を軽く見せたい | すべて閉じる | 情報量を抑えやすい |
| 最初に読んでほしい補足がある | 一部を既定で開く | 情報の目立ちやすさを上げられる |
| 現在の操作に必須の情報 | Accordion に入れない | 隠すと判断ミスにつながる |
「既定で閉じる」を基本にしつつ、本当に目立たせたい情報だけを開く、という考え方が扱いやすいです。次は複数同時に開くケースを見ます。
Multiple open items
通常、Accordion はある項目を開くと別の項目が閉じる振る舞いです。これは画面の縦方向の伸びを抑えやすく、読む対象を絞りやすいので、多くの場面で自然です。
一方で、公式ガイドでは、複数同時に開いても情報量が過剰にならない場合に限って、複数オープンを許可してよいとされています。React では multiple を使います。
たとえば、次のようなケースは multiple が合います。
- 複数の補足情報を見比べたい
- それぞれの項目が独立して読める
- 開いたままスクロールして確認したい
逆に避けたいのは、ある項目を見ながら別の項目も参照しないと理解できない構造です。公式ガイドでも、ある項目の情報を別の項目も見ないと理解できない設計は避けるべきとされています。
つまり multiple は便利ですが、情報同士が依存しているなら Accordion 自体を見直したほうがよいです。次は見た目のルールを整理します。
レイアウトと見出しのルール
公式ガイドでは、Accordion のヘッダーにある chevron アイコンは追加コンテンツの存在と開閉操作を示すものとされています。配置は先頭でも末尾でもよいですが、同じ体験の中では一貫させることが重要です。
また、ヘッダー文言にもルールがあります。
- パネルの中身が想像できる文言にする
- 短く保つ
- 英語 UI では sentence-style capitalization を使う
- タイトルの末尾にピリオドを付けない
日本語 UI では capitalization の影響は小さいですが、英語ラベルが混ざる画面では同じ考え方が役立ちます。たとえば Advanced settings は自然ですが、ADVANCED SETTINGS や Advanced settings. は避けたいです。
Microsoft Writing Style Guide の該当ページも置いておきます。
私としては、Accordion の見出しは「クリックさせる文」ではなく、中身の要約として書くのが一番ぶれにくいと感じます。次はアクセシビリティ上のポイントです。
アクセシビリティ ♿
公式 Usage ページでは、Accordion header は button role を持ち、支援技術から認識できるようにすることが示されています。また、項目が開いているときは aria-expanded が true になるべきです。
ここは、支援技術に伝わる情報と Fluent UI の内部状態を分けて考えると分かりやすいです。
-
aria-expandedは、スクリーンリーダーなどに「この項目は開いている / 閉じている」と伝えるための属性です - つまり、利用者が Accordion を開いたときに
aria-expanded="true"、閉じたときにaria-expanded="false"へ変わることが重要です - 一方で
activeは標準 ARIA 属性ではなく、少なくとも HTML にそのまま付ける属性として理解しないほうが安全です
そのため、実装者がまず確認したいのは、開閉に合わせて aria-expanded が正しく切り替わっているかです。
実装では、まずライブラリのコンポーネントを素直に使い、そこから生成されるアクセシブルな構造を壊さないことが重要です。
確認したいポイントは次のとおりです。
- ヘッダーがボタンとして認識されるか
- 開閉時に
aria-expandedが変化するか - キーボードで開閉できるか
- 見出しだけで内容の見当がつくか
つまり Accordion のアクセシビリティは、属性を足すことよりも、正しいコンポーネント利用と情報設計のほうが効きます。最後に React 実装例を見てみます。
React での実装例 ⚛️
以下は @fluentui/react-components を使ったシンプルな例です。基本形、defaultOpenItems、multiple、collapsible をひととおり入れています。
import * as React from "react";
import {
Accordion,
AccordionHeader,
AccordionItem,
AccordionPanel,
Text,
} from "@fluentui/react-components";
export const ArticleAccordionExamples = () => {
return (
<div style={{ display: "grid", gap: "24px", maxWidth: "720px" }}>
<section>
<Text as="h3" weight="semibold">
基本の Accordion
</Text>
<Accordion>
<AccordionItem value="what-is-it">
<AccordionHeader>Accordion とは</AccordionHeader>
<AccordionPanel>
関連する情報をまとめ、必要なときだけ開いて読めるようにする UI です。
</AccordionPanel>
</AccordionItem>
<AccordionItem value="when-to-use">
<AccordionHeader>向いている場面</AccordionHeader>
<AccordionPanel>
FAQ、設定の補足、詳細オプションのように、今すぐ必須ではない情報に向いています。
</AccordionPanel>
</AccordionItem>
</Accordion>
</section>
<section>
<Text as="h3" weight="semibold">
defaultOpenItems と collapsible
</Text>
<Accordion defaultOpenItems={["summary"]} collapsible>
<AccordionItem value="summary">
<AccordionHeader>最初に読んでほしい概要</AccordionHeader>
<AccordionPanel>
この項目は初期表示で開いています。概要を目立たせたいときに便利です。
</AccordionPanel>
</AccordionItem>
<AccordionItem value="notes">
<AccordionHeader>補足事項</AccordionHeader>
<AccordionPanel>
<ul>
<li>必須情報は Accordion の中に隠さない</li>
<li>見出しは短く、中身が想像できる表現にする</li>
</ul>
</AccordionPanel>
</AccordionItem>
</Accordion>
</section>
<section>
<Text as="h3" weight="semibold">
multiple を使う例
</Text>
<Accordion multiple>
<AccordionItem value="design">
<AccordionHeader>情報設計の観点</AccordionHeader>
<AccordionPanel>
各項目が独立して読めるなら、複数同時オープンは有効です。
</AccordionPanel>
</AccordionItem>
<AccordionItem value="a11y">
<AccordionHeader>アクセシビリティの観点</AccordionHeader>
<AccordionPanel>
開閉状態が支援技術に伝わること、キーボードで操作できることが重要です。
</AccordionPanel>
</AccordionItem>
<AccordionItem value="implementation">
<AccordionHeader>実装の観点</AccordionHeader>
<AccordionPanel>
`defaultOpenItems` や `multiple` は便利ですが、まずは情報を分ける粒度が適切かを見直します。
</AccordionPanel>
</AccordionItem>
</Accordion>
</section>
</div>
);
};
ポイントを整理すると次のとおりです。
- 基本形: まずは単一オープン前提で使うと設計しやすいです
-
defaultOpenItems: 初期表示で開きたい項目を指定できます -
multiple: 複数項目を同時に開けます -
collapsible: 開いている項目を再度閉じられるようにし、すべて閉じた状態へ戻せます
defaultOpenItems を使うときも、「目立たせたいから開く」のか、「必須情報だから出したい」のかは分けて考えたいです。後者なら Accordion の外へ出したほうが安全です。
実装自体はシンプルですが、本当に重要なのは props の使い方より「その情報を折りたたんでよいか」という判断です。最後にまとめます。
まとめ 📝
Fluent UI 2 の Accordion は、関連する情報をまとめて開閉できる便利なコンポーネントです。特に、利用者が見たい範囲を選べるため、認知負荷を下げるという意味で効果があります。
ただし、次の原則は強く意識したいです。
- 必須情報は Accordion に入れない
- 既定では閉じる
- 必要なら
defaultOpenItemsで目立たせる - 複数オープンは、情報量が過剰にならない場合だけ許可する
- ある項目の内容を別項目から参照させない
- ヘッダー文言は短く、中身が分かるものにする
-
aria-expandedのような状態が支援技術に伝わることを大切にする
Accordion は「省スペースのための部品」というより、情報の見せ方を調整するための部品として考えると使いどころがぶれにくいです。
次に Fluent UI 2 の別コンポーネントを見るときも、見た目だけでなく情報設計とアクセシビリティの原則から読むと理解しやすくなるはずです 📝