アイコンボックス — 書式、ルール、および例

アイコンボックスは、1つの意図のあるアイコンと短いラベル、焦点を絞った説明を組み合わせます。アイコンは主題を認識可能にし、ラベルはそれを名付け、テキストはその重要性を説明します。この要素は、3つの製品機能や4つの要件など、小さなピアグループの1メンバーとして最も効果的に機能します。ページ全体に散りばめられた装飾として使用するものではありません。

チェック記号には意図があります。空いているスペースを埋めるのではなく、検証を強化します。可視ラベルがすでに同じ意味を述べているため、レンダリングされた記号は支援技術から隠されています。スクリーンリーダーユーザーは、「検証済みソース」とその説明から完全なメッセージを受け取り、冗長なアイコン出力を聞く必要はありません。

この要素が重要な理由

読者はすべての文を順番に処理するわけではありません。彼らは「これは自分が必要とするものについてのものか？」という問いに答えるランドマークを探します。アイコンボックスは、コンパクトな認識パターン（形状が最初、ラベルが二番目、説明が三番目）を作り出します。適切に形成されたグループでは、読者はラベルをスキャンし、関連するカテゴリを特定し、必要な補足テキストだけを読むことができます。これにより、同じ重みのアイデアが複数含まれた段落を解読する労力が軽減されます。

心理的な価値は、認識、チャンキング、および一貫性から生まれます。馴染みのある盾は保護を、時計は時間を、書類はレポートを、読者がラベルを読み終える前に示唆できます。ラベルはその後、曖昧さを取り除きます。繰り返される形状は、アイテムが同じ編集上のランクを持つことを読者に伝えます。そのシグナルは、コンテンツが真に並列である場合にのみ有用です。カードグリッドは、無関係な主張を首尾一貫したセットに変えることはできません。

機械による抽出可能性とは、ソフトウェアが主題と主張を保持しながらコンテンツ単位を分離できることを意味します。構造化されたアイコンボックスは、名前付きアイテムを簡潔な本文と、オプションのグループ内の安定した位置とともに公開します。検索システムは、「検証済みソース」をその説明と一緒に抽出でき、どの文がどの視覚記号に属するかを推測する必要がありません。アイコンアセット自体は抽出にほとんど貢献しないため、可視の言葉が完全な命題を伝えなければなりません。

アイコンには編集上の意味が依然として必要です。恣意的なキラキラ、ロケット、抽象的な形状は、人にとってノイズを加え、機械にとって有用なセマンティクスを提供しません。「意図はあるが冗長」は有効なアクセシビリティモードです。アイコンは、晴眼読者がカテゴリを認識するのに役立つ一方で、可視ラベルがすでにその意味を提供しているため、支援技術から隠すことができます。要素の記述ルール に従い、最初に完全なアイデアをドラフトし、後の構造パスのみでアイコンボックスを選択してください。ここでの要素固有の制限は、アイコンの選択、グループ化、およびアクセシビリティマッピングにおいて優先されます。

使用するタイミング

アイコンボックスは、コンテンツが1つの簡潔で名前付きのアイデアであり、承認されたシステムのアイコンが推測なしにそのアイデアを表現できる場合に使用します。グループは、2～6個のアイテムが同じ暗黙の質問に同等の深さで答える場合に適しています：「何が含まれますか？」、「どのような保護対策が適用されますか？」、「このワークフローは何を生成しますか？」各アイテムは、プレーンテキストとしてコピーされた場合でも理解可能であるべきです。

優れた使用例としては、アイテムごとに1つの成果を示す機能概要、詳細な手順の前の要件概要、サービスの原則セット、またはワークフロー出力のコンパクトな説明などがあります。アイコンは認識の補助手段であり、証拠ではありません。ファイル形式、応答期間、サポート対象システム、所有権などの詳細は、依然としてラベルと本文に属します。

ほぼ該当するが微妙に異なるケースは一般的です。

• すべてのアイテムに同じチェックマークのアイコンを使用する場合は、通常の箇条書きリストを使用します。繰り返しはカテゴリの意味を伝えません。
• アイテムを共通の基準で評価する必要がある場合は、比較表を使用します。個別のアイコンボックスはアイテム間の比較を難しくします。
• 順序、完了、または依存関係が重要な場合は、ステップリストを使用します。アイコンボックスの並びはシーケンスではなくピアを意味します。
• 1つの馴染みのない用語に正式な意味が必要な場合は、定義ボックスを使用します。アイコンは正確な定義を強化しません。
• 重大度と中断が主な役割である場合は、警告または注意を使用します。アイコンボックスには中立的な構造的重みがあります。
• 各アイテムに複数の段落、証拠、メディア、または小見出しが必要な場合は、完全なセクションを使用します。

テキストが多いページをデザインされたように見せるためだけにアイコンボックスを使用しないでください。著者が意味的に正確であるよりも視覚的に魅力的なものを探してアイコンを選択した場合、おそらくこの要素は必要ありません。

配置する場所

スタンドアロンのアイコンボックスは、それがサポートする段落の直後に配置します。アイコンボックスグループは、見出しと共有質問を名付ける1つの導入段落の後に配置します。このコンテキストは、アイテムがなぜ一緒に属するのかを説明し、グループはコンパクトな答えを提供します。グループの後には、各ボックスを散文で繰り返すのではなく、詳細、証拠、または次の決定事項を配置します。

記事では、最初のグループは直接の回答または冒頭の定義の後にのみ表示します。商用ページでは、機能グループは問題と成果のステートメントの後に続くことがありますが、価値提案の前に配置して視覚的なヒーローを作ることは避けます。ドキュメントでは、要件グループはそれが管理する手順の前に配置します。ただし、必要な順序と合格基準は通常の指示に保持します。

アイコンボックスグループを、別のカードグリッド、比較表、ロゴウォール、統計バンド、またはマルチカラムのコールトゥアクションのすぐ隣に配置しないでください。隣接するグリッドは情報階層を平坦化し、編集上の事実がプロモーションのように見えるようにします。それらの間に説明文またはセクション区切りを挿入します。主張とそのソースの間、ステップとその期待される結果の間、テーブルセル内、または別のアイコンボックス内にアイコンボックスを配置しないでください。2つのグループを背中合わせに配置することも避けてください。

構成要素

アイコンボックスには、3つの作成領域と1つのコンテキスト上の関係が含まれます。スクリーンショットはピクセル値ではなく意味を持つ領域をラベル付けするため、契約はビジュアルの再設計後も存続します。

1. アイコン領域: アイテムのコンセプトに一致する承認済みアイコンを1つ使用します。可視の言葉の代わりにはなりません。
2. 短いラベル: 機能、要件、成果、またはカテゴリを具体的な言葉で名付けます。
3. テキスト本文: 結果、範囲、または証拠を1つのコンパクトな段落で説明します。
4. オプションのリンク先: リンクバリアントを使用する場合、1つの説明的な次のステップを提供します。
5. グループコンテキスト: 先行する見出しまたはアクセス可能なグループラベルが、すべての兄弟アイコンボックスが答える質問を述べます。

境界線、背景、角丸、アイコンサイズ、色、グリッド列、ブレークポイントはレンダラーに属します。著者は意味的内容、アイコン識別子、ソース順序、およびアクセシビリティモードを選択します。

デザイン例

この要素は4つの表示バリアントをサポートします。すべて同じアイコン-ラベル-本文の階層と同じソース順序を保持します。

標準: デフォルトのスタンドアロンまたはグループ化されたカード。本文に25〜60語の説明が必要な場合に使用します。

コンパクト: 12〜30語の1文の本文を使用します。馴染みのある概念に適しており、微妙な条件を圧縮するのには適しません。

リンク: 1つのリンク先を追加します。可視の説明的リンクを推奨します。カード全体がインタラクティブな場合、レンダラーは単一のリンクターゲットと明確なフォーカス状態を提供する必要があります。

ステータス: 利用可能、制限付き、合格、保留中などの状態を伝えます。ステータスの言葉は可視でなければならず、色もアイコン形状も唯一のシグナルであってはなりません。

狭いビューポート: グループはソース順に1列になります。レンダラーは高さを揃えるためにボックスを並べ替えてはなりません。

アクセシビリティモードは表示バリアントとは別です。冗長なアイコンは、ラベルが同じ意味を持つため、支援技術から隠されます。真に情報を提供するアイコンはプログラムによるテキスト代替を受け取りますが、作成者は通常、アイコンのみの事実を維持する代わりに、その情報を可視ラベルに追加すべきです。

パラメータ

契約は、作成された意味とプレゼンテーションを分離して維持します。より厳しい制限が明記されていない限り、制限はすべてのバリアントに適用されます。

iconは承認済みアイコンレジストリを通じて解決されなければなりません。作成者は任意のSVG、絵文字、画像URL、またはアイコンフォントのクラス名を提供できません。制限付きMarkdownでは、強調、インラインコード、および1つのインラインリンクが許可されます。ネストされた見出し、リスト、表、メディア、フォーム、ボタン、アコーディオン、およびその他のコンポーネントは除外されます。本文の最初の見出しがlabelを提供する場合、アダプターは本文からその見出しを削除し、ページ相対の正しいレベルでレンダリングします。

構文とコード例

各表記法は、同じアイコン、ラベル、本文、バリアント、およびアクセシビリティモードにマッピングされます。アイコンキーは意味論的でポータブルです。各プラットフォームはshield-checkを承認済みのローカルアセットにマッピングします。

ポータブルMarkdownディレクティブ

:::iconbox{icon="shield-check" iconMode="redundant" variant="standard"}
### 検証済みソース

すべての事実に基づく主張は、レビュー担当者が確認できるソースにリンクされているため、証拠は執筆中、承認中、およびその後の更新中も可視のままです。
:::

最初の見出しがlabelになり、残りの段落がcontentになります。「検証済みソース」が可視テキストで完全な意味を提供するため、アイコンは冗長です。

Hugoショートコード

{{< iconbox icon="shield-check" label="Verified sources" iconMode="redundant" variant="standard" >}}
Every factual claim links to a source a reviewer can inspect, so evidence remains visible during writing, approval, and later updates.
{{< /iconbox >}}

アダプターは名前付きパラメータのみを使用します。未知のアイコンキーやバリアントは、意味を変える可能性のあるフォールバックを静かに表示するのではなく、拒否しなければなりません。

WordPressブロック

<!-- wp:amicited/iconbox {"icon":"shield-check","label":"Verified sources","iconMode":"redundant","variant":"standard"} -->
<p>Every factual claim links to a source a reviewer can inspect, so evidence remains visible during writing, approval, and later updates.</p>
<!-- /wp:amicited/iconbox -->

エディターは、自由テキストのアセットフィールドではなく、検索可能な承認済みアイコンピッカーを公開する必要があります。そのアクセシブルな名前プレビューでは、アイコンが非表示か読み上げられるかを示す必要があります。

例

良い例

これが機能する理由は、書類記号がレポートのコンセプトと一致し、ラベルが具体的な機能を名付け、本文が出力とその実用的な結果を説明しているからです。可視テキストは記号なしでも完全であるため、記号は支援技術から隠すことができます。

悪い例

これはすべての層で失敗しています。ロケットは正確なカテゴリマーカーではなく装飾的であり、ラベルには具体的な機能が含まれておらず、本文には仕組み、境界、検証可能な結果が示されていません。絵文字も予測不能に読み上げられる可能性があります。このブロックを具体的な記述（何が、どのメカニズムで、どのような条件下で高速になるのか）に置き換えるか、削除してください。

スキーママークアップとアクセシビリティ

アイコンボックスには専用のSchema.orgタイプはありません。そのラベルと本文は、マークアップが別途正当化される場合、親のArticle、TechArticle、WebPage、Product、またはその他のページレベルのエンティティのコンテンツとして残ります。視覚的なグループは自動的にItemListにはなりません。コンテンツモデルにおいてセットが完全または順序付けられている場合にのみ、リストマークアップを使用します。ステータスアイコンボックスは、必要な基礎データなしにReview、Rating、または可用性プロパティを正当化しません。

非インタラクティブなアイコンボックスは、主要な議論の一部である場合はsectionとして、補足的である場合はasideとしてレンダリングします。可視ラベルを通じてアクセシブルな名前を付けます。正しいレベルの実際の見出しを使用し、デフォルトのフォントサイズが適切に見えるという理由だけでh3を選択しないでください。繰り返されるピアは、グループが実際にリストである場合にリスト内に配置でき、各アイコンボックスは1つのリストアイテム内に配置されます。

ほとんどのアイコンは、aria-hidden="true"およびfocusable="false"を持つインラインSVGであるべきです。これは、可視ラベルがそれらの意味を繰り返すためです。これはそれらを編集上装飾的にするわけではありません。視覚的な認識には依然として役立ちますが、同じ概念を2回読み上げるとノイズが増えます。アイコンがラベルにない情報を伝える場合は、コンポーネントのiconTextマッピングを通じてアクセシブルなテキスト代替を提供します。さらに良いのは、すべての読者がその事実を受け取れるように、可視ラベルを修正することです。

色、位置、動き、またはアイコン形状のみに依存しないでください。緑色のチェックには「合格」などの可視テキストが必要です。鍵には「制限付き」または正確なアクセス条件が必要です。アイコンは背景に対して十分なコントラストが必要ですが、コントラストカラートークンはレンダラーが所有します。何も伝えない装飾的な飾りは、冗長な代替テキストを割り当てるのではなく削除する必要があります。alt="icon"、ファイル名、Unicodeグリフ名、「シールド、検証済みソース」などの重複テキストは避けてください。

リンクバリアントの場合、1つのアイコンボックスには1つのリンク先があります。インタラクティブな名前はそのリンク先を伝えなければならず、キーボードフォーカスは可視でなければならず、クリック可能な領域には別のリンクやボタンを含めてはいけません。ホバーでは重要なテキストを明らかにしてはいけません。読み上げ順序とキーボード順序は、すべてのビューポート幅でソース順序と一致している必要があります。

記述ルール

アイコンを選択する前にラベルを記述します。ラベルは具体的な名詞句または短い成果にすべきです：「ロールベースのアクセス」、「毎週のエクスポート」、「人間によるレビュー」。ピアのラベルは文法的に並列にします。「パワフル」、「シームレス」、「革新的」、「ベストインクラス」などの汎用的な主張は避けてください。これらは機能も決定事項も名付けていません。

ラベルには2〜6語、最大55文字を使用します。本文は1段落で12〜60語とし、コンパクトバリアントは12〜30語に収めます。具体的なメカニズム、範囲、または結果で始めます。落ち着いた事実に基づくトーンを保ちます。条件が約束を変更する場合は、遠くの細字部分ではなく同じボックス内に記載します。

グループには2〜6個のボックスを使用します。すべてのアイテムに同等の深さを持たせ、同じ質問に答えさせます。どのアイコンが最も見栄えがするかではなく、読者の優先順位、ワークフローの論理、または明示されたカテゴリで順序付けます。1つのグループ内で異なる意味に同じアイコンを使用せず、複数のビジュアルスタイルやアイコンファミリーを一緒に使用しないでください。

アイコンボックス内に以下のものを絶対に入れないでください：

• 長い機能リスト、複数ステップの手順、ネストされた箇条書き、表、フォーム、推薦文、価格、法的免責事項。
• アイコンのみのラベル、説明のない略語、または色だけで表現されたステータス。
• 複数のリンク、競合するコールトゥアクション、カード全体のリンク内のボタン。
• スクリーンショット、動画、チャート、ロゴ、写真、または別のアイコンボックス。
• 複数のボックスに適用されるが1つにしか表示されない証拠。これによりグループが不均衡または誤解を招くものに見えます。

コンテンツがこれらの制限を超える場合は、通常のセクションに昇格させます。すべてのアイテムに同じチェックマークが必要な場合は、アイコンを削除してリストを使用します。ラベルが画像なしでは意味をなさない場合は、公開前にラベルを書き直します。

使用する投稿タイプ

postTypesフロントマター項目がこのテーブルのソースです。包含は、コンテンツが真正なピアセットを形成する場合に要素が利用可能であることを意味し、そのタイプのすべてのページにアイコンボックスを含めるべきという意味ではありません。

QAチェックリスト

• 意図のあるアイコン: すべてのアイコンはそのラベルとの明らかな関連性を持ち、削除すると事実上の意味ではなく視覚的な認識が低下します。
• 完全な可視テキスト: ラベルと本文は、アイコン、色、または位置に依存せずに完全な命題を伝えます。
• 正しいアクセシビリティモード: 冗長なアイコンは非表示にされ、情報を提供するアイコンには簡潔なテキスト代替と文書化された理由があります。
• 真のピアグループ: 兄弟アイテムは同じ質問に答え、同等の深さを持ち、並列なラベル文法を使用します。
• 安全な数: グループには2〜6個のアイテムが含まれ、より大きなセットはカテゴリ化されるか、より適切な構造に移動されます。
• 正確なコピー: ラベルは具体的な機能、要件、状態、または成果を名付け、本文はメカニズム、範囲、または結果を提供します。
• 有効なアイコンソース: すべてのアイコンキーは承認済みレジストリに存在し、絵文字、任意のSVG、画像URL、またはアイコンフォントクラスは作成されません。
• 適切な配置: グループはそのフレーミングコンテキストに従い、主張とソース、ステップと結果、または警告と影響を受けるアクションを分離しません。
• 安全な隣接要素: カードグリッド、表、ロゴウォール、統計バンド、またはマルチカラムCTAがグループのすぐ隣に配置されていません。
• アクセシブルな構造: 見出しレベルは文書に従い、コントラストは十分で、ステータスには可視テキストがあり、ソース順序は読み上げ順序と一致します。
• インタラクションの制約: リンクアイコンボックスには1つのリンク先、説明的な名前、可視のフォーカス状態、およびネストされたインタラクティブコントロールがありません。
• 表記法のパリティ: ポータブルMarkdown、Hugo、およびWordPressは、同じアイコンキー、ラベル、コンテンツ、バリアント、およびアクセシビリティ動作を保持します。
• スキーマの制約: コンポーネントはスタンドアロンのスキーマを追加せず、外観からItemListやステータスプロパティを推測しません。
• レスポンシブ検証: 狭い幅では、ボックスはクリップ、水平スクロール、または不可視の重要なテキストなしにソース順に積み重ねられます。

アイコンが恣意的である場合、ラベルが曖昧である場合、または可視テキストが記号に依存している場合は、要素を拒否します。これらはコンテンツモデルの欠陥です。間隔、色、またはイラストスタイルを変更しても修復できません。

FAQ

フロントマターのFAQは、グループサイズ、代替テキスト、リンクカード、絵文字、およびスキーマ動作をカバーしています。承認された回答を構造化されたフロントマターに保持することで、アカデミーレイアウトは、記事本文で同じ質問を重複させることなく、それらを一貫してレンダリングできます。