Webのガイドライン

情報構造、操作、状態、アクセシビリティを一貫して設計する。

媒体一覧 · 共通ガイドライン · チェックリスト・禁則事項

6.1 WebアプリとWebサイト

• 必須: 一連の処理ではProgressまたはStepperで現在地点を示します。
• 必須: 印刷スタイルでは、ナビゲーションと装飾を除き、本文、出典、図表を保持します。
• 必須: 利用者が見るControlの面、境界、Icon、文字、選択、進行、成功、警告、ErrorはLiberkaの意味役割とtokenで設計します。Native elementの意味や入力機能を使う場合も、Browserごとの未調整な既定外観を最終デザインにしません。
• 必須: Browser組込みの検証Bubble、確認画面、選択結果だけを、Errorや重要な判断を伝える唯一の経路にしません。製品内の文言と状態として同じ内容を確認できるようにします。
• 原則: Semantic HTMLを優先し、見た目のために意味を壊しません。
• 原則: Native elementが提供する入力、読み上げ、Keyboard、Mobile連携は維持し、必要な外観だけを正規化します。外観の統一を理由に、より弱い独自Controlへ置き換えません。
• 原則: 320 CSS pxから大画面まで、情報の優先順位を保って再配置します。
• 原則: LoadingとEmptyでも、Page Header、Navigation、Toolbar、入力領域、一覧、表、図表など、完了後に使う実際の構造を先に表示します。
• 原則: 主要操作は44×44 CSS pxを目安とし、WCAG 2.2のターゲットサイズ基準を下回りません。
• 禁止: Hoverへ情報や操作を依存させません。
• 禁止: ブラウザ標準のalert()、confirm()、prompt()を製品体験に使いません。
• 禁止: 通常レイアウトで100vwを使って意図しない横スクロールを発生させません。

Webの余白とControl token

値の一覧は実装のためだけに別ファイルへ置かず、この節を正本とします。JSONとCSSは、この表を機械処理できる形へ写したものです。

• 必須: pageInline、contentMeasure、sectionGap、componentGap、sidebarInsetを用途どおりに使います。
• 必須: 入力面はbox-sizing: border-boxとし、文字、caret、Placeholder、Iconを境界外へ出しません。
• 原則: 320 CSS pxではpageInlineCompact、通常画面ではpageInline、十分な幅ではpageInlineWideを使い、本文の一行を不必要に長くしません。

Webのcontinuous corner

Webでは、標準CSSが利用できる場合にcorner-shapeを使い、border-radiusが定める範囲へsuperellipse(2)、すなわちsquircleを適用します。corner-shapeはBorder、Outline、Overflowを同じ輪郭へ追従させるため、初期導入ではJavaScriptによるResize監視やSVG maskを必要としません。

• 必須: border-radiusをfallbackとして先に宣言し、@supports (corner-shape: squircle)の中だけでcontinuous cornerを有効にします。

• 必須: 初期適用対象は角丸矩形のButtonとCardに限定します。ピル形Button、Search Field、Icon Button、Radio、Input、Dialogは対象外とします。

• 必須: 対応時も非対応時も、同じHTML、Border、Focus Visible、操作対象寸法、読み順を維持します。

• 原則: 比較図や事前計算された署名形状の生成には、正本tokenと同じスーパー楕円モデルを使います。

• 許容: 説明用の比較図では、未対応Browserでも曲率差を確認できるよう、同じ値から生成したSVG pathを使えます。

• 禁止: continuous cornerをHoverや選択状態として切り替えたり、形状を連続Animationさせたりしません。

• 禁止: 標準CSSの非対応だけを理由に、実行時の高頻度なpath再計算、Canvas、WebGLを導入しません。

• 禁止: Cardを選択、モード切替え、表示切替え、ページ遷移に使いません。

• 禁止: 破壊的操作を確認なしで実行しません。

• 禁止: 破壊的操作を赤系以外で示しません。

• 禁止: LabelをCardまたはSectionの見出しとして使いません。

• 禁止: すべてを中央揃えにしたり、内容のない100vhヒーローを作ったりしません。

• 禁止: 全CardをHover時に拡大したり、transition: allを使ったりしません。

• 禁止: 全Sectionへfade-up、bounce、cursor followerを適用しません。

Web固有の禁止事項の検査

• 必須: 該当する第7章の部品仕様と第8・9章の操作・状態・アクセシビリティを受け入れ項目へ接続します。初期表示だけで、未操作のDialog・送信・失敗状態を合格にしません。
• 禁止: 意図しない横はみ出し、隠れた主要操作、入力内容の消失を残して受け入れ完了にしません。

Webの本文書体

• 原則: 本文と操作には、OSと調和するsystem UI sans-serifを基準にします。

Webの余白token値

Webへ実装するCore spacing tokenは、spacing.micro2: 2px、spacing.micro3: 3px、spacing.micro4: 4px、spacing.micro6: 6px、spacing.12: 12px、spacing.24: 24px、spacing.36: 36px、spacing.48: 48px、spacing.72: 72px、spacing.96: 96px、spacing.120: 120pxです。

Webのピル形状

• 許容: ピル形状は、短い一行のButton、Label、Search Field、Chat Composerに限ります。

Webの読み順

• 必須: 視覚順、DOM上の読み順、読み上げ順を一致させます。

白を基調とした左上のミント色背景

LiberkaのWeb画面とWebサイトは、白を基調とし、左上からミント色が穏やかに広がる静止gradientを共通背景にします。これは情報や状態を表す面ではなく、Liberkaらしさを静かに支えるCanvasです。

• 必須: 背景の基底にはbackground.base（#FFFFFF）、左上の色にはbackground.mint（#8ECCB0）、基準となる最大不透明度にはbackground.mintOpacity（0.24）を使います。
• 必須: gradientは左上を起点とし、本文、操作、図表より背面へ固定した静止表現にします。
• 原則: Header、Sidebar、Card、Dialogなど内容を載せる面は白いSurfaceを基本とし、文字直下の明度を安定させます。
• 禁止: 背景の位置、濃度、形を、時間、scroll、cursor、利用者情報、random値で変化させません。
• 禁止: blob、発光orb、粒子、video、Canvas、WebGLを背景表現へ追加しません。
• 禁止: 背景に意味、進捗、選択状態を持たせたり、背景に起因するCLSや入力遅延を発生させたりしません。

Webの文字寸法

Webの余白の実装

Web実装では--spacing-unit: 12pxを起点とする--spacing-12から--spacing-120までのトークンを使い、同じ階層に理由のない近似値を混在させません。プレゼンテーションと文書では、CSS pxをそのまま移植せず、12基準の比率をpt、mm、グリッドへ置き換える。

Webアプリのgap、padding、margin、inset、固定要素の補正には、生のpx、rem、emではなく正式な余白トークンを使います。この規則は認証後画面だけでなく、公開画面、認証画面、管理画面、Dialog、Popoverにも適用します。操作対象の44 CSS px、1 pxの境界、文字寸法、図形の描画位置など、余白とは異なる寸法は対象外とします。個別の例外値が構造上必要な場合は、用途が分かる名前のトークンとして定義し、同じ役割で共有します。

Webの角と曲線の実装基準

角の大きさと、直線から曲線へ移る仕方は別の性質です。radiusは角が占める範囲を表し、cornerはその範囲で曲率がどう変化するかを表します。通常の円弧は直線から角へ入る地点で曲率が急に変わります。LiberkaのControl、Card、Surfaceでは、直線から曲線へ穏やかにつながるスーパー楕円を基本形とします。

ここでParameterはCSS Borders Level 4のsuperellipse(K)と同じKです。2は指数2^2 = 4のスーパー楕円で、CSS keywordのsquircleと等価です。Figma固有の割合と誤解されるcorner smoothingというtoken名は使いません。

• 必須: 複雑な輪郭は事前計算したベクターパスまたは少数の制御点として保持します。
• 必須: radiusとcornerを別のtokenとして参照し、半径だけを連続曲率の根拠にしません。
• 必須: Pill Button、Search Field、Chat Composerの一行状態、Icon Button、Radioは円または円弧の意味を保ち、continuous cornerへ変更しません。
• 原則: 表示時に高価な曲線計算を繰り返しません。
• 原則: 標準角丸は、Control 10、Card 14、Surface 18相当を基準とします。
• 原則: 大きな輪郭や署名表現でも、クロソイド、サイン曲線、スーパー楕円、調整済みBezier曲線のように、接線と曲率が自然に変化する形を優先します。
• 原則: すべてを大きな角丸にして柔らかさを演出しません。
• 許容: 小さな操作部品、入力、カードには、互換性と性能のため標準的な角丸を使えます。
• 許容: 左右端が円になるピル形状は、Buttonと短いLabelに限って使えます。
• 禁止: 曲線表現のためにButtonやInputをSVGへ置き換えたり、Focus Visible、境界、Semantic HTMLを失うmaskを適用したりしません。

実装tokenはradius.control: 10px、radius.card: 14px、radius.surface: 18px、radius.pill: 999pxと、corner.control、corner.card、corner.surfaceを組み合わせます。999pxは実寸を巨大にする値ではなく、短い一行要素の左右端を円にするためだけに使います。

良い例: Buttonはradius.controlとcorner.controlを使い、未対応Browserでも同じButton要素と通常の角丸を保ちます。

悪い例: Cardを角の形に切り抜くためだけにSVG maskを常用し、1px境界とFocus outlineを別要素で描き直します。

確認方法: 対応Browserと非対応Browserの双方で、ButtonとCardの寸法、全周境界、Focus Visible、overflow、印刷を比較します。曲線の差が消えるfallbackは許容しますが、情報、操作、境界を失うfallbackは不適合です。

Webの固定Composerの奥行き

• 許容: Chat Composerを会話面の下端に固定し、前後関係を境界と面の明度だけでは判別できない場合は、一段の控えめな影を使えます。

• 禁止: 影の有無にかかわらず、ComposerがMessage Logを隠す配置にはしません。

アイコンの取得元と統一

• 原則: 一つの成果物または製品で、線幅、端部、塗りの方針が揃ったアイコン体系を使います。
• 原則: 新しく機能アイコンを選ぶ場合は、Lucide公式カタログのoutline体系を第一候補にします。React / Next.jsでは公式のlucide-reactから使用するアイコンだけを名前付きimportし、採用版をlockfileで固定します。
• 原則: HTML、スライド、文書では同じ公式カタログのSVGを使い、取得元、アイコン名、版または取得日、ライセンスを制作記録に残します。配布物には採用した資産に必要な著作権・許諾表示を保持します。
• 原則: 同じ意味には同じアイコンを対応させ、選択を製品の共通マッピングまたは認定部品で管理します。ページごとに別の絵を選び直しません。
• 原則: 新規の機能アイコンでは手書きSVG、フォントの文字記号、画像検索で拾った素材を第一候補にせず、正規の取得元から選びます。
• 許容: 既存の認定Component内のSVGやOS標準Symbolは、意味と外観が一貫している間は継続できます。既存部品はconsumerで複製せず、その所有先で移行と検証を行います。
• 許容: 適切な意味のアイコンがない場合は文字だけにできます。別体系や独自図案が必要なら、意味、取得元、ライセンス、既存体系で表せない理由を所有先のPRに記録します。
• 禁止: 絵文字を機能アイコンとして使いません。

LucideのReact利用方法とライセンスを参照します。 公式ブランドロゴは機能アイコンで代用せず、brand/または各権利者の公式資産を使います。 Lucideの採用は、その色・寸法・部品の外観をLiberkaのtokenより優先するものではありません。

見出しと操作での使い分け

• 原則: Webの機能Section見出し、主要Navigation、反復する操作には、意味を識別できるアイコンを積極的に用います。見出しは「アイコン＋短い見出し文字」を基本とし、見出し階層と読み上げられる名前を保ちます。
• 原則: 画面の大見出し、長文記事、スライドの結論、文書の章見出しには機械的に付けず、内容の種類を見分ける助けになる場合に使います。同じアイコンを全見出しへ反復しません。
• 原則: 初めて使う機能、製品固有の行動、送信、削除、公開・共有範囲の変更には、何が起こるかを表す短い文字を残します。「記録」「相談」など解釈が分かれる機能を絵だけへ置き換えません。
• 原則: アイコンを小さくしても操作対象は縮めず、第9章の操作寸法、Focus、コントラスト、文字拡大の条件を保ちます。見出し文字との間隔・サイズ・線幅は同じ役割の中で統一します。
• 許容: 対象が明確な編集、検索、閉じる、前後移動など、文脈から動作を判断できる反復操作はアイコンだけにできます。初見で伝わらない場合は文字を併記します。
• 禁止: 状態、件数の単位、必須入力、エラーの原因、重要な注意を、アイコン化を理由に取り除きません。

この表は意味選択の例であり、各製品の情報設計や既存マッピングを一括で変更する指示ではありません。 同じ意味の候補を複数採用する場合は、利用者が違いを説明できるかを確認します。

アクセシビリティと確認

• 原則: アイコンだけの操作にはアクセシブルネームを付けます。
• 原則: 文字と重複する装飾SVGはaria-hidden="true"とし、二重に読み上げません。アイコンだけのButtonやLinkの名前はSVGではなく操作要素に付けます。
• 原則: 操作名は「ペン」ではなく「振り返りを編集」のように目的を示します。Hover時のTooltipやSVGのtitleだけを名前・説明の唯一の経路にしません。
• 原則: 意味のある状態アイコンは文字やアクセシブルな状態と組み合わせます。Keyboard、VoiceOverなどの読み上げ、forced-colors、実際の表示寸法で、識別と操作を確認します。

良い例は、短い見出しをアイコンで見分けられ、編集は小さくても押しやすく、共有操作の文字は残る画面です。 悪い例は、見出しを絵だけにする、すべてに同じ飾りを付ける、独自の絵の意味をTooltipで説明しないと操作できない画面です。

6.4 グラフ、表、データ可視化

視覚表現は、量の可視化に加え、比較・関係・構造・業務・体験・場面を読者が理解できる形へ変換する仕事です。6.4.1〜6.4.10に、選択手順、72の形式、素材、媒体別の仕上げ、監査の手引きを整理します。以下の規則は全体に適用し、形式一覧は条件に応じて選ぶ候補として扱います。

• 必須: 軸、単位、期間、母数、集計方法、欠損、出典を必要に応じて示します。
• 必須: インタラクティブなグラフには、同じ情報へ到達できる要約または表形式の代替を用意します。
• 原則: 図表は問いに答えるために選び、見栄えのために種類を増やしません。
• 原則: タイトルは何を比較しているかを表し、読み手に結論を強制する誇張表現を避けます。
• 原則: 色だけで系列を区別せず、直接ラベル、線種、記号、配置を併用します。
• 原則: 円グラフは少数の構成比に限り、比較が目的なら棒グラフを優先します。
• 原則: 切断軸、面積、遠近法で差を誇張しません。
• 原則: 表の数値は桁、小数点、単位を揃え、並び順に意味を持たせます。
• 禁止: 比較に不要な3D、影、グラデーション、過剰な補助線を使いません。

比較を誤らせない表現

• 原則: 棒の長さで量を示す場合はゼロを基点とします。微小な差を示す場合は差分や点の位置など別表現を検討します。折れ線にゼロ基点を一律強制せず、尺度を明示し、変化を誇張しません。
• 原則: 二重軸の調整で関係があるように見せず、別々の図や尺度を揃えた比較を検討します。時間・年齢などの自然な順序と、値による順位を使い分けます。
• 原則: 実績と予測は線種や注記でも識別し、解釈に必要な目標・基準・不確実性を示します。

図表固有の禁止事項

• 禁止: 数値、単位、期間、母数、軸の尺度を、元データと照合せず実測値として示しません。
• 禁止: 凡例や色だけに識別を依存させ、白黒・色覚差で比較対象を失う図表を配布しません。
• 禁止: 軸の省略、切断、面積・体積の誇張で、値の差を実際と異なる印象にしません。

図表の文字寸法

6.4.1 視覚表現の選択と原稿化

この節以降は第6.4節の規則を具体化する設計手引きです。列挙した形式をすべて使う義務はありません。適用条件を満たす候補を比較し、読者に必要な理解を最も少ない推論で届けるものを選びます。型の多さ、画像の枚数、文字面積率は品質の代わりになりません。

言いたいことを視覚の仕事へ変える

選択の六つの確認

1. 読者と利用場面：投影を見る経営層、精読する専門家、操作中の利用者では、必要な深さと読む時間が異なる。
2. 情報の性質：数量、分類、順序、時間、地理、包含、関係、場面を区別する。数値がないものに数量の見かけを与えない。
3. 読み取る作業：順位、差、傾向、探索、照合、理解、判断のどれを助けるかを決める。
4. 比較対象と基準：同じ期間・母数・単位かを先に確認する。デザインで比較不能を隠さない。
5. 誤読と欠落：各候補が何を隠し、どの関係を過剰に示すかを比較する。
6. 出力条件：投影・紙・スマートフォン・PDFで再現できるか。Hoverやアニメーションが消えても意味が残るか。

制作前原稿の記入単位

この記録と第12章の原稿・監査記録を接続します。原稿を長くすることが目的ではなく、制作時に意味・データ・構造を再発明させないことが目的です。

参考：Datawrapperの選択ガイド。問いから表現を選ぶ考え方を参照し、上の業務図・原稿仕様はLiberka向けに整理しています。

本文を書く前の視覚設計

1. 全体の論理と各ページの問いを短く決める。長文の完成原稿を先に作らない。
2. 問いを比較・構成・順序・範囲・操作・場面・根拠などの読取り作業にする。同時に主要な視覚候補を検索する。
3. 候補の型と、要件から組み立てる案を比べる。主図が何を説明し、アイコン・実画面・画像がどこを助けるかを決める。
4. 図が引き受ける説明を列挙し、その文を本文へ重ねて置かない。残す本文は図だけでは分からない条件・留保を中心にし、話者ノートや文書の詳細節と分ける。
5. 主図の順序・配置・実ラベル・データ・素材を原稿として確定する。図を隠した場合に何が理解できなくなるか、図だけから意図した答えが読めるかを監査する。
6. 全体を一覧にして同じ形式の連続や装飾偏重を検討し、代表ページを試作する。試作の修正は原稿へ戻す。

文書では一段落ごとに無理に図を付けず、節の説明責務を単位に判断します。学術的な論証、正確な契約条件、引用の精読などは文章を主とする理由になります。スライドでは文章を既定にせず、まず視覚へ移せる部分を検討します。アイコン・生成画像も用途を記録し、必要な場面は個別に準備します。採用しない素材に生成を要求しません。

6.4.2 大小・順位・差分・目標の比較

以下は状況別の候補です。同じデータでも「順位」と「改善幅」では適切な並びや図が変わります。

並び順はメッセージの一部

順序が本質の時間・年齢・評価尺度は順序を保持します。純粋な大小比較なら値順が候補です。前後ページを照合する場合は同じ対象順を保つ方が比較しやすいことがあります。値順の変更で同じ対象の場所が移る場合は、その負担を評価します。

「最重要列を左端」は一律の規則ではありません。比較対象を識別する名称列を左に置き、その次に判断の主軸を置く方が、名称と評価の往復が短くなる場合があります。

架空データによる設計例

案件A・B・Cの確認時間が旧方式12・8・10分、新方式8・7・6分という説明用データを考えます。順位だけを見る横棒より、同一案件の変化を問う場合は行ごとのダンベルが適します。横軸0〜12分、縦軸A・B・C、旧方式は白抜き点、新方式は塗り点、端点に値を記します。差は−4・−1・−4分。実験条件が不明なので「導入で短縮した」とは結論しません。

参考：ONSの並び順、軸と補助線。形式ごとの原稿仕様はLiberkaの設計手引きです。

自作の構成例

この図は形式の理解を助ける自作の架空例です。実製品の仕様や導入効果の証拠ではありません。完成資料では対象媒体のtokenと原稿の実データを適用します。

6.4.3 推移・期間・工程・繰り返し

時間の条件を先に定義する

「月次」が月末時点か月内合計か、累積か当月分か、暦年か年度かを原稿で決めます。累積線の上昇だけで成長率の上昇を主張しません。月の日数差や稼働日数差が影響する場合は、総量と一日当たりを使い分けます。

移動平均は窓幅と端点処理を記し、元系列から何を平滑化したか説明します。都合のよい開始日、季節の違う期間、制度変更前後の定義差を確認します。予測値には前提・作成時点を添え、未来の事実として描きません。

工程図と状態図の区別

工程図は「作業をどう進めるか」、状態図は「対象がいま何で、何が起きると変わるか」です。申請→審査→承認は活動列か状態列かを先に決めます。待機・差戻し・中止が読者の判断に関係するなら正常経路だけで完結させません。

参考：ONSの小分割図、不確実性の表示。工程表の運用仕様はLiberkaの整理です。

自作の構成例

この図は形式の理解を助ける自作の架空例です。実製品の仕様や導入効果の証拠ではありません。完成資料では対象媒体のtokenと原稿の実データを適用します。

6.4.4 分布・関連・不確実性

集計で消えるものを確認する

平均だけで群の差を説明する前に、中央値、ばらつき、標本数、外れ値を確認します。群を混ぜた傾向と群内の傾向は一致しないことがあります。割合なら分子・分母、重み付き平均なら重み、回答者ベースなら非回答の扱いを記録します。

標準偏差は観測値のばらつき、標準誤差は推定量の標本変動を扱います。信頼区間と予測区間も別物です。区間の意味が未確認なら、見た目を整えるために帯や誤差棒を追加しません。頻度論の95%信頼区間を「確定したこの区間に真値が95%の確率で入る」と無条件に説明しないなど、採用した統計的定義に沿って記述します。

探索用と説明用

探索段階は散布行列や多数の分布で仮説を探せます。説明段階は読者の問いに関係する図を選びます。ただし結論に都合の悪いデータや条件を隠す意味ではありません。詳細・反証・方法へ辿れる構造を残します。

参考：NISTの信頼区間、NISTの箱ひげ図、NISTの可視化手法一覧、Data to Vizの注意点。

6.4.5 構成比・階層・地理・流量

全体の定義

複数回答を足して100%にした円グラフ、重複集合を排他的な内訳として描く図、赤字・負値を面積へ写す図は、情報構造を先に見直します。「その他」に含める対象と割合を説明し、重要な少数項目をまとめて消さないよう確認します。

割合を比較するときは、全体が10人と1万人でも同じ100%になることを意識します。「率が高い」と「人数が多い」は別の問いです。地図でも地域人口当たりと総数を選び分け、行政区域の変更や地域単位の違いを確認します。

参考：ONSの地図、Datawrapperの図種選択。特殊な形式の採用は読者が解釈できる場合に限るという編集判断を加えています。

自作の構成例

この図は形式の理解を助ける自作の架空例です。実製品の仕様や導入効果の証拠ではありません。完成資料では対象媒体のtokenと原稿の実データを適用します。

6.4.6 関係・構造・業務・体験の図解

数量がなくても図解はできます。ただし位置・長さ・面積が量を示すように見える場合は「概念図」「模式図」と用途を示します。箱と矢印を並べる前に、関係が順序・依存・因果・包含・接続のどれかを定義します。

矢印・囲い・余白の文法

矢印の凡例を増やしすぎるより、異なる関係を別図に分けます。実線と破線を使うなら意味を一つずつ決めます。距離・中央配置・大きさも重要度や近さを暗示するため、根拠のない優劣を作らないよう確認します。交差線を減らしても、実際にある関係を削除して単純化しません。

架空の「閲覧範囲」を図解する例

「本人は自分の記録、管理者は共有された記録を見られる」を人物アイコン二つで説明すると範囲が分かりません。本人／管理者を行、自分の未共有／他者の未共有／共有済みを列にした権限表が候補です。「共有した瞬間に見える範囲が変わる」が論点なら、状態遷移と小さな権限表を組み合わせます。どちらの場合も実製品の権限仕様を確認してから確定します。

参考：NN/gのジャーニー、サービスブループリント。その他はLiberka向けの図解分類・設計観点です。UML・BPMN準拠と名乗る場合は、別途その標準の記法を確認します。

自作の構成例

この図は形式の理解を助ける自作の架空例です。実製品の仕様や導入効果の証拠ではありません。完成資料では対象媒体のtokenと原稿の実データを適用します。

6.4.7 表・マトリクスと判断の設計

表はグラフの代替品ではありません。正確な値の参照、異種の条件の照合、実務上の採否を支える役割があります。文章をセルに詰めただけの表は、比較軸が揃っているか見直します。

表の設計順

1. 読者が最初に探すものを行見出しまたは列見出しにする。
2. 同じ粒度の評価軸に揃え、同じ条件で比較できるか確認する。
3. 判断の主要軸を名称の近くへ置き、詳細・注釈・出典の場所を決める。
4. 数量、二値、段階評価、自由記述を区別し、それぞれの整列と表記を選ぶ。
5. 比較対象が増えた場合の分割・固定見出し・繰り返し見出しを設計する。

セルの意味を固定する

ゼロは測定された0、欠測は値が得られない状態、対象外は定義上適用されない状態です。空欄やダッシュ一つで兼用しません。丸・三角・バツの意味も「優劣」なのか「可否」なのかを明示します。主観的評価には評価者・根拠・評価時点を接続します。

罫線と読みやすさ

罫線は行列の対応を助ける分だけ使い、全セルの強い囲いを避けます。行のまとまりは余白や控えめな背景でも示せます。HTML表は見出しセルとデータセルの対応を持たせます。PDFでは見出しの繰返し、行の分断、注記の離脱を確認します。表の罫線は、禁止されている装飾的なborder-leftとは役割を区別します。

参考：W3Cの表のアクセシビリティ。業務上の評価軸・採否の扱いはLiberkaの編集方針です。

自作の構成例

この図は形式の理解を助ける自作の架空例です。実製品の仕様や導入効果の証拠ではありません。完成資料では対象媒体のtokenと原稿の実データを適用します。

6.4.8 アイコン・写真・イラスト・生成画像・実画面

視覚素材の役割を分ける

生成画像の指示は「きれいな画像」で終えない

場面の主体、動作、対象、場所、視点、画角、主役の位置、文字領域、光と質感、ブランドとの整合、避けたい描写を指定します。別ページに別の場面が必要なら、ページごとの指示で複数回生成・選定します。同じ画像の切抜き・色替えで異なる場面を埋める運用は、6.2・6.3の素材規則に照らして監査します。

採用前に、意味、余計な文字・ロゴ、不自然な物体・接続、人物の表現、視線と画角、必要解像度、誤認のおそれを確認します。生成画像は背景を埋める義務ではありません。表・グラフで説明すべき箇所を画像へ置き換えず、場面理解を助ける場所で積極的に採用します。

アイコンの使い方

同じ意味に同じアイコンを使い、異なる意味に同じ記号を流用しないよう確認します。指定ライブラリとブランド規則は第4章・媒体別規範を参照します。アイコンを全廃するのでも、見出しすべてに付けるのでもなく、識別が速くなる箇所で採用します。図の節点をアイコン化しても、節点間の関係を線・配置・ラベルで設計する仕事は残ります。

切り抜きと注釈

実画面は読ませる範囲まで拡大し、必要なら全体の小図と詳細を対応番号で接続します。装飾用デバイス枠で実画面を小さくしません。注釈は対象の近くに置き、同時に読む説明と画像を離さないよう確認します。写真のトリミングで状況や証拠の意味が変わる場合は、原画像との比較へ戻ります。

参考：NN/gのアイコン理解、W3Cの複雑な画像。生成回数・素材の原稿への接続はLiberka固有の制作方針です。

再利用する視覚構成

以下は実在の実績や顧客発言を作るための型ではなく、確認済み素材を組版するための型です。

端末外観は質感のある実機モックアップを選びます。配布物には利用・再配布条件を確認した素材、または生成素材を用います。同梱のV73は生成したノートPC・スマートフォン・タブレットの透過画像であり、実機写真・メーカー公式素材・特定機種の正確な再現ではありません。画面は独立したassetをHTMLで背面に配置し、カメラやベゼルを前面に保ちます。生成素材である旨を表示し、端末外側の透過を維持します。特定機種の寸法や対応を証明する用途には、確認済みの実機素材を別途使います。画面を枠へ直接はめ込む方式を標準候補とし、クロマキーは既存の写真・動画素材に必要な場合に使います。画面assetの出典・版・状態・掲載可能性は別途確認します。月桂冠・コメントの出典欄が埋まっていても、内容の真偽は自動保証されません。

操作・対応・指標を大きく見せる

6.4.9 視覚の文法と媒体別の仕上げ

位置・長さ・面積・色・形

位置と長さを共通基準へ揃えると、差を直接比較できます。面積・角度・色の濃さは精密な数値読取りに負担があるため、概観の目的や数値ラベルと組み合わせます。一つの変数に複数の視覚属性を使う場合も、矛盾した意味を与えないよう確認します。

色は強調だけでなく、カテゴリ、大小、基準からの差、状態も表せます。「色は強調時だけ」という一律の規則にはしません。意味のない色分けを減らし、色が担う役割を限定します。

ブランド色を全系列や全背景へ広げる必要はありません。情報を読む領域の可読性を守り、データの意味とブランドの役割を分けます。白地も背景演出も媒体とページの役割に合わせて選びます。同じ緑系の背景と文字で層を埋めず、実寸で階層と区別を確認します。

視線と余白

まずタイトルから主図へ、主図から必要な注記へ辿れる配置を設計します。凡例を往復するより直接ラベルが適する場面があります。ただし密集して重なる場合は、配置・図の分割・表示対象を見直します。余白は関係のまとまりを示すために使い、空間を埋めるための枠・アイコン・画像を追加しません。

媒体ごとの変換

媒体tokenの文字寸法を適用し、スライドの大きな主図をそのまま文書へ縮小しません。文書の詳細表を投影用へ押し込むこともしません。HTMLからPDFに変換できても、表の見出し関係・読み順・代替説明がそのまま維持されるとは限らないため、最終PDFで確認します。

単調さと一貫性を混同しない

同じ主体、同じ指標、同じ状態の表現は揃えます。一方、大小・権限・体験という異なる問いをすべて「三つのカード」で表す必要はありません。ページを並べて見たときの強弱は、情報の役割と根拠の違いから生みます。見た目を変えるためだけの特殊グラフは選びません。

参考：Datawrapperの色尺度、フェンリルのブランディング支援。後者はブランドと体験の一貫性の参考であり、図表の統計的正確性の根拠やフェンリル社内の制作規則として扱いません。

自作の構成例

この図は形式の理解を助ける自作の架空例です。実製品の仕様や導入効果の証拠ではありません。完成資料では対象媒体のtokenと原稿の実データを適用します。

背景と内容面の合成

模様背景ではタイトル・本文・表・フッターを透過とする構成を基本候補にします。領域全体の白い塗りで背景を隠す処理を自動挿入せず、模様の濃度や位置を調整して可読性を確保します。写真背景などで文字の判読性が足りない場合は、文字の領域だけに読み取り面を置く案と、写真を別領域へ分ける案を比較します。

背景候補は無地、淡色、ドット、グリッド、斜線、周縁のリング、上下の淡い帯、画像を揃えます。背景は図表の数量・分類の符号と競合させず、印刷・狭幅でも選定結果を確認します。透過とはページ自体の透明化ではなく、ページ上の不要な白い面をなくすことです。

文字の削減は、本文と図の重複を取り除き、対象の識別を指定アイコン、境界を包含、役割を表、階層をピラミッド、実際の操作を画面へ移すことで行います。必要な根拠・単位・条件は残し、アイコン数や図の個数だけで品質を判定しません。

6.4.10 視覚監査と検査可能性

本節は第12章の受け入れ記録を視覚表現へ適用する索引です。新しい合格点を作らず、既存の必須・禁止、対象要件、採用形式の条件へ接続します。自動化候補は実装済みの機能を意味しません。

監査の問い

1. タイトルを隠しても、何を比べた図か分かるか。
2. 主図を隠すと、理解に必要な情報が失われるか。失われないなら装飾か重複の可能性はないか。
3. 色をなくしても対象・関係・重要な差を読めるか。
4. 大小・距離・矢印・包含から、根拠にない意味を読み取らせていないか。
5. 例外・欠測・未確認・不確実性が結論を変えるのに消えていないか。
6. 読者に必要な比較を頭の中の計算やページ往復へ丸投げしていないか。
7. アイコンで説明できない関係をアイコンに任せていないか。
8. 本文を削った結果、単位・条件・定義・出典まで失っていないか。
9. ページを俯瞰したとき、内容の違いが図の構造に表れているか。
10. 実際の配布PDF・表示幅で、ラベルと主図と注記を読めるか。

典型的な差戻し

「レビューを30回」は30件のチェックボックスではありません。明示された巡数の対象版・指摘・修正・再確認を残し、同じコマンドの再実行を内容監査の一巡として数えません。回数を満たしても未確認の必須条件は未確認です。

7. Webコンポーネントの正式語彙

適用層: 媒体別標準（Web）

この章はWebコンポーネントの目的・状態・操作と、画面構造・状態遷移・作業の流れの仕様を所有します。単体部品の見本はComponents Library、画面と流れの見本はLayouts & Flowsで確認します。

7.1 画面骨格

見本: App Shell / Sidebar / Mobile Navigation

• 必須: Main Contentは、固定Sidebarの幅と固定Top Barの高さをApp Shellのtokenから正確に差し引き、内容を背後へ隠しません。アンカー移動、フォーカス移動、エラー位置への移動にも同じ上部補正を適用します。
• 原則: Desktop SidebarとApp Top Barはviewportへ固定し、ページ固有のMain Contentだけをdocument scrollで移動させます。Page全体を独自の全画面Scroll Containerへ入れません。
• 原則: 高さが不足する場合はDesktop SidebarのNavigation部分だけをスクロール可能にし、製品名、現在地、アカウント操作を同時に失いません。
• 原則: モバイルではDesktop Sidebarを隠し、固定Mobile Top BarとMobile Navigation Panelへ再構成します。Main ContentはTop Barとsafe-areaの高さを補正し、document scrollを維持します。
• 許容: Table、ログ、チャットなど、境界と目的が明確な領域だけに局所的なScroll Containerを使えます。
• 禁止: bodyとMain Contentの二重縦スクロールを作りません。

7.2 Card

見本: Card · Avatar · Separator

Cardは四隅が角丸になった、情報の一区切りを示す構造です。

• 原則: 全周1 px相当の境界で外部と区切ります。
• 原則: 見出しは通常の文字階層で示し、Label形状で囲みません。
• 原則: クリック可能に見せるHover、pointer、浮上、拡大をCard自体へ付けません。
• 原則: 操作はCard内部のButtonまたはLinkへ置きます。
• 原則: Card内Cardは、独立した情報境界が必要で、余白やSectionでは表現できない場合に限ります。
• 原則: 同じ視点で比較するCard群は、各Cardの最小可読幅を保てる間は複数列で一覧できるようにします。ブレークポイントを越えただけで早く一列へ落としません。
• 禁止: Card全体を選択、モード切替え、表示切替え、ページ遷移に使いません。
• 禁止: Cardの内側へさらに緑系の背景面を重ねません。Card内の文字、Link、Label、状態色と緑の主張が競合する場合は、余白、Divider、見出しで区切ります。
• 禁止: Table、ログ、チャットのように領域内スクロール自体が機能でない限り、Card本体は内容の高さまで広げ、内容を切る縦スクロールを作りません。
• 禁止: Cardの一辺だけに色線を置きません。

AvatarとSeparator

Avatarは人または主体を素早く識別する補助情報です。Separatorは、見出しや余白だけでは関係を説明できない場合に、内容の区切りを明示します。

• 必須: Avatarだけで本人確認、権限、在席、選択状態を伝えず、必要な名前と状態を文字でも示します。
• 必須: 意味のあるSeparatorはhrなど適切な構造を使い、装飾だけの線は読み上げから除外します。
• 原則: Avatar画像がない場合は、安定した文字のfallbackまたは共通Symbolを使います。
• 原則: Separatorを追加する前に、見出し、余白、整列で区切りを表現できないか確認します。
• 許容: Avatarは人物、組織、製品、AIなど、発話者や所有者を反復して識別する場面に使えます。
• 禁止: 出所を確認できない人物写真、絵文字、ランダムな背景色をAvatarへ使いません。
• 禁止: 一覧のすべての行やCard内部を線で細分化し、情報のまとまりを線だけに依存させません。

7.3 Button

見本: Button

Buttonは、ユーザーの操作によって同じ画面内の状態またはデータを変更する部品です。

• 必須: 破壊的Buttonは赤系で示します。
• 原則: 色と塗りで周囲から区別し、Hover時は色を変えます。
• 原則: マウスカーソルはpointerとします。
• 原則: Dialog、Popover、Menuを開くButtonには矢印を付けません。
• 原則: Button外観で画面遷移するNavigation Buttonには末尾に→を付けます。
• 原則: Disabledは理由が分からない状態を作らず、必要に応じて説明を近くに置きます。
• 原則: Hover時に位置、寸法、形を変えません。
• 許容: 形状は、用途に応じて角丸四角またはピルを使えます。

Liberka共通のBrand Primary #009EA1は、通常情報と選択を識別します。ただし、通常サイズのButton Labelに月白#F6F7F8を重ねると4.5:1を満たさないため、Primary Action Buttonは--button-primary-action-background（#007477）、Hover時は--button-primary-action-background-hover（#005456）、文字は--button-primary-action-color（月白#F6F7F8）を使います。#009EA1を面に使う場合はInkなど4.5:1以上となる文字色と組み合わせ、状態ごとに背景色と文字色を一組で定義します。

--button-square-backgroundは正式tokenではありません。consumer repositoryに互換目的で残っていても、新規または変更する通常Action Buttonの根拠として使用せず、Primary Action Tokenへ移行します。

濃緑のPrimaryは、その面の中心操作に限定します。複数の操作を同格のPrimaryにせず、保存、更新、移動、表示のすべてを濃緑で競合させません。DangerとWarningにはPrimaryの配色を流用しません。

補助操作は--button-secondary-background、--button-secondary-colorと対応するHover tokenを使い、画面固有の淡色と文字色を追加しません。補助操作の選択中はPrimaryへ切り替え、aria-pressedと近接する状態文を併用します。

7.4 Label

見本: Label

Labelは、件数、状態、種類など数語の情報を伝える非操作要素です。

• 原則: 原則一行、数語に限定します。
• 原則: 色だけで状態を伝えません。
• 禁止: Hoverで色を変えず、クリックへ反応せず、pointerを使いません。
• 禁止: CardまたはSectionの見出しとして使いません。

7.5 Tabs

見本: Sidebar Navigation Link · Navigation Trigger / Hamburger Button · Tabs · Breadcrumbs · Pagination · Toolbar · Navigation Menu

Tabsは、同じ文脈の中で表示面を切り替える操作部品です。

• 必須: 選択中は下線、濃い文字、必要に応じた件数Labelで示します。
• 必須: Tabsを選ぶと、対応するtabpanelへ表示内容そのものが切り替わります。選択前後で同じ内容が残り、表示方法や設定値だけが変わる場合はToggle Groupを使います。
• 原則: Hover時は背景色を変えます。
• 原則: tablist、tab、tabpanelの関係を持たせます。
• 原則: Arrow keysで同じTablist内を移動し、HomeとEndを支援します。
• 原則: CardやLabelの外観でTabsを代用しません。
• 禁止: ページ間ナビゲーション、単独の絞込み、実行操作へ流用しません。
• 禁止: 保存、整列、表示密度など、選択した時点で同じ対象の設定を変更する操作へ流用しません。

BreadcrumbsとPagination

• 必須: Breadcrumbsは現在地を末尾に置き、Navigationとして名前を付けます。現在地はLinkにしません。
• 必須: Paginationは現在のページ、全体または前後関係を文字で示し、各Linkの目的をアクセシブルネームでも区別します。
• 原則: Breadcrumbsは利用者が上位階層へ戻る必要がある場合に使い、単なる閲覧履歴にはしません。
• 原則: Paginationは結果の順序が安定し、分割によって比較や作業の継続を妨げない場合に使います。
• 許容: 狭い画面では中間のBreadcrumbを省略できますが、起点、親、現在地の関係を失いません。
• 禁止: BreadcrumbsをPage Titleの代わりに使いません。
• 禁止: 無限scrollだけを唯一の移動手段にし、現在位置や終端を分からなくしません。

ToolbarとNavigation Menu

• 必須: Toolbarは同じ対象へ作用する操作だけをまとめ、名前とキーボード上の移動方法を持たせます。
• 必須: Navigation Menuは移動先を扱い、保存や削除など同じ画面の状態を変える操作と混在させません。
• 原則: 頻繁に使う操作を先に置き、低頻度の操作は一つのMenuへまとめます。
• 原則: 狭い画面ではToolbarを折り返すかMenuへ再構成し、操作Labelを途中で切りません。
• 許容: IconだけのToolbar Buttonは、繰り返し使う一般的な操作で、アクセシブルネームとTooltipを持つ場合に使えます。
• 禁止: Toolbarを見出し、検索、Navigation、状態表示の雑多な置き場にしません。
• 禁止: Hoverだけで開くNavigation Menuへ主要導線を依存させません。

7.6 Link

見本: Link

Linkは別のURLまたはページへ移動します。

• 原則: 本文Linkは下線または文脈上明確なLink表現を持ちます。
• 原則: Button外観にする場合も、実装上はLinkの意味を保ちます。
• 原則: 新しいタブを開く場合は、必要に応じて事前に伝えます。
• 原則: ここをクリックではなく遷移先を説明する文言を使います。

7.7 Form Controls

見本: Text Field · Search Field · Toggle Group · Checkbox · Radio Group · Select · Combobox / Autocomplete · Switch · Slider · Number Field · Date Field / Date Picker · Password Field · File Upload · Character Count

• 必須: Label、Control、Help、Errorを意味的に関連付けます。
• 必須: 必須と任意をフォーム全体で一貫して示します。
• 必須: 入力値を失敗後も可能な限り保持します。
• 必須: Checkbox、Radio、Select、Slider、Number、Date、Fileを含むControlは、DefaultだけでなくHover、Focus、Selected、Disabled、Loading、Errorなど必要な状態の外観をLiberka側で定義します。
• 必須: SelectとComboboxの選択肢は、HoverとFocus Visibleで操作対象だと分かる面を作り、文字とのコントラストを保ちます。Liberka共通のHover面にはBrand Soft #DCEFE7とBrand Primary Strong #005456を組み合わせ、Defaultの外観と位置を変えません。Brand Primary #009EA1の面を選択肢のHoverへ使いません。
• 原則: PlaceholderだけでLabelを代用しません。
• 原則: エラーは対象の近くに置き、原因と修正方法を説明します。
• 原則: 選択肢が少なく比較が重要ならRadio、多い場合はSelect、独立した二値設定にはSwitchを使います。
• 原則: Selectの既定値は、利用者が最初に比較すべき最上位の範囲を選びます。ワークスペースと個別チームが並ぶ場合はワークスペース、全社と部門が並ぶ場合は全社を既定とし、下位項目を一覧の先頭という理由だけで選びません。権限外の範囲は候補にも既定値にも含めません。
• 原則: 日付入力は保存値やAPI値にISO形式を使用してよいが、利用者に見えるControl面は20XX年M月D日で表示します。ブラウザやOSによって見え方が変わるネイティブ日付文字列を、そのまま表示面にしません。
• 禁止: Components Libraryの参照実例で、Browser既定のCheckbox、Radio、Select矢印、Range track、Number spinner、Date表示、File選択面を、そのままLiberkaの完成外観として提示しません。

Search Field

Search Fieldは、入力内容によって同じ情報集合を絞り込む一行入力です。短い入力であることと、検索対象が明らかであることを前提に、通常のText Fieldより細身にできます。

• 必須: 一行のSearch Fieldは、左右端が円になる細身のピル形、透明な背景、Liberkaの濃緑による1 CSS pxの全周境界を使います。
• 必須: 入力面の先頭へ、検索であると分かる虫眼鏡Iconを置きます。Iconは装飾として読み上げから除外し、入力自体にアクセシブルネームを設定します。
• 必須: Placeholderは「ガイドライン内を検索」「メンバーを検索」のように、検索対象を含む自然な表現にします。
• 必須: Focus Visibleでは外側へ別のoutlineやshadowを追加せず、同じ境界を内側へ2 CSS pxに強調します。部品の外寸と周囲の配置を変えません。
• 必須: Focus表示は背景に対して認識できる面積とコントラストを持つことを、キーボード操作とforced-colorsで検証します。
• 禁止: 「検索語」のように利用者の行動や対象を説明しない内部的な語だけをLabelまたはPlaceholderに使いません。
• 禁止: Placeholderだけでアクセシブルネームを代用しません。視覚的なLabelを省略する場合も、aria-labelまたは同等の方法で名前を持たせます。

良い例: 虫眼鏡と「ガイドライン内を検索」が一つの入力面に収まり、Tabで移動すると同じ濃緑の境界が内側へ強調されます。

悪い例: 大きな空の入力面へ「検索語」とだけ表示し、Focus時に外側へ二重の枠やglowを追加します。

複数行のText FieldとChat Composer

• 必須: 一行のChat Composerでは、入力文字、caret、Placeholderを44 CSS px以上の入力面の垂直方向中央へ揃えます。行高と上下paddingを一組で定義し、上寄せまたは下寄せにしません。
• 必須: 複数行入力は横幅を保ったまま高さを増やし、一定半径の角丸矩形へ切り替えます。
• 必須: 文字、caret、Placeholder、Icon、送信Buttonのための内側余白を確保し、どの状態でも全周境界の外へはみ出さないようにします。
• 必須: 200%文字拡大、長い日本語、五行以上の入力、ソフトキーボード表示で、入力内容と送信操作を検証します。
• 禁止: 高さに比例して角丸を大きくし、複数行入力を巨大なピル形にしません。

Checkbox、Radio Group、Toggle Group

• 必須: Checkboxは複数の独立した選択、Radio Groupは一つだけ選ぶ相互排他的な選択に使います。
• 必須: Groupには質問または目的を示す名前を付け、各選択肢のLabel全体を操作できるようにします。
• 必須: checked、unchecked、mixed、selectedを色だけで区別せず、Controlの形とアクセシブルな状態を一致させます。
• 原則: Toggle Groupは、同じ内容を残したまま表示密度、整列、書式などの設定を変える短い選択肢に使い、選択数が一つか複数かを明確にします。各Buttonはaria-pressedなどで現在値を示し、tabpanelを持ちません。
• 許容: 選択肢が短く、同時比較が重要な場合は、Button外観のToggle Groupを使えます。
• 禁止: 同意、重要な確認、料金の発生を初期選択済みにしません。
• 禁止: Card全体をCheckbox、Radio、Toggleの代わりにしません。
• 禁止: Toggle Groupで別の内容面、状態見本、Sectionを切り替えません。その関係にはTabsを使います。

SelectとCombobox

• 必須: Selectは用意された候補から選ぶ場合、Comboboxは入力による候補の絞込みまたは任意値の入力が必要な場合に使います。
• 必須: Comboboxは入力、Popup、候補、選択値の関係をアクセシブルに実装し、読み込み中、0件、Errorを文字で示します。
• 必須: 候補を開いても入力値とFocusを失わず、Escapeで候補を閉じた後も入力へ戻ります。
• 原則: 候補が少なく比較が重要な場合はRadio Groupを優先します。
• 許容: 候補が多く、名前を思い出しながら探す場合はAutocompleteを使えます。
• 禁止: Search Fieldを選択Controlとして流用し、選択の確定状態を曖昧にしません。
• 禁止: Placeholderだけで既定値、未選択、Labelを兼ねません。

SwitchとSlider

• 必須: Switchは操作直後に反映される独立した二値設定に使い、現在がOnかOffかを文字でも理解できるようにします。
• 必須: Sliderは最小値、最大値、現在値、単位を示し、Keyboardと直接入力でも同じ値へ到達できるようにします。
• 原則: 正確な値が重要な場合はSliderだけにせずNumber Fieldを併設します。
• 許容: 連続量を相対的に調整し、途中値を見ながら決める場合にSliderを使えます。
• 禁止: 保存が必要な設定をSwitchだけで即時反映したように見せません。
• 禁止: 二つ以上の状態や取り消せない操作にSwitchを使いません。

Number、Date、Password、File、Character Count

• 必須: Number Fieldは許容範囲、刻み、単位、Error条件を入力の近くへ示します。
• 必須: Date Fieldは利用者に見える値を20XX年M月D日で示し、Calendarを使えない人にも文字入力または同等の経路を用意します。
• 必須: Password Fieldは内容を表示・非表示にする操作を用意する場合も、入力値、Focus、caretを保持します。
• 必須: File Uploadは対応形式、上限、選択済みFile、進行、成功、失敗、取消し可否を文字で示します。
• 必須: Character Countは上限が判断へ影響する位置に現在値と上限を示し、超過理由を色だけに依存させません。
• 原則: Number、Date、Fileはブラウザ固有UIだけへ依存せず、対象環境で表示とKeyboard操作を確認します。
• 許容: Drag and DropによるFile選択は、通常のFile選択Buttonを残す場合に追加できます。
• 禁止: Passwordの値を初期状態で表示しません。
• 禁止: File選択面全体をButtonに見せながら、Keyboardや読み上げでは操作対象を特定できない構造にしません。

7.8 Dialog、Popover、Menu、Tooltip

見本: Dialog · Popover / Menu / Tooltip

• 原則: 製品内でユーザーが見る確認、選択、入力は、製品のデザインに統一したDialogを使います。
• 原則: 初期フォーカス、フォーカストラップ、Escape、フォーカス復帰、背後の操作抑止を持ちます。
• 原則: 長文や文字拡大により初期Focusが冒頭の説明を画面外へ送る場合は、先頭の見出しを読み始める位置にします。短い入力では最初の入力欄へのFocusを保ち、送信や削除を自動実行しません。
• 原則: 破壊的操作は、対象と影響を示したうえで赤い実行Buttonによる確認を必要とします。
• 原則: 警告はオレンジを使い、破壊と混同しません。
• 原則: Dialogの上へDialogを重ねず、同じ面のステップ切替えを優先します。
• 原則: PopoverとMenuは起点との関係を保ち、画面外へはみ出しません。
• 禁止: Tooltipへ重要情報、エラー、操作を置きません。

7.9 Progress、Loading、Empty State

見本: Progress / Spinner · Alert / Notification Banner · Toast · Error Summary

• 必須: Loading中は、最終表示で使うPage Header、Tabs、Toolbar、Card、List、Table、Chart、入力領域を先に配置し、そのデータ領域内へ読込状態を示します。
• 必須: 段階処理は現在地点、完了済み、残り、失敗地点を示します。
• 原則: 読込前後で、外枠の幅と高さ、見出し、Tabsの選択位置と外観、Toolbar、入力、文字体系を同じにします。利用可能になったデータだけを、予約済みの領域へ表示します。
• 原則: Page全体のLoading画面を、画面遷移や再取得のたびに必ず挟んではなりません。見出し、入力、取得済みデータなど用意できた内容は順に表示し、本当に未取得のデータ領域だけへLoading状態を置きます。見せるための最低表示時間を設けません。
• 原則: 同じ対象と期間を再取得するときは、表示済みの有効な内容を消さず、同じ骨格のまま更新状態を伝えます。対象、権限、ワークスペースを切り替え、旧内容が新しい選択の内容だと誤認される場合に限り、旧データを除いて新しい対象の骨格を表示します。
• 原則: 読込状態は、対象を表す文言、aria-busyまたはrole="status"、必要最小限の進捗表示で示します。Empty Stateを中央配置する領域では読込文も同じ基準で中央配置し、文言の切替えで視線位置を動かしません。
• 原則: Empty StateでもPage Header、Tabs、Toolbar、追加操作を必要に応じて残します。
• 原則: 終了時はProgressを消すだけでなく、成功または失敗を通知します。
• 禁止: 最終画面と無関係なSkeleton Cardや仮の図形を追加しません。汎用の大きなSkeleton面、実際の行数を示さない反復Placeholder、意味のない灰色の線を「骨格」と呼びません。
• 禁止: 読込中のTabや入力を一時的な配色、透明度、代替書体で示しません。操作不能であることはaria-busy、aria-disabled、状態文で伝え、完了時に外観を切り替えません。
• 禁止: Spinnerだけを大きな空白の中央へ置きません。

Alert、Toast、Error Summary

• 必須: Alertは種類だけでなく、起きたこと、影響、次にできることを本文で示します。
• 必須: Error SummaryはFormの先頭付近に置き、各Errorから該当Controlへ移動できるようにします。
• 必須: Toastを動的に表示する場合は、内容の緊急度に合うlive regionを使い、Focusを奪いません。
• 原則: ページ内で継続して参照する必要がある状態はAlert、短い完了通知はToastを使います。
• 原則: Toastは自動で消えても仕事の結果を再確認できる経路を残します。
• 許容: 利用者が行った軽微で復旧可能な操作は、取消し操作を持つToastで通知できます。
• 禁止: Error、費用、破壊的結果、公開範囲など重要な情報をToastだけで伝えません。
• 禁止: Alertを常設の装飾Cardや販促Bannerとして使いません。

7.10 List、Table、Tree、Chart

見本: List / Table · Calendar / Agenda · Mini Calendar · Tree

• 必須: List Row全体を疑似Buttonにせず、行内操作を明示します。
• 必須: ドラッグ操作には可視ハンドル、grab状態、キーボード代替、結果通知を用意します。
• 原則: 順序だけならList、行列比較ならTable、親子関係ならTreeを使います。
• 原則: Treeの階層はインデント、開閉、親子関係で示し、Card左縁の色線で示しません。
• 原則: Tableは見出し、並び順、単位、横スクロール範囲を明確にします。
• 原則: Chartは要約、説明、表形式の代替を持ちます。
• 禁止: Chartの表、凡例、詳細を展開しても、先に表示されているプロット領域を縮小または押しつぶしません。プロットの寸法を保ち、追加内容を下へ展開するか、所属する領域をスクロールさせます。

Mini Calendar

Mini Calendarは、ホームや概要欄で予定のある日を確認する、表示専用の小さな月表示です。

• 必須: 対象の年・月と曜日を示し、予定が一つ以上ある日だけ日付番号、予定がない日は「・」を中央揃えで表示します。数字は予定件数ではなく日付を意味します。
• 必須: 月曜から日曜の7列と日付順を保ち、月外の位置は空欄にします。実在する月初の曜日、月末、うるう年を反映します。
• 必須: 日付と予定有無を読み上げでも確認できる構造にし、数字とドットの意味を近くに明記します。予定0件では月の全日をドットで示し、予定がないことを文字でも伝えます。
• 必須: LoadingとErrorは対象月と表示領域を保ち、未確認であることを状態文で示します。取得できていない日を「予定なし」のドットとして表示しません。
• 原則: 日付セルは非操作とし、枠、Hover、pointer、Tab停止を追加しません。予定本文や選択操作が必要な場合はCalendar / AgendaまたはDate Fieldを使います。
• 許容: 予定の詳細を確認するLinkを、Mini Calendarの外側へ併設できます。
• 禁止: 今日や選択中という理由だけで、予定がない日に番号を表示しません。セル全体やカレンダー全体を疑似Buttonにしません。

Tree

• 必須: Tree itemは階層、展開状態、選択状態を構造として持ち、Arrow keys、Home、Endで移動できるようにします。
• 必須: 展開Buttonと項目の選択または移動を別の操作として認識できるようにします。
• 原則: 深い親子関係を同じ面で探索する必要がある場合にTreeを使います。
• 許容: 階層が浅く、展開を必要としない場合は通常のListや見出し構造を使えます。
• 禁止: インデントや色線だけで親子関係を表しません。
• 禁止: 一覧に階層があるという理由だけで、Mobileでも横幅を消費するTreeを維持しません。

7.11 Chat

見本: Chat Composer · Chat Bubble · Chat Message · Message Log

• 必須: 発話者別の面はAssistantにcolor.surface、Userにcolor.brandSoft、Systemにcolor.canvasを使い、発話者名と構造を併用します。

Chatは、継続する会話、質問、記録または支援を時系列で扱う領域です。会話が画面の中心目的である場合は、必要な現在地と状態を保ったうえで、残りのviewportを履歴と入力へ優先配分します。Chatの外側に別の中心目的がある場合は、画面全体をChat専用構成に置き換えません。

画面構成と履歴はLayouts & FlowsのChat画面仕様を参照します。

Messageと動的更新

• 必須: Message Logは視覚的かつアクセシブな名称を持ち、Messageを古い順からDOM上の読み順と一致させる。新着Messageはrole="log"、live region、または同等の方法で通知し、既存履歴全体を再度読み上げさせません。ストリーミング中は文字ごとでなく、意味のある単位または完了時にまとめて通知します。

• 必須: 利用者が末尾付近を読んでいる場合だけ新着へ自動追従し、過去を読んでいる場合は位置を保って、新着位置へ移動する操作を示します。

• 禁止: Messageの追加、生成中の更新、送信結果の通知でフォーカスを奪いません。

• 必須: Message Bubbleは全周境界とSurfaceで背景から区切り、基本形を角丸にします。

• 必須: AI、利用者、システムの通知、外部操作、承認待ちを、文言、読み上げ、構造の組合せで区別します。内部実装名を主要メッセージへ露出させず、アクセシブな発話者情報を保ったうえで、連続する同一発話者の名前、時刻、AvatarまたはLogoの反復は省略できます。

• 必須: Bubbleは長文、URL、改行、長い日本語、コード、構造化内容を必要に応じて折り返します。

• 許容: 発話者側の下角だけ半径を小さくして方向を補助できます。ただし、方向を形だけへ依存させません。

• 禁止: Tailとして別要素または疑似要素の三角形を継ぎ足しません。

• 禁止: Bubbleが横幅を越え、Message Log全体へ意図しない横スクロールを作る状態を許容しません。

Composerと送信

• 必須: ComposerはChat領域の下端へ固定またはsticky配置し、safe-areaとソフトキーボードを考慮します。Messageが増えても入力位置を見失わせず、Message Logを隠さない余白を確保します。
• 必須: Send Buttonは、送信可能、未入力、生成または送信中、失敗、文字数超過を判別できる状態を持ちます。処理中は重複送信を防ぎ、完了または失敗まで状態を示します。
• 必須: キーボード送信を提供する場合は、改行と送信の操作をComposerの近くへ明記します。日本語などのIME変換中にEnterを押しても送信せず、変換確定と送信を区別します。ショートカットを使えない環境でも、送信Buttonから同じ目的を達成できるようにします。
• 必須: 文字数制限がある場合は現在値と上限を示し、超過時は送信不能の理由を色だけでなく文言で示します。
• 必須: モバイルの入力文字は16 CSS px以上とし、Focus時の自動拡大を起こさない。Focusやソフトキーボード表示によってMessage Log全体が画面外へ移動したり、Composerがキーボードの背後へ隠れたりしないことを実機相当で確認します。
• 原則: 五行までは内容に応じて自動拡張し、それを超える場合は高さを固定して入力内部だけを縦スクロールさせます。利用者によるサイズ変更を無効にする場合は、200%の文字拡大で入力と送信を失いません。
• 原則: 送信Buttonは44×44 CSS px以上の操作対象を保ち、flexまたは狭幅で押しつぶしません。Iconだけの円形Buttonを使う場合は、視覚的かつアクセシブな名前から送信操作だと判別できるようにします。
• 許容: 一行時の入力面は左右端が円になるピル形状を使えます。複数行時は高さだけを上方向へ拡張し、ControlまたはSurfaceの一定半径へ切り替えます。高さに比例して半径を増やしません。

7.12 Accordion

見本: Accordion

Accordionは、同じページの補助的な内容を見出し単位で開閉する部品です。長い内容を短く見せるためではなく、利用者が必要な詳細を選んで読むために使います。

• 必須: 見出し全体を一つのButtonとし、見出しレベル、aria-expanded、操作対象との関係を保ちます。
• 必須: EnterまたはSpaceで開閉でき、Tab順序を視覚順序と一致させます。
• 必須: 開閉状態は矢印の向きだけでなく、アクセシブルな状態として伝えます。
• 許容: FAQ、任意の補足、章ごとに独立した設定など、閉じていても中心目的と重要な判断を失わない内容に使えます。
• 禁止: 警告、エラー、費用、公開範囲、取消し可否、主要操作、現在地を閉じたAccordionの中だけに置きません。
• 禁止: 連続して読む本文や、目次の階層を短く見せることだけを目的に使いません。
• 禁止: 閉じた内容へフォーカスを残しません。開閉によって読み手の現在位置を不必要に移動させません。

良い例: FAQの質問がButtonになり、回答を閉じても申込み条件と主要操作は常に読めます。

悪い例: ガイドラインの章をすべて閉じ、見出しだけでは規則の存在や重要度を判断できなくします。

7.13 共通コンポーネントの仕様一覧

見本: Components Library

ここまでの規則を、実装時に照合しやすい形でまとめます。この一覧にあるコンポーネントは製品固有ではなく、すべてのLiberka製品で共通です。製品別規則は色や文言の使い方を限定できますが、新しい意味や矛盾する状態を追加できません。

• 必須: IconだけのButtonにもアクセシブルネームを付け、重要操作は44×44 CSS px以上を目安にします。
• 必須: Dialogは初期Focus、Focus trap、Escape、起点へのFocus復帰、背後操作抑止を持ちます。
• 必須: MenuはArrow keysとEscape、起点へのFocus復帰を持ちます。非modal PopoverはFocusを閉じ込めません。
• 必須: Tableは正しいtable semanticsを使い、長文、0件、大量、領域内横scrollを確認します。
• 必須: Webの共通Componentは@liberka-schedia/ui-reactのReact exportを正本実装とし、Components、Layouts & Flows、skill、consumer repositoryは同じexportを参照します。
• 必須: Componentsの公開実例は正本React Component自体から生成し、見本専用の複製HTMLや別実装を表示しません。
• 必須: catalogはすべてのComponent IDをReact export、型、共通style、必要stateへ機械可読に結びます。
• 原則: 外部のDesign SystemやComponent Libraryは、操作モデル、状態、アクセシビリティの比較資料として調査します。採用元と確認日はcomponents/web/sources.jsonで追跡します。
• 原則: @liberka-schedia/ui-reactはNext.js固有APIへ依存せず、Reactを利用する各製品とNext.jsのServer・Client双方から利用できる境界を保ちます。
• 許容: Reactを利用できない媒体やruntimeでは、正本Componentの意味、DOM関係、状態、token、検証条件を保ったadapterを所有先で実装できます。
• 禁止: ReactまたはNext.jsのconsumer repositoryで、正本Componentと同じ意味の部品を製品固有Componentとして複製しません。
• 禁止: Buttonの色と形を自由な直積として選びません。意味役割がvariantを決めます。
• 禁止: Search Fieldを、項目数が多そうだという理由だけで追加しません。
• 禁止: 一般的な長文FormへChat Composerを流用しません。
• 禁止: Progressへ見せるための最低表示時間を設けません。
• 禁止: 外部LibraryのCSS、色、余白、命名、装飾を、そのLibraryが一般的であることだけを理由にLiberkaの正本へ持ち込みません。

7.14 共通の構成と流れ（Layouts & Flows）

見本: App Shell / Sidebar / Mobile Navigation · Form · Chat · Loading / Empty / Error · Confirmation / Destructive Action · Authentication · Overview / Dashboard · List / Detail · Search / Filter / Results · Settings · Multi-step Flow

Layoutは複数の共通コンポーネントを一つの画面構造へ組み合わせたもの、Flowは状態遷移を含む作業の流れです。どちらもComponentsと同じ媒体別標準ですが、探す粒度が異なるため、UI Libraryでは「Layouts & Flows」として分けます。

• 必須: LayoutとFlowは、Componentsで定義済みの意味、variant、state、token、アクセシビリティをそのまま再利用します。
• 必須: 参照例は、使用したComponentを機械可読な索引で明示し、単体例と複合例が同じ部品であることを検証できるようにします。
• 原則: Componentsでは一つの部品を比較し、Layouts & Flowsでは部品間の配置、状態の連鎖、Responsive時の再構成を確認します。
• 禁止: LayoutまたはFlowの都合で、既存Componentに似た別外観や別操作を局所的に作りません。必要なvariantは先にComponentの共通仕様へ追加します。

App Shell、Sidebar、Mobile Navigation

• 必須: Desktop SidebarとTop Barを固定する場合、Main Contentへ正確なinsetとanchor補正を与えます。
• 必須: 高さが不足するときはNavigation部分だけをscroll可能にし、製品名とaccount操作を同時に失いません。
• 必須: Mobileでは、一つのHamburger Buttonから検索とNavigationを含むPanelを開きます。
• 必須: Hamburger ButtonはNavigation Triggerの円形または角丸矩形variantを使い、App Shell専用の別Buttonとして作り直しません。
• 禁止: 同じ位置へ、役割を区別できない複数のHamburger Buttonを並べません。

Form

• 必須: 必須と任意の示し方をForm全体で統一します。
• 必須: 比較が重要な少数選択肢にはRadio、多数にはSelect、独立した二値設定にはSwitchを使います。
• 必須: 失敗後も入力値を保持し、最初のErrorへFocusを移すか、明確なError summary導線を提供します。
• 禁止: Disabledの外観だけで操作できない理由を隠しません。

Loading、Empty、Error

• 必須: 参照ギャラリーなどでLoading、Refreshing、Empty、Error、Successの表示面を比較する場合はTabsを使い、Toggle Groupや実行Buttonで状態見本を切り替えません。
• 必須: Loading中も最終画面の骨格を先に配置し、本当に未取得の領域だけへ状態を示します。
• 必須: 同じ対象の再取得では、有効な表示済み内容を消さず更新状態を伝えます。
• 必須: EmptyでもPage Header、Filter、追加操作など必要な骨格を残します。
• 必須: Errorでは原因、影響、再試行の安全性、代替手段を示します。
• 禁止: Loading完了時にTypography、Tabs、入力の外観を切り替えません。

確認と破壊的操作

• 必須: 破壊的操作は、対象、影響、復旧可否、赤い実行Buttonを示して確認します。
• 必須: Warningはオレンジ、通常確認はLiberka greenを使い、破壊と混同しません。
• 禁止: Dialogの上へDialogを重ねません。同じ面のstep切替を使います。

Chat画面

会話領域とナビゲーション

• 原則: モバイルでは、同じ位置へ複数のHamburger Buttonを並べない。App ShellのMobile Navigation Panelへ画面固有操作を統合するか、役割の異なる操作だと名称と外観から判別できる構成にします。
• 原則: 公開範囲、保存の有無、利用上の重要な注意は、利用者が送信前に確認できる位置に示します。継続的な判断に不要な説明は、Empty Stateまたは導入メッセージへ簡潔に統合します。
• 許容: 画面の中心目的であるChatでは、Message LogにHeaderとComposerを除いた利用可能な高さを与え、Message Logだけを局所的に縦スクロールできます。
• 禁止: App Top Barに現在地が表示されている場合、Main Contentの先頭へ同じPage Titleを反復しません。
• 禁止: 新規セッション、履歴、検索、設定など会話を直接構成しない補助操作は、専用SidebarまたはApp Top Bar内の一つのMenuへまとめる。補助操作のためだけに常設Toolbarを追加しません。
• 禁止: 埋込みChatで不要な二重縦スクロールを作りません。document scrollを優先します。

セッションと履歴

• 必須: 履歴を保存するかは、機能要件、利用者の理解、プライバシーに基づいて決めます。
• 必須: 履歴を保存するChatは、新規セッションと既存セッションを混在させず、各項目から題名、更新日時、必要な状態、現在選択中のセッションを判別できるようにします。件数や反復的な探索により目視での発見が難しくなる場合は検索を用意します。
• 必須: 履歴の表示形式に応じて操作モデルを分けます。常設Sidebarと非モーダルPanelは通常のフォーカス順序を保ちます。MenuはEscapeによる閉じる操作と起点へのフォーカス復帰を持ちます。
• 原則: セッションを開いたときはMessage Logの末尾または最初の未読位置を基準に表示し、読み込みによってComposer、Header、フォーカスを移動させません。過去のMessageを追加する場合は、読んでいた位置を維持します。
• 禁止: 外観またはチェックリストへ合わせるために、保存しないChatへ履歴やセッションを追加しません。
• 禁止: 常設Sidebarと非モーダルPanelでフォーカスを閉じ込めたり、背後の会話操作を抑止したりしません。フォーカストラップと背後の操作抑止は、モーダルPanelまたはDialogだけに使います。

Chat画面の構造、履歴、Message Log、Chat Bubble、Composer、IME、live更新、Focus保持は7.11のすべてを満たします。Chat Composerは7.13の単体部品と同じ入力面、送信Button、stateを再利用します。外観だけを会話風にするため、単発の検索、Form、通知をChatへ置き換えません。

認証

• 必須: Sign in、本人確認、Password resetなど現在の段階と、次に必要な操作をPage TitleとFormから理解できるようにします。
• 必須: 認証失敗では、入力値を必要な範囲で保持し、再試行、別の認証手段、問い合わせのうち利用できる経路を示します。
• 禁止: 認証Formの隣へ、判断に不要なCard、推薦文、抽象的な製品コピーを並べません。

概要・Dashboard

• 必須: 最初に利用者が判断すべき現在地、重要な変化、次の行動を示します。
• 原則: 同じ観点で比較する情報は、表、List、同格のCard群から最も少ない視線移動で比較できる構造を選びます。
• 禁止: 数値や短文を均等なCardへ分割すること自体をDashboardの構造にしません。

一覧・詳細

• 必須: 一覧で比較に必要な属性、選択中の対象、詳細へ移った後の戻り先を保ちます。
• 原則: 十分な幅では一覧と詳細を並べ、狭幅では一覧から詳細へ遷移して同じ情報順序を保ちます。
• 禁止: List Row全体を意味の曖昧なButtonにせず、遷移先または行内操作を明示します。

検索・絞込み・結果

• 必須: 検索対象、適用中の条件、結果件数、0件、取得失敗、条件解除を同じ画面骨格で示します。
• 原則: 条件が少ない場合は画面内へ置き、多い場合だけPopover、Panel、Menuへ再構成します。
• 禁止: 絞込みの実行、Navigation、表示mode切替をSearch Fieldへ兼用させません。

設定

• 必須: 設定名、現在値、変更結果、保存単位を近接させ、即時反映か保存操作が必要かを明示します。
• 原則: 関連設定は見出しと余白でまとめ、独立した判断単位でない項目ごとにCardを作りません。
• 禁止: 危険操作を通常設定の途中へ同じ外観で混ぜません。専用Sectionと確認を用意します。

複数段階の作成・導入

• 必須: 現在地点、完了済み、残り、戻れる範囲、確定が起きる段階を示します。
• 必須: 各段階で入力を保持し、失敗後に安全に再試行できる地点を示します。
• 禁止: 一枚で理解できる短いFormを、演出のためだけに複数段階へ分割しません。

8. 状態、インタラクション、AI

適用層: 媒体別標準（操作や処理状態を持つ成果物）

Webと操作を持つHTMLに適用します。静的な資料のAI提案・情報の確度は第3章で確認し、存在しない操作状態を設計する必要はありません。

8.1 インタラクション状態

操作部品は、必要な範囲で次の状態を設計します。

• 必須: Hover、Focus、Active、Selected、Disabled、Loadingを含む各状態で、背景色と文字色を一組で検証し、通常文字4.5:1以上、情報理解に必要なUI境界3:1以上を保ちます。
• 必須: HoverやSelectedによって、Defaultより文字、Icon、境界が読みにくくならないようにします。色を変える場合もLabel、寸法、配置を維持します。
• 原則: 現在地や選択は、濃緑の塗りを増やす前に、下線、Check、太さ、全周境界、Brand Softの面を組み合わせて示します。
• 禁止: 同じ面に並ぶ複数の通常ControlやNavigation項目を、選択やHoverのたびに濃緑で塗り、中心操作と競合させません。

状態設計の共通条件

• 必須: Default、Hover、Focus Visible、Active、Selected、Disabled、Loading、Success、Warning、Errorのうち必要な状態を設計します。
• 必須: Loading、Empty、Errorでも、何が起きていて次に何ができるかを示します。
• 禁止: Spinnerだけを大きな空白の中央へ置きません。
• 禁止: Shimmer、Sparkles、発光orbを、AIや読込中の既定表現にしません。

8.2 AIを介する体験

AIらしさを装飾で示さず、責任、確度、状態を明確にすることで示します。

• 原則: AI生成内容を、人が確定した事実と同じ外観にしません。
• 原則: 外部送信文は、送信前に内容と相手を確認できるようにします。
• 原則: AIが利用不能でも、人が確認、編集、実行できる安全な経路を残します。
• 原則: ShimmerをAIの象徴として使わず、Skeleton、Progress、状態文を使います。
• 禁止: 重要な根拠と注意を折りたたみ内だけに置きません。

9. アクセシビリティ、レスポンシブ、モーション

適用層: 基本原則、および媒体別標準

9.1 アクセシビリティ

WCAG 2.2 AAを最低目標とし、企画、構成、制作、実装、書出しの各段階で確認します。

• 必須: スライドと文書も、読み順、代替テキスト、コントラスト、言語設定を確認します。
• 禁止: 色、位置、形、音、動きの一つだけへ意味を依存させません。

9.2 レスポンシブ

レスポンシブは縮小ではなく再構成です。

1. 主要な内容と主要操作を残します。
2. 複数列を一列へ再配置します。
3. 補助情報を本文の後または開閉可能な領域へ移す。
4. Toolbarを折返し、Popover、Menuへ再配置します。
5. 表とTabsだけ、意味を失わない範囲で領域内横スクロールを許容します。

複数列から一列への再配置は、Card内の文字、操作、進捗表示が読めなくなる直前に行います。関連する概要Cardが十分な幅を保てるときは複数列を維持し、一画面での比較可能性を優先します。次の行動、推奨、手順の短いListは項目をすべて表示し、List内の縦スクロールや末端の見切れを作りません。

320、375、414、768、1024、1440 CSS pxを代表幅として確認します。safe-area、ソフトキーボード、長い日本語、最大件数、文字拡大、Hoverのない入力環境を含めます。

9.3 モーション

• 原則: 動きは、状態変化、空間関係、操作結果を理解させるために使います。
• 原則: スライドでは全要素へ同じ登場アニメーションを付けず、順序理解に必要な段階表示だけに使います。
• 禁止: 装飾だけの常時移動、カーソル追従、視差スクロール、浮遊物を使いません。

9.4 Webと操作を持つHTMLの実装・検証

Webアプリ、Webサイト、および操作を持つHTML出力に適用します。静的なPDFへHoverや画面幅の検査を機械的に適用しません。HTML読覧表示とPDFの読み順・代替説明・可読性は、それぞれの出力で検証します。

支援技術と操作の検証

• 必須: キーボードだけで移動、選択、編集、送信、閉じる操作を完了できるようにします。

• 必須: Focus Visibleを消しません。既定outlineを置き換える場合は、同等以上に明確な表示を同じ境界または面へ用意します。

• 必須: 200%文字拡大と400%相当の狭幅で、内容と主要操作を失わないようにします。

• 必須: forced-colors、高コントラスト、Reduced Motionなどの支援設定を妨げません。

Webと操作を持つHTMLのアクセシビリティ

• 必須: フォーカス順序と読み上げ順を視覚順序に一致させます。

• 必須: 自動更新、タイムアウト、消える通知には停止、延長、再確認の方法を用意します。

• 原則: キーボードだけで、移動、選択、編集、送信、閉じる操作を完了できます。

• 原則: フォーカス表示を消しません。

• 原則: 200%ズームと文字拡大で操作を失わず、400%相当の狭い表示でも再配置します。

• 禁止: forced-colors、高コントラスト、OSの支援設定を意図的に妨げません。

Webと操作を持つHTMLのモーション

• 原則: Controlの反応は120–180 ms、DialogやPanelは180–260 msを基準とします。

• 原則: transition: allを使わず、変化するプロパティを限定します。

• 原則: レイアウトを連続的に動かすプロパティより、transformとopacityを優先します。

• 原則: prefers-reduced-motion: reduceでは非本質的な動きを停止します。

• 原則: 標準easingにはcubic-bezier(0.2, 0, 0, 1)を使い、Controlの120ms、標準の180ms、DialogやPanelの260msという時間役割を入れ替えません。

チェックリスト・禁則事項

正本の必須・禁止をそのまま確認項目として掲載しています。媒体固有の条件と共通条件の両方を確認してください。自動検査と内容・視覚の判断は別です。未確認の項目は合格ではありません。

媒体固有 — 禁則事項

• Hoverへ情報や操作を依存させません。 出典: 6.1 WebアプリとWebサイト
• ブラウザ標準のalert()、confirm()、prompt()を製品体験に使いません。 出典: 6.1 WebアプリとWebサイト
• 通常レイアウトで100vwを使って意図しない横スクロールを発生させません。 出典: 6.1 WebアプリとWebサイト
• continuous cornerをHoverや選択状態として切り替えたり、形状を連続Animationさせたりしません。 出典: Webのcontinuous corner
• 標準CSSの非対応だけを理由に、実行時の高頻度なpath再計算、Canvas、WebGLを導入しません。 出典: Webのcontinuous corner
• Cardを選択、モード切替え、表示切替え、ページ遷移に使いません。 出典: Webのcontinuous corner
• 破壊的操作を確認なしで実行しません。 出典: Webのcontinuous corner
• 破壊的操作を赤系以外で示しません。 出典: Webのcontinuous corner
• LabelをCardまたはSectionの見出しとして使いません。 出典: Webのcontinuous corner
• すべてを中央揃えにしたり、内容のない100vhヒーローを作ったりしません。 出典: Webのcontinuous corner
• 全CardをHover時に拡大したり、transition: allを使ったりしません。 出典: Webのcontinuous corner
• 全Sectionへfade-up、bounce、cursor followerを適用しません。 出典: Webのcontinuous corner
• 意図しない横はみ出し、隠れた主要操作、入力内容の消失を残して受け入れ完了にしません。 出典: Web固有の禁止事項の検査
• 背景の位置、濃度、形を、時間、scroll、cursor、利用者情報、random値で変化させません。 出典: 白を基調とした左上のミント色背景
• blob、発光orb、粒子、video、Canvas、WebGLを背景表現へ追加しません。 出典: 白を基調とした左上のミント色背景
• 背景に意味、進捗、選択状態を持たせたり、背景に起因するCLSや入力遅延を発生させたりしません。 出典: 白を基調とした左上のミント色背景
• 曲線表現のためにButtonやInputをSVGへ置き換えたり、Focus Visible、境界、Semantic HTMLを失うmaskを適用したりしません。 出典: Webの角と曲線の実装基準
• 影の有無にかかわらず、ComposerがMessage Logを隠す配置にはしません。 出典: Webの固定Composerの奥行き
• 絵文字を機能アイコンとして使いません。 出典: アイコンの取得元と統一
• 状態、件数の単位、必須入力、エラーの原因、重要な注意を、アイコン化を理由に取り除きません。 出典: 見出しと操作での使い分け
• 比較に不要な3D、影、グラデーション、過剰な補助線を使いません。 出典: 6.4 グラフ、表、データ可視化
• 数値、単位、期間、母数、軸の尺度を、元データと照合せず実測値として示しません。 出典: 図表固有の禁止事項
• 凡例や色だけに識別を依存させ、白黒・色覚差で比較対象を失う図表を配布しません。 出典: 図表固有の禁止事項
• 軸の省略、切断、面積・体積の誇張で、値の差を実際と異なる印象にしません。 出典: 図表固有の禁止事項
• bodyとMain Contentの二重縦スクロールを作りません。 出典: 7.1 画面骨格
• Card全体を選択、モード切替え、表示切替え、ページ遷移に使いません。 出典: 7.2 Card
• Cardの内側へさらに緑系の背景面を重ねません。Card内の文字、Link、Label、状態色と緑の主張が競合する場合は、余白、Divider、見出しで区切ります。 出典: 7.2 Card
• Table、ログ、チャットのように領域内スクロール自体が機能でない限り、Card本体は内容の高さまで広げ、内容を切る縦スクロールを作りません。 出典: 7.2 Card
• Cardの一辺だけに色線を置きません。 出典: 7.2 Card
• 出所を確認できない人物写真、絵文字、ランダムな背景色をAvatarへ使いません。 出典: AvatarとSeparator
• 一覧のすべての行やCard内部を線で細分化し、情報のまとまりを線だけに依存させません。 出典: AvatarとSeparator
• Hoverで色を変えず、クリックへ反応せず、pointerを使いません。 出典: 7.4 Label
• CardまたはSectionの見出しとして使いません。 出典: 7.4 Label
• ページ間ナビゲーション、単独の絞込み、実行操作へ流用しません。 出典: 7.5 Tabs
• 保存、整列、表示密度など、選択した時点で同じ対象の設定を変更する操作へ流用しません。 出典: 7.5 Tabs
• BreadcrumbsをPage Titleの代わりに使いません。 出典: BreadcrumbsとPagination
• 無限scrollだけを唯一の移動手段にし、現在位置や終端を分からなくしません。 出典: BreadcrumbsとPagination
• Toolbarを見出し、検索、Navigation、状態表示の雑多な置き場にしません。 出典: ToolbarとNavigation Menu
• Hoverだけで開くNavigation Menuへ主要導線を依存させません。 出典: ToolbarとNavigation Menu
• Components Libraryの参照実例で、Browser既定のCheckbox、Radio、Select矢印、Range track、Number spinner、Date表示、File選択面を、そのままLiberkaの完成外観として提示しません。 出典: 7.7 Form Controls
• 「検索語」のように利用者の行動や対象を説明しない内部的な語だけをLabelまたはPlaceholderに使いません。 出典: Search Field
• Placeholderだけでアクセシブルネームを代用しません。視覚的なLabelを省略する場合も、aria-labelまたは同等の方法で名前を持たせます。 出典: Search Field
• 高さに比例して角丸を大きくし、複数行入力を巨大なピル形にしません。 出典: 複数行のText FieldとChat Composer
• 同意、重要な確認、料金の発生を初期選択済みにしません。 出典: Checkbox、Radio Group、Toggle Group
• Card全体をCheckbox、Radio、Toggleの代わりにしません。 出典: Checkbox、Radio Group、Toggle Group
• Toggle Groupで別の内容面、状態見本、Sectionを切り替えません。その関係にはTabsを使います。 出典: Checkbox、Radio Group、Toggle Group
• Search Fieldを選択Controlとして流用し、選択の確定状態を曖昧にしません。 出典: SelectとCombobox
• Placeholderだけで既定値、未選択、Labelを兼ねません。 出典: SelectとCombobox
• 保存が必要な設定をSwitchだけで即時反映したように見せません。 出典: SwitchとSlider
• 二つ以上の状態や取り消せない操作にSwitchを使いません。 出典: SwitchとSlider
• Passwordの値を初期状態で表示しません。 出典: Number、Date、Password、File、Character Count
• File選択面全体をButtonに見せながら、Keyboardや読み上げでは操作対象を特定できない構造にしません。 出典: Number、Date、Password、File、Character Count
• Tooltipへ重要情報、エラー、操作を置きません。 出典: 7.8 Dialog、Popover、Menu、Tooltip
• 最終画面と無関係なSkeleton Cardや仮の図形を追加しません。汎用の大きなSkeleton面、実際の行数を示さない反復Placeholder、意味のない灰色の線を「骨格」と呼びません。 出典: 7.9 Progress、Loading、Empty State
• 読込中のTabや入力を一時的な配色、透明度、代替書体で示しません。操作不能であることはaria-busy、aria-disabled、状態文で伝え、完了時に外観を切り替えません。 出典: 7.9 Progress、Loading、Empty State
• Spinnerだけを大きな空白の中央へ置きません。 出典: 7.9 Progress、Loading、Empty State
• Error、費用、破壊的結果、公開範囲など重要な情報をToastだけで伝えません。 出典: Alert、Toast、Error Summary
• Alertを常設の装飾Cardや販促Bannerとして使いません。 出典: Alert、Toast、Error Summary
• Chartの表、凡例、詳細を展開しても、先に表示されているプロット領域を縮小または押しつぶしません。プロットの寸法を保ち、追加内容を下へ展開するか、所属する領域をスクロールさせます。 出典: 7.10 List、Table、Tree、Chart
• 今日や選択中という理由だけで、予定がない日に番号を表示しません。セル全体やカレンダー全体を疑似Buttonにしません。 出典: Mini Calendar
• インデントや色線だけで親子関係を表しません。 出典: Tree
• 一覧に階層があるという理由だけで、Mobileでも横幅を消費するTreeを維持しません。 出典: Tree
• Messageの追加、生成中の更新、送信結果の通知でフォーカスを奪いません。 出典: Messageと動的更新
• Tailとして別要素または疑似要素の三角形を継ぎ足しません。 出典: Messageと動的更新
• Bubbleが横幅を越え、Message Log全体へ意図しない横スクロールを作る状態を許容しません。 出典: Messageと動的更新
• 警告、エラー、費用、公開範囲、取消し可否、主要操作、現在地を閉じたAccordionの中だけに置きません。 出典: 7.12 Accordion
• 連続して読む本文や、目次の階層を短く見せることだけを目的に使いません。 出典: 7.12 Accordion
• 閉じた内容へフォーカスを残しません。開閉によって読み手の現在位置を不必要に移動させません。 出典: 7.12 Accordion
• ReactまたはNext.jsのconsumer repositoryで、正本Componentと同じ意味の部品を製品固有Componentとして複製しません。 出典: 7.13 共通コンポーネントの仕様一覧
• Buttonの色と形を自由な直積として選びません。意味役割がvariantを決めます。 出典: 7.13 共通コンポーネントの仕様一覧
• Search Fieldを、項目数が多そうだという理由だけで追加しません。 出典: 7.13 共通コンポーネントの仕様一覧
• 一般的な長文FormへChat Composerを流用しません。 出典: 7.13 共通コンポーネントの仕様一覧
• Progressへ見せるための最低表示時間を設けません。 出典: 7.13 共通コンポーネントの仕様一覧
• 外部LibraryのCSS、色、余白、命名、装飾を、そのLibraryが一般的であることだけを理由にLiberkaの正本へ持ち込みません。 出典: 7.13 共通コンポーネントの仕様一覧
• LayoutまたはFlowの都合で、既存Componentに似た別外観や別操作を局所的に作りません。必要なvariantは先にComponentの共通仕様へ追加します。 出典: 7.14 共通の構成と流れ（Layouts & Flows）
• 同じ位置へ、役割を区別できない複数のHamburger Buttonを並べません。 出典: App Shell、Sidebar、Mobile Navigation
• Disabledの外観だけで操作できない理由を隠しません。 出典: Form
• Loading完了時にTypography、Tabs、入力の外観を切り替えません。 出典: Loading、Empty、Error
• Dialogの上へDialogを重ねません。同じ面のstep切替を使います。 出典: 確認と破壊的操作
• App Top Barに現在地が表示されている場合、Main Contentの先頭へ同じPage Titleを反復しません。 出典: 会話領域とナビゲーション
• 新規セッション、履歴、検索、設定など会話を直接構成しない補助操作は、専用SidebarまたはApp Top Bar内の一つのMenuへまとめる。補助操作のためだけに常設Toolbarを追加しません。 出典: 会話領域とナビゲーション
• 埋込みChatで不要な二重縦スクロールを作りません。document scrollを優先します。 出典: 会話領域とナビゲーション
• 外観またはチェックリストへ合わせるために、保存しないChatへ履歴やセッションを追加しません。 出典: セッションと履歴
• 常設Sidebarと非モーダルPanelでフォーカスを閉じ込めたり、背後の会話操作を抑止したりしません。フォーカストラップと背後の操作抑止は、モーダルPanelまたはDialogだけに使います。 出典: セッションと履歴
• 認証Formの隣へ、判断に不要なCard、推薦文、抽象的な製品コピーを並べません。 出典: 認証
• 数値や短文を均等なCardへ分割すること自体をDashboardの構造にしません。 出典: 概要・Dashboard
• List Row全体を意味の曖昧なButtonにせず、遷移先または行内操作を明示します。 出典: 一覧・詳細
• 絞込みの実行、Navigation、表示mode切替をSearch Fieldへ兼用させません。 出典: 検索・絞込み・結果
• 危険操作を通常設定の途中へ同じ外観で混ぜません。専用Sectionと確認を用意します。 出典: 設定
• 一枚で理解できる短いFormを、演出のためだけに複数段階へ分割しません。 出典: 複数段階の作成・導入
• 同じ面に並ぶ複数の通常ControlやNavigation項目を、選択やHoverのたびに濃緑で塗り、中心操作と競合させません。 出典: 8.1 インタラクション状態
• Spinnerだけを大きな空白の中央へ置きません。 出典: 状態設計の共通条件
• Shimmer、Sparkles、発光orbを、AIや読込中の既定表現にしません。 出典: 状態設計の共通条件
• 重要な根拠と注意を折りたたみ内だけに置きません。 出典: 8.2 AIを介する体験
• 色、位置、形、音、動きの一つだけへ意味を依存させません。 出典: 9.1 アクセシビリティ
• 装飾だけの常時移動、カーソル追従、視差スクロール、浮遊物を使いません。 出典: 9.3 モーション
• forced-colors、高コントラスト、OSの支援設定を意図的に妨げません。 出典: Webと操作を持つHTMLのアクセシビリティ

媒体固有 — 必須条件

• 一連の処理ではProgressまたはStepperで現在地点を示します。 出典: 6.1 WebアプリとWebサイト
• 印刷スタイルでは、ナビゲーションと装飾を除き、本文、出典、図表を保持します。 出典: 6.1 WebアプリとWebサイト
• 利用者が見るControlの面、境界、Icon、文字、選択、進行、成功、警告、ErrorはLiberkaの意味役割とtokenで設計します。Native elementの意味や入力機能を使う場合も、Browserごとの未調整な既定外観を最終デザインにしません。 出典: 6.1 WebアプリとWebサイト
• Browser組込みの検証Bubble、確認画面、選択結果だけを、Errorや重要な判断を伝える唯一の経路にしません。製品内の文言と状態として同じ内容を確認できるようにします。 出典: 6.1 WebアプリとWebサイト
• pageInline、contentMeasure、sectionGap、componentGap、sidebarInsetを用途どおりに使います。 出典: Webの余白とControl token
• 入力面はbox-sizing: border-boxとし、文字、caret、Placeholder、Iconを境界外へ出しません。 出典: Webの余白とControl token
• border-radiusをfallbackとして先に宣言し、@supports (corner-shape: squircle)の中だけでcontinuous cornerを有効にします。 出典: Webのcontinuous corner
• 初期適用対象は角丸矩形のButtonとCardに限定します。ピル形Button、Search Field、Icon Button、Radio、Input、Dialogは対象外とします。 出典: Webのcontinuous corner
• 対応時も非対応時も、同じHTML、Border、Focus Visible、操作対象寸法、読み順を維持します。 出典: Webのcontinuous corner
• 該当する第7章の部品仕様と第8・9章の操作・状態・アクセシビリティを受け入れ項目へ接続します。初期表示だけで、未操作のDialog・送信・失敗状態を合格にしません。 出典: Web固有の禁止事項の検査
• 視覚順、DOM上の読み順、読み上げ順を一致させます。 出典: Webの読み順
• 背景の基底にはbackground.base（#FFFFFF）、左上の色にはbackground.mint（#8ECCB0）、基準となる最大不透明度にはbackground.mintOpacity（0.24）を使います。 出典: 白を基調とした左上のミント色背景
• gradientは左上を起点とし、本文、操作、図表より背面へ固定した静止表現にします。 出典: 白を基調とした左上のミント色背景
• 複雑な輪郭は事前計算したベクターパスまたは少数の制御点として保持します。 出典: Webの角と曲線の実装基準
• radiusとcornerを別のtokenとして参照し、半径だけを連続曲率の根拠にしません。 出典: Webの角と曲線の実装基準
• Pill Button、Search Field、Chat Composerの一行状態、Icon Button、Radioは円または円弧の意味を保ち、continuous cornerへ変更しません。 出典: Webの角と曲線の実装基準
• 軸、単位、期間、母数、集計方法、欠損、出典を必要に応じて示します。 出典: 6.4 グラフ、表、データ可視化
• インタラクティブなグラフには、同じ情報へ到達できる要約または表形式の代替を用意します。 出典: 6.4 グラフ、表、データ可視化
• Main Contentは、固定Sidebarの幅と固定Top Barの高さをApp Shellのtokenから正確に差し引き、内容を背後へ隠しません。アンカー移動、フォーカス移動、エラー位置への移動にも同じ上部補正を適用します。 出典: 7.1 画面骨格
• Avatarだけで本人確認、権限、在席、選択状態を伝えず、必要な名前と状態を文字でも示します。 出典: AvatarとSeparator
• 意味のあるSeparatorはhrなど適切な構造を使い、装飾だけの線は読み上げから除外します。 出典: AvatarとSeparator
• 破壊的Buttonは赤系で示します。 出典: 7.3 Button
• 選択中は下線、濃い文字、必要に応じた件数Labelで示します。 出典: 7.5 Tabs
• Tabsを選ぶと、対応するtabpanelへ表示内容そのものが切り替わります。選択前後で同じ内容が残り、表示方法や設定値だけが変わる場合はToggle Groupを使います。 出典: 7.5 Tabs
• Breadcrumbsは現在地を末尾に置き、Navigationとして名前を付けます。現在地はLinkにしません。 出典: BreadcrumbsとPagination
• Paginationは現在のページ、全体または前後関係を文字で示し、各Linkの目的をアクセシブルネームでも区別します。 出典: BreadcrumbsとPagination
• Toolbarは同じ対象へ作用する操作だけをまとめ、名前とキーボード上の移動方法を持たせます。 出典: ToolbarとNavigation Menu
• Navigation Menuは移動先を扱い、保存や削除など同じ画面の状態を変える操作と混在させません。 出典: ToolbarとNavigation Menu
• Label、Control、Help、Errorを意味的に関連付けます。 出典: 7.7 Form Controls
• 必須と任意をフォーム全体で一貫して示します。 出典: 7.7 Form Controls
• 入力値を失敗後も可能な限り保持します。 出典: 7.7 Form Controls
• Checkbox、Radio、Select、Slider、Number、Date、Fileを含むControlは、DefaultだけでなくHover、Focus、Selected、Disabled、Loading、Errorなど必要な状態の外観をLiberka側で定義します。 出典: 7.7 Form Controls
• SelectとComboboxの選択肢は、HoverとFocus Visibleで操作対象だと分かる面を作り、文字とのコントラストを保ちます。Liberka共通のHover面にはBrand Soft #DCEFE7とBrand Primary Strong #005456を組み合わせ、Defaultの外観と位置を変えません。Brand Primary #009EA1の面を選択肢のHoverへ使いません。 出典: 7.7 Form Controls
• 一行のSearch Fieldは、左右端が円になる細身のピル形、透明な背景、Liberkaの濃緑による1 CSS pxの全周境界を使います。 出典: Search Field
• 入力面の先頭へ、検索であると分かる虫眼鏡Iconを置きます。Iconは装飾として読み上げから除外し、入力自体にアクセシブルネームを設定します。 出典: Search Field
• Placeholderは「ガイドライン内を検索」「メンバーを検索」のように、検索対象を含む自然な表現にします。 出典: Search Field
• Focus Visibleでは外側へ別のoutlineやshadowを追加せず、同じ境界を内側へ2 CSS pxに強調します。部品の外寸と周囲の配置を変えません。 出典: Search Field
• Focus表示は背景に対して認識できる面積とコントラストを持つことを、キーボード操作とforced-colorsで検証します。 出典: Search Field
• 一行のChat Composerでは、入力文字、caret、Placeholderを44 CSS px以上の入力面の垂直方向中央へ揃えます。行高と上下paddingを一組で定義し、上寄せまたは下寄せにしません。 出典: 複数行のText FieldとChat Composer
• 複数行入力は横幅を保ったまま高さを増やし、一定半径の角丸矩形へ切り替えます。 出典: 複数行のText FieldとChat Composer
• 文字、caret、Placeholder、Icon、送信Buttonのための内側余白を確保し、どの状態でも全周境界の外へはみ出さないようにします。 出典: 複数行のText FieldとChat Composer
• 200%文字拡大、長い日本語、五行以上の入力、ソフトキーボード表示で、入力内容と送信操作を検証します。 出典: 複数行のText FieldとChat Composer
• Checkboxは複数の独立した選択、Radio Groupは一つだけ選ぶ相互排他的な選択に使います。 出典: Checkbox、Radio Group、Toggle Group
• Groupには質問または目的を示す名前を付け、各選択肢のLabel全体を操作できるようにします。 出典: Checkbox、Radio Group、Toggle Group
• checked、unchecked、mixed、selectedを色だけで区別せず、Controlの形とアクセシブルな状態を一致させます。 出典: Checkbox、Radio Group、Toggle Group
• Selectは用意された候補から選ぶ場合、Comboboxは入力による候補の絞込みまたは任意値の入力が必要な場合に使います。 出典: SelectとCombobox
• Comboboxは入力、Popup、候補、選択値の関係をアクセシブルに実装し、読み込み中、0件、Errorを文字で示します。 出典: SelectとCombobox
• 候補を開いても入力値とFocusを失わず、Escapeで候補を閉じた後も入力へ戻ります。 出典: SelectとCombobox
• Switchは操作直後に反映される独立した二値設定に使い、現在がOnかOffかを文字でも理解できるようにします。 出典: SwitchとSlider
• Sliderは最小値、最大値、現在値、単位を示し、Keyboardと直接入力でも同じ値へ到達できるようにします。 出典: SwitchとSlider
• Number Fieldは許容範囲、刻み、単位、Error条件を入力の近くへ示します。 出典: Number、Date、Password、File、Character Count
• Date Fieldは利用者に見える値を20XX年M月D日で示し、Calendarを使えない人にも文字入力または同等の経路を用意します。 出典: Number、Date、Password、File、Character Count
• Password Fieldは内容を表示・非表示にする操作を用意する場合も、入力値、Focus、caretを保持します。 出典: Number、Date、Password、File、Character Count
• File Uploadは対応形式、上限、選択済みFile、進行、成功、失敗、取消し可否を文字で示します。 出典: Number、Date、Password、File、Character Count
• Character Countは上限が判断へ影響する位置に現在値と上限を示し、超過理由を色だけに依存させません。 出典: Number、Date、Password、File、Character Count
• Loading中は、最終表示で使うPage Header、Tabs、Toolbar、Card、List、Table、Chart、入力領域を先に配置し、そのデータ領域内へ読込状態を示します。 出典: 7.9 Progress、Loading、Empty State
• 段階処理は現在地点、完了済み、残り、失敗地点を示します。 出典: 7.9 Progress、Loading、Empty State
• Alertは種類だけでなく、起きたこと、影響、次にできることを本文で示します。 出典: Alert、Toast、Error Summary
• Error SummaryはFormの先頭付近に置き、各Errorから該当Controlへ移動できるようにします。 出典: Alert、Toast、Error Summary
• Toastを動的に表示する場合は、内容の緊急度に合うlive regionを使い、Focusを奪いません。 出典: Alert、Toast、Error Summary
• List Row全体を疑似Buttonにせず、行内操作を明示します。 出典: 7.10 List、Table、Tree、Chart
• ドラッグ操作には可視ハンドル、grab状態、キーボード代替、結果通知を用意します。 出典: 7.10 List、Table、Tree、Chart
• 対象の年・月と曜日を示し、予定が一つ以上ある日だけ日付番号、予定がない日は「・」を中央揃えで表示します。数字は予定件数ではなく日付を意味します。 出典: Mini Calendar
• 月曜から日曜の7列と日付順を保ち、月外の位置は空欄にします。実在する月初の曜日、月末、うるう年を反映します。 出典: Mini Calendar
• 日付と予定有無を読み上げでも確認できる構造にし、数字とドットの意味を近くに明記します。予定0件では月の全日をドットで示し、予定がないことを文字でも伝えます。 出典: Mini Calendar
• LoadingとErrorは対象月と表示領域を保ち、未確認であることを状態文で示します。取得できていない日を「予定なし」のドットとして表示しません。 出典: Mini Calendar
• Tree itemは階層、展開状態、選択状態を構造として持ち、Arrow keys、Home、Endで移動できるようにします。 出典: Tree
• 展開Buttonと項目の選択または移動を別の操作として認識できるようにします。 出典: Tree
• 発話者別の面はAssistantにcolor.surface、Userにcolor.brandSoft、Systemにcolor.canvasを使い、発話者名と構造を併用します。 出典: 7.11 Chat
• Message Logは視覚的かつアクセシブな名称を持ち、Messageを古い順からDOM上の読み順と一致させる。新着Messageはrole="log"、live region、または同等の方法で通知し、既存履歴全体を再度読み上げさせません。ストリーミング中は文字ごとでなく、意味のある単位または完了時にまとめて通知します。 出典: Messageと動的更新
• 利用者が末尾付近を読んでいる場合だけ新着へ自動追従し、過去を読んでいる場合は位置を保って、新着位置へ移動する操作を示します。 出典: Messageと動的更新
• Message Bubbleは全周境界とSurfaceで背景から区切り、基本形を角丸にします。 出典: Messageと動的更新
• AI、利用者、システムの通知、外部操作、承認待ちを、文言、読み上げ、構造の組合せで区別します。内部実装名を主要メッセージへ露出させず、アクセシブな発話者情報を保ったうえで、連続する同一発話者の名前、時刻、AvatarまたはLogoの反復は省略できます。 出典: Messageと動的更新
• Bubbleは長文、URL、改行、長い日本語、コード、構造化内容を必要に応じて折り返します。 出典: Messageと動的更新
• ComposerはChat領域の下端へ固定またはsticky配置し、safe-areaとソフトキーボードを考慮します。Messageが増えても入力位置を見失わせず、Message Logを隠さない余白を確保します。 出典: Composerと送信
• Send Buttonは、送信可能、未入力、生成または送信中、失敗、文字数超過を判別できる状態を持ちます。処理中は重複送信を防ぎ、完了または失敗まで状態を示します。 出典: Composerと送信
• キーボード送信を提供する場合は、改行と送信の操作をComposerの近くへ明記します。日本語などのIME変換中にEnterを押しても送信せず、変換確定と送信を区別します。ショートカットを使えない環境でも、送信Buttonから同じ目的を達成できるようにします。 出典: Composerと送信
• 文字数制限がある場合は現在値と上限を示し、超過時は送信不能の理由を色だけでなく文言で示します。 出典: Composerと送信
• モバイルの入力文字は16 CSS px以上とし、Focus時の自動拡大を起こさない。Focusやソフトキーボード表示によってMessage Log全体が画面外へ移動したり、Composerがキーボードの背後へ隠れたりしないことを実機相当で確認します。 出典: Composerと送信
• 見出し全体を一つのButtonとし、見出しレベル、aria-expanded、操作対象との関係を保ちます。 出典: 7.12 Accordion
• EnterまたはSpaceで開閉でき、Tab順序を視覚順序と一致させます。 出典: 7.12 Accordion
• 開閉状態は矢印の向きだけでなく、アクセシブルな状態として伝えます。 出典: 7.12 Accordion
• IconだけのButtonにもアクセシブルネームを付け、重要操作は44×44 CSS px以上を目安にします。 出典: 7.13 共通コンポーネントの仕様一覧
• Dialogは初期Focus、Focus trap、Escape、起点へのFocus復帰、背後操作抑止を持ちます。 出典: 7.13 共通コンポーネントの仕様一覧
• MenuはArrow keysとEscape、起点へのFocus復帰を持ちます。非modal PopoverはFocusを閉じ込めません。 出典: 7.13 共通コンポーネントの仕様一覧
• Tableは正しいtable semanticsを使い、長文、0件、大量、領域内横scrollを確認します。 出典: 7.13 共通コンポーネントの仕様一覧
• Webの共通Componentは@liberka-schedia/ui-reactのReact exportを正本実装とし、Components、Layouts & Flows、skill、consumer repositoryは同じexportを参照します。 出典: 7.13 共通コンポーネントの仕様一覧
• Componentsの公開実例は正本React Component自体から生成し、見本専用の複製HTMLや別実装を表示しません。 出典: 7.13 共通コンポーネントの仕様一覧
• catalogはすべてのComponent IDをReact export、型、共通style、必要stateへ機械可読に結びます。 出典: 7.13 共通コンポーネントの仕様一覧
• LayoutとFlowは、Componentsで定義済みの意味、variant、state、token、アクセシビリティをそのまま再利用します。 出典: 7.14 共通の構成と流れ（Layouts & Flows）
• 参照例は、使用したComponentを機械可読な索引で明示し、単体例と複合例が同じ部品であることを検証できるようにします。 出典: 7.14 共通の構成と流れ（Layouts & Flows）
• Desktop SidebarとTop Barを固定する場合、Main Contentへ正確なinsetとanchor補正を与えます。 出典: App Shell、Sidebar、Mobile Navigation
• 高さが不足するときはNavigation部分だけをscroll可能にし、製品名とaccount操作を同時に失いません。 出典: App Shell、Sidebar、Mobile Navigation
• Mobileでは、一つのHamburger Buttonから検索とNavigationを含むPanelを開きます。 出典: App Shell、Sidebar、Mobile Navigation
• Hamburger ButtonはNavigation Triggerの円形または角丸矩形variantを使い、App Shell専用の別Buttonとして作り直しません。 出典: App Shell、Sidebar、Mobile Navigation
• 必須と任意の示し方をForm全体で統一します。 出典: Form
• 比較が重要な少数選択肢にはRadio、多数にはSelect、独立した二値設定にはSwitchを使います。 出典: Form
• 失敗後も入力値を保持し、最初のErrorへFocusを移すか、明確なError summary導線を提供します。 出典: Form
• 参照ギャラリーなどでLoading、Refreshing、Empty、Error、Successの表示面を比較する場合はTabsを使い、Toggle Groupや実行Buttonで状態見本を切り替えません。 出典: Loading、Empty、Error
• Loading中も最終画面の骨格を先に配置し、本当に未取得の領域だけへ状態を示します。 出典: Loading、Empty、Error
• 同じ対象の再取得では、有効な表示済み内容を消さず更新状態を伝えます。 出典: Loading、Empty、Error
• EmptyでもPage Header、Filter、追加操作など必要な骨格を残します。 出典: Loading、Empty、Error
• Errorでは原因、影響、再試行の安全性、代替手段を示します。 出典: Loading、Empty、Error
• 破壊的操作は、対象、影響、復旧可否、赤い実行Buttonを示して確認します。 出典: 確認と破壊的操作
• Warningはオレンジ、通常確認はLiberka greenを使い、破壊と混同しません。 出典: 確認と破壊的操作
• 履歴を保存するかは、機能要件、利用者の理解、プライバシーに基づいて決めます。 出典: セッションと履歴
• 履歴を保存するChatは、新規セッションと既存セッションを混在させず、各項目から題名、更新日時、必要な状態、現在選択中のセッションを判別できるようにします。件数や反復的な探索により目視での発見が難しくなる場合は検索を用意します。 出典: セッションと履歴
• 履歴の表示形式に応じて操作モデルを分けます。常設Sidebarと非モーダルPanelは通常のフォーカス順序を保ちます。MenuはEscapeによる閉じる操作と起点へのフォーカス復帰を持ちます。 出典: セッションと履歴
• Sign in、本人確認、Password resetなど現在の段階と、次に必要な操作をPage TitleとFormから理解できるようにします。 出典: 認証
• 認証失敗では、入力値を必要な範囲で保持し、再試行、別の認証手段、問い合わせのうち利用できる経路を示します。 出典: 認証
• 最初に利用者が判断すべき現在地、重要な変化、次の行動を示します。 出典: 概要・Dashboard
• 一覧で比較に必要な属性、選択中の対象、詳細へ移った後の戻り先を保ちます。 出典: 一覧・詳細
• 検索対象、適用中の条件、結果件数、0件、取得失敗、条件解除を同じ画面骨格で示します。 出典: 検索・絞込み・結果
• 設定名、現在値、変更結果、保存単位を近接させ、即時反映か保存操作が必要かを明示します。 出典: 設定
• 現在地点、完了済み、残り、戻れる範囲、確定が起きる段階を示します。 出典: 複数段階の作成・導入
• 各段階で入力を保持し、失敗後に安全に再試行できる地点を示します。 出典: 複数段階の作成・導入
• Hover、Focus、Active、Selected、Disabled、Loadingを含む各状態で、背景色と文字色を一組で検証し、通常文字4.5:1以上、情報理解に必要なUI境界3:1以上を保ちます。 出典: 8.1 インタラクション状態
• HoverやSelectedによって、Defaultより文字、Icon、境界が読みにくくならないようにします。色を変える場合もLabel、寸法、配置を維持します。 出典: 8.1 インタラクション状態
• Default、Hover、Focus Visible、Active、Selected、Disabled、Loading、Success、Warning、Errorのうち必要な状態を設計します。 出典: 状態設計の共通条件
• Loading、Empty、Errorでも、何が起きていて次に何ができるかを示します。 出典: 状態設計の共通条件
• スライドと文書も、読み順、代替テキスト、コントラスト、言語設定を確認します。 出典: 9.1 アクセシビリティ
• キーボードだけで移動、選択、編集、送信、閉じる操作を完了できるようにします。 出典: 支援技術と操作の検証
• Focus Visibleを消しません。既定outlineを置き換える場合は、同等以上に明確な表示を同じ境界または面へ用意します。 出典: 支援技術と操作の検証
• 200%文字拡大と400%相当の狭幅で、内容と主要操作を失わないようにします。 出典: 支援技術と操作の検証
• forced-colors、高コントラスト、Reduced Motionなどの支援設定を妨げません。 出典: 支援技術と操作の検証
• フォーカス順序と読み上げ順を視覚順序に一致させます。 出典: Webと操作を持つHTMLのアクセシビリティ
• 自動更新、タイムアウト、消える通知には停止、延長、再確認の方法を用意します。 出典: Webと操作を持つHTMLのアクセシビリティ

全媒体共通 — 禁則事項

• 個別の製品やページに、この正本と競合する独自のデザイン規範を作りません。 出典: 1.1 何に適用するか
• 個別成果物の不適合一覧、改修計画、リリース記録、日付順の変更履歴を本文へ混ぜません。それらはIssue、Pull Request、Git履歴で管理します。 出典: 1.1 何に適用するか
• 「なるべく」「いい感じに」「適切に」のように、合否を判断できない言葉だけで規則を終えません。 出典: 1.2 規範語
• ブランドらしさ、見栄え、慣例を理由に、上位の安全性やアクセシビリティを下げません。 出典: 1.3 判断の優先順位
• 媒体別標準や製品別規則が、基本原則の必須事項または禁止事項を解除することはできません。 出典: 1.4 三つの適用層
• 共通tokenファイルに値が存在することだけを理由に、Webの背景、操作部品、角丸、時間指定を他媒体へ適用しません。 出典: 1.5 共通原則と媒体別の具体化を分ける
• 勢い、曖昧な文言、視覚的な誘導によって、重要な決定を急がせません。 出典: 2.1 Mission
• Hover、色、音、動きのいずれか一つだけへ意味や操作を依存させません。 出典: 2.2 Vision
• 利用者の不安や見落としを利用して行動を促しません。 出典: Choose with Love — 大切なものを最優先に選ぶ
• 謝罪や婉曲表現だけで原因と影響を隠しません。 出典: Honest Dialogue — 感情も問題も誠実に向き合う
• 重要な注意を脚注、Tooltip、閉じたAccordionの中だけに置きません。 出典: Give First — 価値も愛も出し惜しみしない
• 表現のために表示性能、検索性、印刷性、アクセシビリティを下げません。 出典: Long-term Choice — 長期で正しい選択をする
• 既存実装を正当化するためだけに、規範を弱めません。 出典: 2.4 哲学を検証可能にする
• 「革新的」「シームレス」「可能性を解き放つ」など、具体的な価値を説明しない語を主文にしません。 出典: 3.1 言葉は判断を助ける
• 一般的な言葉で説明できる概念へ、独自の造語を追加しません。 出典: 3.1 言葉は判断を助ける
• 機能を説明しない抽象的なAIコピーを使いません。 出典: 3.1 言葉は判断を助ける
• 装飾のための架空データ、顧客、推薦文、効果を事実として示しません。 出典: 3.2 情報の確度を見分けられるようにする
• 利用者の感情や仕事を、点数やランキングだけへ縮減しません。 出典: 3.2 情報の確度を見分けられるようにする
• 実在しない数値、顧客、推薦文、効果、出典を事実として示しません。 出典: 3.2 情報の確度を見分けられるようにする
• 孫引きされた同じ情報を独立した複数の証拠として数えたり、相関や図の矢印だけで因果関係を断定したりしません。 出典: 内容品質の共通条件
• 必須条件の不合格を総合点で相殺したり、推奨案を勝たせるために比較条件を変えたりしません。 出典: 内容品質の共通条件
• 内容品質を情報量や分析項目の多さだけで評価したり、用途に不要な提案・意思決定・結論を型に合わせて作ったりしません。用途への適応を理由に、正確性、用語整合、適用される根拠・論理・留保の条件を弱めません。 出典: 読者と用途に応じた内容設計
• 余白を埋めるためにCard、図、文章、操作を増やしません。 出典: 3.3 一つの面に一つの中心目的を置く
• 成果物ごとに同じ意味の色を即興で追加しません。 出典: 3.4 色は名前ではなく意味で管理する
• 色だけで見出し階層を作りません。 出典: 3.5 見出しは大きさとコントラストで階層を作る
• 見出しの直前へ、カテゴリ名や雰囲気だけを表す小さな文字のkicker、eyebrow、overlineを反復しません。必要な分類は見出し本文、Breadcrumb、Navigationで示します。 出典: 3.5 見出しは大きさとコントラストで階層を作る
• 英大文字の短いLabelをすべての見出しの上へ反復しません。 出典: 3.5 見出しは大きさとコントラストで階層を作る
• kicker、eyebrow、overlineとして、小さなカテゴリ名や雰囲気語を見出しの上へ反復しません。 出典: 3.5 見出しは大きさとコントラストで階層を作る
• 見出し、操作、ブランド名を本文用書体へ機械的に合わせません。 出典: 3.6 文字は長く読めることを優先する
• すべての数値を12の倍数へ丸めるために、16pxの本文、1pxの境界、操作対象の寸法を崩しません。 出典: 3.7 余白は関係を説明する
• 通常のCard、一覧行、Button、図表へ影、色付きglow、Hover浮上を付けません。 出典: 3.8 境界、角、奥行きは実際の構造を示す
• Cardの一辺だけに意味のないアクセント線を置きません。 出典: 3.8 境界、角、奥行きは実際の構造を示す
• カードの左縁など、一辺だけにアクセント線を置くside-stripe cardを使いません。 出典: 3.8 境界、角、奥行きは実際の構造を示す
• 影だけで階層を示す構成、全Cardの浮上、色付きグローを使いません。 出典: 3.8 境界、角、奥行きは実際の構造を示す
• 任意の書体で「Liberka」や「Schedia」を組み、公式ロゴのように扱いません。 出典: 3.9 ロゴとブランド名を混同しない
• シンボルの変形、回転、縁取り、影、再着色、切り抜き、要素追加を行いません。 出典: 3.9 ロゴとブランド名を混同しない
• 状態が変わったように見せるだけの演出で、実際の結果や未完了の作業を隠しません。 出典: 3.10 状態と次の一歩を隠さない
• ブランド表現を理由に、コントラスト、代替テキスト、読み順、操作対象を弱めません。 出典: 3.11 アクセシビリティは後付けにしない
• アクセシビリティまたは情報の正確性を、ブランド表現を理由に下げません。 出典: 3.11 アクセシビリティは後付けにしない
• Sparkles、ロボット、脳、魔法の杖をAIの既定記号にしません。 出典: 3.12 AIは責任と確度で示す
• 実データのない効果、利用者数、推薦文、比較優位を作りません。 出典: 3.13.2 言葉の原則
• 同じ意味役割の色を成果物ごとに即興で追加しません。 出典: Liberka Core palette
• 紫から青、紫からピンクのグラデーションを使いません。 出典: Liberka Core palette
• グラデーション文字を使いません。 出典: Liberka Core palette
• 形状のために情報の境界、可読性、必要な操作を失わせません。 出典: 4.4 角と曲線
• 複数段の影、色付きグロー、ホバー時の浮上、常時浮く統計カードを使いません。 出典: 4.5 境界と奥行き
• スライドや文書で、段落や数値を装飾カードへ入れて階層を作りません。 出典: 4.5 境界と奥行き
• 半透明色だけで境界を作りません。 出典: 4.6 透明素材とガラス表現
• ガラス面の上へさらにガラス面を重ねません。 出典: 4.6 透明素材とガラス表現
• 全面GlassやGlassの入れ子を使いません。 出典: 4.6 透明素材とガラス表現
• 絵文字を機能アイコンとして使いません。 出典: アイコンの共通方針
• 意味のない人物イラスト、3D物体、発光球を余白埋めに使いません。 出典: 画像とイラスト
• 発光orb、汎用blob、オーロラ、意味のない3D物体を使いません。 出典: 画像とイラスト
• 重要な注意を脚注、Tooltip、折りたたみの中だけに置きません。 出典: 5.2 読む順序
• すべてをCardへ入れる構成、意味のないCard内Card、均等なBentoグリッドを使いません。 出典: 5.3 容器の節度
• 三列の均等なアイコンCardを、内容上の理由なく使いません。 出典: 5.3 容器の節度
• 必須項目の未確認や不合格が残った状態を受け入れ完了としません。例外は第13.4節に従います。 出典: 12.1 対象と判定
• 観点別チェック件数を改稿回数や独立レビュー人数と呼びません。原稿版、指摘、実際の変更、再確認を分け、同じ案への賛成を重ねて品質を証明したことにしません。利用者が回数を指定しても、回数によって未解決条件を解除しません。 出典: 原稿を批評してから変換する

全媒体共通 — 必須条件

• 成果物の所有者は、基本原則、対応する媒体別標準、該当する製品別規則の順に確認します。 出典: 1.1 何に適用するか
• AIが生成または補助した成果物も、人が作った成果物と同じ基準で検証します。 出典: 1.1 何に適用するか
• 規範的な箇条書きには、四つの規範語のいずれかを付けます。 出典: 1.2 規範語
• 下位層は上位層を具体化します。 出典: 1.4 三つの適用層
• consumer repositoryとの接続情報は「適用設定」として管理します。適用設定はデザイン上の第四層ではありません。 出典: 1.4 三つの適用層
• 特定媒体の操作、出力条件、実装技術を前提とする規則は、媒体別の所有先に置きます。共通原則には守る目的と参照先を残します。 出典: 1.5 共通原則と媒体別の具体化を分ける
• 規則の適用は成果物の目的と実際の機能で判断します。操作を持つHTMLでは第8章・第9.4節も参照し、HTML制作であることだけを理由に資料全体をWeb媒体へ切り替えません。 出典: 1.5 共通原則と媒体別の具体化を分ける
• 利用者が何を理解し、何を決め、次に何が起こるかを説明できる構成にします。 出典: 2.1 Mission
• 重要な操作には、確認、編集、取消し、復旧のうち必要な経路を用意します。 出典: 2.1 Mission
• 支援技術、キーボード、タッチ、文字拡大、狭い画面でも中心目的へ到達できるようにします。 出典: 2.2 Vision
• 中心目的と、それを支える情報の優先順位を定めます。 出典: Choose with Love — 大切なものを最優先に選ぶ
• 規範を変更するときは、影響範囲と変更後の判断方法を説明します。 出典: Grow to Choose — 選択を増やすために成長する
• 事実、推定、提案、未確定、失敗を区別します。 出典: Honest Dialogue — 感情も問題も誠実に向き合う
• エラーでは、起きたこと、影響、次にできることを示します。 出典: Honest Dialogue — 感情も問題も誠実に向き合う
• 重要な条件、費用、公開範囲、取消し可否は、決定前に確認できる位置へ置きます。 出典: Give First — 価値も愛も出し惜しみしない
• 規則には、守る目的、適用範囲、確認方法を持たせます。 出典: 2.4 哲学を検証可能にする
• 見出しだけを追っても、話の順序と結論が分かるようにします。 出典: 3.1 言葉は判断を助ける
• 操作名は「保存」「削除」「記録を見る」のように、起きることを動詞で表します。 出典: 3.1 言葉は判断を助ける
• 事実、推定、例、提案、目標値を、文言と構造で区別します。 出典: 3.2 情報の確度を見分けられるようにする
• 必要に応じて出典、基準日、単位、対象範囲、算出方法を示します。 出典: 3.2 情報の確度を見分けられるようにする
• AIの提案は未確定であること、編集・採用・拒否できることを示します。 出典: 3.2 情報の確度を見分けられるようにする
• CQ-01 読み手、理解・判断・行動の目的、前提知識、閲覧方法、対象範囲を整理し、説明の順序・深さ・情報密度を選びます。判断を求める場合は、今回決める事項と未決事項を区別します。 出典: 内容品質の共通条件
• CQ-02 判断に影響する主張には追跡可能な根拠を対応させ、根拠から結論に至る理由と成立条件を説明します。未確認事項は明示し、主張を根拠の対象・期間・精度より広げません。 出典: 内容品質の共通条件
• CQ-03 比較では評価軸、単位、母数、期間、対象の条件を揃えるか、比較できない違いを明示します。実績と予測、意向と行動、変動と確認できた変化を区別します。 出典: 内容品質の共通条件
• CQ-04 提案・選定では必須条件と比較観点を分け、実質的な代替案と不採用理由、重要な弱点・依存条件を説明します。選択肢が指定済みの場合は、その制約を明示し、架空の比較を作りません。 出典: 内容品質の共通条件
• CQ-05 要約・見出し・図表に短縮しても、判断を変える留保や反対の証拠を隠しません。根拠が足りない場合は不足と、それによって判断できない範囲を示します。 出典: 内容品質の共通条件
• CQ-06 実行を求める提案では、行動、担当、時期、成功の確認方法を示すか、未決の項目を明示します。承認されていない役割や期限を確定事項にしません。 出典: 内容品質の共通条件
• CQ-07 説明・分析・提案の重要な用語と指標は、意味、適用範囲、単位・期間・比較基準を揃えます。同義語の使い分けと同じ語の異なる意味を点検し、区別に理由がある場合は明示します。「拡大」「急増」「有効」などの評価語には根拠と成立条件を定め、根拠のない閾値を作りません。 出典: 内容品質の共通条件
• 読者・目的・前提知識・閲覧方法は、まず会話・資料・利用場面から判断します。重要な仮定と構成の選択理由を必要な範囲で記録し、判断材料がない重大な分岐だけ第12.3節に従って質問します。読者の肩書きだけで知識量や必要な説明を決めません。 出典: 読者と用途に応じた内容設計
• 視覚的な順序と、出力形式が持つ構造上の読み順・読み上げ順を一致させます。 出典: 3.3 一つの面に一つの中心目的を置く
• 画面、Dialog、スライド、文書ページ、図表には中心となる問いまたは行動を一つ置きます。 出典: 3.3 一つの面に一つの中心目的を置く
• 通常文字は4.5:1以上、大きな文字と情報理解に必要なUI境界は3:1以上のコントラストを確保します。 出典: 3.4 色は名前ではなく意味で管理する
• 色へ文言、形、アイコン、位置の少なくとも一つを併用します。 出典: 3.4 色は名前ではなく意味で管理する
• 破壊とエラーは赤系、警告はオレンジ系、通常情報と選択はLiberka greenを使います。 出典: 3.4 色は名前ではなく意味で管理する
• Page Titleは、その面で最も高い文字の視覚的優先度とコントラストを持ちます。 出典: 3.5 見出しは大きさとコントラストで階層を作る
• 見出しレベルを飛ばさず、見出しだけを読んでも構成を理解できる文言にします。 出典: 3.5 見出しは大きさとコントラストで階層を作る
• 書体、文字寸法、行間は対象媒体の規範とtokenから選び、別媒体の本文用設定を機械的に流用しません。 出典: 3.6 文字は長く読めることを優先する
• 数値比較では桁、単位、小数点を揃え、必要に応じて等幅数字を使います。 出典: 3.6 文字は長く読めることを優先する
• 関連するラベルと値は近づけ、異なる判断は広く離します。 出典: 3.7 余白は関係を説明する
• 花形をLiberka共通シンボルとして、brand/liberka.mdの資産と余白規則に従って使います。 出典: 3.9 ロゴとブランド名を混同しない
• 公式ロックアップが必要な場所では画像資産を使います。 出典: 3.9 ロゴとブランド名を混同しない
• 通常文章中のブランド名は正確にLiberka、Schediaと綴ります。 出典: 3.9 ロゴとブランド名を混同しない
• 状態を持つ成果物では、現在の状態、完了したこと、未完了のこと、次にできることを区別します。 出典: 3.10 状態と次の一歩を隠さない
• 対象者と利用環境に応じ、読み順、代替説明、識別、理解、必要な操作を最終出力で確認します。 出典: 3.11 アクセシビリティは後付けにしない
• AI提案、人の確認、確定、実行中、実行済み、失敗を区別します。 出典: 3.12 AIは責任と確度で示す
• 外部送信や重要な変更は、実行前に対象、内容、相手、結果を確認できるようにします。 出典: 3.12 AIは責任と確度で示す
• AIが利用不能でも、人が確認、編集、実行できる安全な経路を残します。 出典: 3.12 AIは責任と確度で示す
• 信頼できる: 事実、推定、提案、未確定を区別します。 出典: 3.13.1 ブランド人格
• 前へ進める: 過度に鼓舞せず、現実的な次の一歩を示します。 出典: 3.13.1 ブランド人格
• エラーは謝罪だけで終わらず、起きたこと、影響、次にできることを示します。 出典: 3.13.2 言葉の原則
• AIの提案は断定せず、編集、採用、拒否できることを示します。 出典: 3.13.2 言葉の原則
• 破壊的操作とエラーは赤系、警告と注意はオレンジ系で示します。 出典: Liberka Core palette
• 通常情報、選択、成功は製品プロファイルの主色で示します。 出典: Liberka Core palette
• 色だけで意味を伝えず、文言、形、アイコン、位置の少なくとも一つを併用します。 出典: Liberka Core palette
• 通常文字は4.5:1以上、大きな文字と情報理解に必要なUI境界は3:1以上を基準とします。 出典: Liberka Core palette
• 半透明面、画像、映像、動く背景の上の文字は、最も読みにくい状態で検査します。 出典: Liberka Core palette
• 印刷、グレースケール、投影、画面共有でも重要な区別を失いません。 出典: Liberka Core palette
• 本文、操作、図表、注釈に必要なウェイトと字形が揃うことを確認します。 出典: 4.2 タイポグラフィ
• 階層は、面の明度、全周境界、余白、重なり、背景の抑制で示します。 出典: 4.5 境界と奥行き
• 左右・上下の配置だけへ順序を依存させず、読み上げ順と一致させます。 出典: 5.2 読む順序
• 複数ページでは、現在地、全体量、次の遷移先を必要に応じて示します。 出典: 5.2 読む順序
• 対象成果物、版またはcommit、媒体、主要な利用経路、確認者、確認日、確認環境を記録します。 出典: 12.1 対象と判定
• 該当する共通原則、Component、Layout / Flow、製品条件を特定し、それぞれの仕様から確認項目を選びます。 出典: 12.1 対象と判定
• 各項目を合格・不合格・未確認・対象外で記録し、対象外には理由を添えます。未確認を合格に含めません。 出典: 12.1 対象と判定
• 合格には再現手順、期待結果、実際の結果、証拠を添えます。自動検証と実際の最終出力の確認を区別します。 出典: 12.1 対象と判定
• 制作前に共通規範・媒体・製品・使用部品から必須条件と禁止事項を列挙し、制作後は同じ項目を最終成果物で確認します。 出典: 12.3 実施と記録
• 最終判定では禁止事項を独立して再点検し、不適合を修正した後に影響範囲を再検査します。検査後に変更した成果物へ以前の合格を流用しません。 出典: 12.3 実施と記録
• 自動検査の合格は、その検査が実際に観測した対象・状態・範囲に限定します。意味・事実・読み順・未操作状態の確認を自動検査で代替しません。 出典: 12.3 実施と記録
• Webは第9章の代表幅、200%拡大、400%相当の再配置、Reduced Motion、forced-colorsと、使用Componentの必要状態を確認します。 出典: 12.3 実施と記録
• 性能へ影響する変更では、同じ端末・通信・データ条件で変更前後を比較し、測定値と採用した性能予算を記録します。予算や比較結果が未定なら合格にしません。 出典: 12.3 実施と記録
• 最終出力の確認には、実際に配布または公開する版を使用します。 出典: 12.3 実施と記録
• 制作前と監査で情報不足を見つけた際は、既存の会話・提供資料・適用規範を確認し、調査で補える情報と利用者の判断が必要な情報を分けます。情報の充足確認は質問の実施を意味しません。 出典: 情報の充足確認と自律的な進行
• 未確認の事実・数値・社内決定を仮定で確定させません。重要な分岐の回答待ちや根拠不足が解消しない部分は未確定の草稿とし、沈黙を同意と扱いません。自律的な進行は、公開・破壊的操作等に必要な権限や承認を代替しません。 出典: 情報の充足確認と自律的な進行
• 自動検査で警告された候補は、該当箇所を確認して修正または適用しない理由を記録します。警告の件数だけで不合格にせず、警告なしを内容合格にしません。 出典: 内容検査の判定境界
• 根拠の十分性・正確さ、推論の妥当性、比較の公平性、重要な反証、要約による意味の保持は内容レビューで確認します。AIの評価だけを事実確認の証拠にしません。 出典: 内容検査の判定境界
• 文書・スライドの原稿を短縮、分割、並べ替え、図表化する場合は、重要な成立条件・未決事項・根拠の掲載先を追跡し、編集後の実文と照合します。情報の存在だけで意味の保持を合格にしません。各候補の構成変更を原稿の関係・参照へ反映します。 出典: 制作前原稿と監査・改善ループ
• 文書・スライドは、全体構成、用語・指標、制作前原稿、内容監査、制作、最終出力監査の順に進めます。全体構成では各単位が目的にどう寄与するか、前提・理由・具体化・比較・反証・結論などの関係を確かめます。隣接しているだけの項目を論理的につながっていると扱いません。 出典: 制作前原稿と監査・改善ループ
• 内容監査では、全体の問いへの回答、根拠から主張への推論、単位間の重複・欠落・矛盾、用語・数値・留保の一貫性、読み手が理解・判断できる順序を別々の観点で確認します。最終出力では原稿との意味の一致と実際の表示を確認します。 出典: 制作前原稿と監査・改善ループ
• 指摘には対象と版、該当条件、問題と読み手への影響、修正内容、再確認範囲、再確認の証拠と結果を残します。根拠不足は調査、論理の欠落は構成、表現の問題は原稿または制作へ戻し、修正後に再監査します。反証や未確認事項を削除して合格にしません。 出典: 制作前原稿と監査・改善ループ
• 用語定義の変更は全使用箇所、結論の変更は要約・根拠・提案、数値や図表の変更は参照箇所へ影響をたどり、該当する判定を再開します。原稿から出力を再生成し、影響部分を確認するまで以前の合格を流用しません。 出典: 制作前原稿と監査・改善ループ
• 完了は監査回数ではなく、適用される必須条件の不合格・未確認がなく、重要な不整合が解消し、変更の影響範囲が再確認されていることで判断します。情報・手段が不足する場合は残件を明示した草稿とします。AI同士の合意や自己採点の反復は根拠の検証を代替しません。 出典: 制作前原稿と監査・改善ループ
• 文書・スライドの本制作前に、内容・論理・視覚表現・背景演出・読者の理解の各観点から、採用案を崩しうる最も強い指摘とその根拠を記録します。修正または維持の判断と理由を示し、修正が必要な指摘は原稿へ戻し、影響範囲を再確認します。攻撃的な検討は案に向け、人への侮辱には向けません。 出典: 原稿を批評してから変換する
• 原稿には実文・根拠・前後関係に加え、視覚表現の検索候補と不採用理由、背景、読む順序、強調、情報密度の理由、素材の対応を記録します。代表ページは現行原稿の入力から試作し、その検討を経て全量変換へ進めます。 出典: 原稿を批評してから変換する
• 本制作への変換で主要な文言・論理・構図を選び直す必要が出た場合は、原稿を未確定へ戻して修正・再監査します。最終描画の検査は省略せず、一度の生成で必ず完成することを保証しません。 出典: 原稿を批評してから変換する
• 文書・スライドの本文を確定する前に、各内容単位について読者の作業、図から読み取る答え、視覚で説明する内容と残す本文・補足へ移す内容を決めます。視覚中心の場合は主図と補助素材を実際の原稿nodeへ結び付け、文字中心の場合はその適用理由を記録します。表紙・扉は内容単位と分けて扱います。 出典: メッセージと主図を同時に設計する
• 原稿監査では、図の有無とは別に、配置・長さ・包含・接続等が何を伝えるか、図と本文が同じ説明を重ねていないか、図がなくても同じ文章一覧のままではないかを確認します。主図の説明機能をアイコン・ハイライト・月桂冠だけで満たしたとしません。図へ移した重要な条件を消しません。 出典: メッセージと主図を同時に設計する
• 資料全体で、文章中心の単位、同じ表現の連続、説明を担わない装飾への偏りを確認し、変更または維持の根拠を原稿へ戻します。固定の図数・文字数・画像比率は合格条件とせず、記録の充足と意味・見た目の妥当性を別々に判定します。 出典: メッセージと主図を同時に設計する