第5章　人間は、足りないものを勝手に補う

画面の構造が伝わるか不安になると、境界線を加えたくなります。カードを枠で囲み、その中の項目を別の枠で囲み、さらにセクション全体へ背景を置く。気づけば、四角の中に四角が重なっています。

しかし、人は描かれた線だけから構造を見ているわけではありません。距離、整列、類似、見出し、輪郭の一部、共通の領域から、まとまりや形を知覚します。境界がなくても構造が見える場合があります。

反対に、境界を消せば洗練されるわけでもありません。入力欄、ボタン、フォーカス、選択状態の識別に必要な境界まで消せば、操作できる場所や状態が分からなくなる可能性があります。

本章では、「枠を減らす」を目標にしません。

章題の「補う」が直接指す中心例は、閉合と遮蔽補完です。共通領域は同じ領域内の要素をまとめる手がかり、図と地は対象と背景の組織化であり、どちらも「足りない線を補う現象」として一括しません。似た Web 表現へ複数の概念名を貼ってしまわないため、あえて同じ章で違いを比べます。

この境界は、何を分けるためにあるのか。境界がなくても、その関係は既に何から見えているのか。

この章の必修は三つです。

1. 見える境界と、それが分ける関係を指す
2. 閉合、共通領域、図と地を区別する
3. 境界を一つだけ変え、知覚・課題・操作への影響を確かめる

この章で見るもの

• 実際に描かれた輪郭と、補って見た輪郭
• 同じ領域に入ることで見えるまとまり
• 前景と背景の分かれ方
• 境界線、背景、影、間隔が示す別々の関係
• モーダルの視覚的な前景化と操作上のモーダル性
• 境界を消したときに失われる状態・操作の手がかり

5.1 欠けた円と、隠れた物体

円の輪郭が何か所か欠けていても、一つの円として見えることがあります。四つの角だけが描かれた四角形を見て、描かれていない辺を含む形としてまとめる場合もあります。

一方、長い長方形の中央が帯で隠れているとき、左右に別々の長方形があるのではなく、帯の背後へ一つの物体が続いていると知覚することがあります。

この二つは、どちらも「見えていない部分を補う」と説明できますが、同じ現象ではありません。

閉合

離れた輪郭要素や欠けた輪郭が、まとまりのある閉じた形として知覚される傾向です。輪郭の配置、良い連続、対称性、既知の形等も関わります。

遮蔽補完

物体の一部が別の面に遮られているとき、遮蔽物の背後にも物体が続く構造として知覚することです。背後の部分を実際に見ているわけではありません。物体の連続性を推定しています。

図 F01 では、次の三つを線種で分けます。

1. 実際に描かれている輪郭
2. 観察者が形の構造として推定した輪郭。感覚上の線が実際に描かれて見えるという意味ではない
3. 遮蔽物の背後へ続くと推定した部分

「脳が勝手に全部描いてくれる」という説明にはしません。何が実際に見え、何を構造として推定したかを分けます。

5.2 全部を囲まなくてもカードは見える

文化祭の出演者情報が三つ並んでいます。画像、出演者名、時刻、説明、詳細リンクからなるまとまりです。カードの境界線がなくても、カード間の距離がカード内部の距離より大きく、同じ配置が反復していれば、三つのまとまりは見えるかもしれません。

そこへ背景、境界線、影を加えると、まとまりの手がかりは増えます。

間隔

カード内部を近づけ、カード間を離すことでまとまりを示します。第2章の近接です。

背景

同じ面色の上に置くことで、一つの領域を作ります。周囲との色差、面積、形、余白によって見え方が変わります。

境界線

領域の外周を線で示します。隣接する面との差が小さい場合や、操作領域を明確にしたい場合に役立つことがあります。

影

面の前後関係や浮き上がりを示す表現として使われます。しかし、影があれば必ずクリック可能、浮き上がりが強ければ必ず重要、とは言えません。製品内の反復と操作結果を確認します。

図 F02 では二つの比較を分けます。

• 個別比較: 同じ基準画面へ背景だけ、境界線だけ、影だけを加える
• 累積比較: 間隔→背景→境界線→影と手がかりを重ねる

累積比較で最後の案が最良だとは限りません。どの段階でカード単位が見えたか、どの段階で境界が過剰に感じられたか、クリック可能性の予測が変わったかを別々に記録します。

カードが見えることと、押せることは別である

一つのまとまりに見えても、カード全体が操作可能か、詳細リンクだけが操作可能かは分かりません。ホバー、フォーカス、カーソル、文言、HTML、操作領域、操作結果を確認します。共通領域は、操作可能性の意味を自動では作りません。

5.3 閉合、共通領域、図と地を区別する

閉合、共通領域、図と地は、いずれも「まとまりが見える」場面で紹介されがちです。しかし、説明する現象は異なります。

閉合――輪郭から形をまとめる

欠けた輪郭や離れた輪郭要素が、閉じた形として組織化される現象を扱います。

共通領域――同じ領域内の要素をまとめる

同じ境界領域の中にある要素が、近接や類同とは別の手がかりによって同じまとまりとして知覚される現象です。Palmer が 1992 年に、近接等へ還元できない Grouping Principle として論じました。

囲みを加えたら必ず近接より強くなる、という固定順位ではありません。領域がどう知覚されるか、入れ子、Depth、配置等の条件があります。

図と地――対象と背景を組織化する

形を持つ対象として知覚される側と、その背後に続く背景として知覚される側へ分かれる現象です。図側は輪郭を持つ対象として見え、地側は背後へ続くように見える場合があります。

Web 用語へ直結させない

次の対応を暗記しません。

• カード＝閉合
• 境界線＝共通領域
• モーダル＝図
• 背景の覆い＝地

カードのまとまりは、近接、類同、整列、共通領域などで説明できる場合があります。モーダルを前景として見る説明に図と地を候補として使えても、モーダルの操作規則は知覚心理学からは決まりません。

名前は、画面へ貼る正解ラベルではありません。どの現象を説明しているかを限定するために使います。

5.4 四角の中に四角が増えていく理由

管理画面を作っているとします。ページ全体に背景を置き、セクションをカードで囲み、その中の設定グループを枠で囲み、各入力欄にも境界線があり、補足情報をバッジで囲みます。

境界を加える理由は理解できます。

• 構造をはっきりさせたい
• 部品の範囲を示したい
• クリック可能に見せたい
• 情報を整理して見せたい
• 実装単位と視覚単位を一致させたい

しかし、境界が増えると、それぞれの強さが競合します。セクション、カード、グループ、入力欄がすべて同じ太さ、線種、コントラスト、角丸なら、どの階層が大きいのか分かりにくくなる可能性があります。境界には本数だけでなく、線の太さ、明度差、連続／破線、角の形、面の広がり、影のぼけとずれ、周囲の空間という造形語彙があります。

DOM の入れ子を全部見せない

DOM 上のコンテナすべてに背景や境界線を付ける必要はありません。実装上のラッパー、レイアウトコンテナ、意味上のセクション、知覚されるまとまりは別です。

図 F04 では、外形数の少なさを競うのではなく、意味階層ごとにどの境界語彙を割り当てたかを比べます。次の三つを別 Overlay にします。

1. DOM の入れ子
2. 画面に見える境界
3. 情報の意味上の階層

三つが完全に一致しないこと自体は問題ではありません。利用者に必要な構造が、適切な手がかりで伝わるかを見ます。

外形数だけで「カードだらけ」を判断しない

カードが多くても、比較単位が明確で、状態と操作が伝わり、高密度な監視課題に合う場合があります。境界線が少なくても、距離と見出しの関係が曖昧なら構造は伝わりません。

「四角が多い」は観察です。問題仮説にするには、何の階層が競合し、どの課題を妨げるかを書きます。

5.5 モーダルを前景化する表現と、操作上のモーダル性

発展――知覚の比喩だけで実装を決めないための HCI 節です

モーダルダイアログを開くと、ダイアログが前景に置かれ、元のページは背景の覆いで暗くなることがあります。背景の覆いの明度差、ダイアログの影、位置、周囲の遮蔽は、ダイアログを前景として見る手がかりになります。

しかし、背景の覆いが暗いことと、操作がモーダルであることは別です。

視覚的な前景化

• 背景の覆いの明度・色
• ダイアログと背景のコントラスト
• 影や輪郭
• 位置と大きさ
• 背景のぼかし

これらは前景と背景の分離へ関わります。ただし、背景の覆いを濃くすれば必ず重要に見える、ぼかせば必ず集中できる、という法則ではありません。内容、文化、テーマ、表示環境も関わります。

モーダルな操作契約

• 開いたとき、適切な要素へフォーカスが移る
• Tab／Shift+Tab でダイアログ内を操作できる
• 外側の内容が操作不能になり操作できない
• Escape または明示的なボタンで閉じられる
• 閉じた後、原則として開いた要素へフォーカスが戻る
• ダイアログにアクセシブルネームがある
• 背景スクロールとダイアログ内スクロールを意図どおり扱う

aria-modal="true" や背景の覆いだけで、これらが自動的に実装されるとは限りません。aria-modal は支援技術へモーダルであることを伝える状態であり、外側を実際に操作不能にしたりフォーカスを管理したりする実装ではありません。ネイティブの dialog.showModal() はトップレイヤーへの配置、モーダル状態、外側の操作不能化などをブラウザが扱う基準候補です。トップレイヤーは単に非常に大きな z-index を指定した状態ではありません。

制作者は、開いた要素、アクセシブルネーム、内容に合う初期フォーカス、閉じるボタン、cancel／close イベントへの方針、破壊的操作の安全性、閉じた後の作業の流れを設計します。フォーカスは通常、開いた要素へ戻しますが、開いた要素が消えた場合や次の作業点が明確な場合は論理的な別位置を選びます。Escape による閉じる要求を許すか、未保存内容をどう扱うかも明記します。

図 F05 では、背景の覆い／影／ぼかしを比べる視覚系列と、ポインター／キーボード／支援技術で開閉する操作系列を別図にします。視覚系列は前景報告、操作系列はフォーカス、外側操作、閉じる、復帰を測り、同じ「集中できた」へまとめません。

フォーカス位置は常に最初のボタンではない

短い確認なら主要または安全な操作へフォーカスする案があります。長い説明やリストを先に理解する必要があるなら、先頭の静的な見出しへ tabindex="-1" を与えてフォーカスする案があります。不可逆な削除では、最も破壊的でない操作を初期フォーカスにする案もあります。

一つの固定手順ではなく、ダイアログの内容と課題から決め、ポインター、タッチ、キーボードのみ、スクリーンリーダー＋キーボードを別シナリオで確かめます。長文ダイアログでは、ダイアログ内部だけを意図どおりスクロールでき、背景は操作中にスクロールせず、閉じた後に元の背景位置へ戻ることを期待値として記録します。モバイルのビューポートは別条件にします。入れ子のダイアログは基準から除外します。

5.6 見えている構造を重ねて説明しない

境界を加える前に、既に働いている手がかりを書きます。

近接で見えている

ラベルと入力欄が近く、次の項目までが十分に離れているなら、各項目へ個別境界線を追加しなくてもまとまりが見えるかもしれません。

整列で見えている

同じ左端と列を共有する情報は、外周を囲まなくてもリストとして追える場合があります。

類同で見えている

同じ役割のカードが同じ画像比率、タイポグラフィ、配置を反復していれば、共通の外形が弱くても同じ種類として見えるかもしれません。

見出しと意味で見えている

明確な見出し、fieldset／legend、文章の順序が、視覚と支援技術へまとまりを伝える場合があります。

それでも境界が必要な場合

• 操作対象の範囲を示す
• 選択、フォーカス、エラーなどの状態を示す
• 密度の高い情報を比較単位へ分ける
• 背景との差が小さい領域を識別する
• ドラッグ／ドロップの対象を示す
• 内容が動的に追加・削除される範囲を示す

境界を重ねる前に、目的を一つ書きます。既に別の手がかりで伝わるなら削減候補です。役割や状態を伝える唯一の手がかりなら、単純に消しません。

5.7 境界を消すと失われるもの

「境界線を消すとすっきりする」という変更は、通常のスクリーンショットだけでは成立して見えるかもしれません。状態と表示条件を変えると、失うものが見えます。

入力欄と背景の区別

入力欄の背景が周囲と同じで境界線もなければ、入力位置を見つけにくい場合があります。プレースホルダーだけを境界の代わりにすると、入力後に手がかりが消えます。

ボタンの操作範囲

文字だけのボタンは文脈によって成立しますが、隣接する文字やリンクと区別できる必要があります。見える外形と操作領域は別なので、境界線を残せば対象サイズが十分になるわけでもありません。

フォーカスと状態

通常の境界線を消しても、明確なフォーカス表示が別にあればキーボードフォーカスは示せます。反対に、フォーカス時の境界線まで消せば現在位置を失う可能性があります。選択中、エラー、無効も別状態として確認します。

コントラスト

WCAG の文字以外のコントラストは、すべての装飾境界線に一律の比率を要求するものではありません。利用者が部品や状態を識別するために必要な視覚情報が対象になります。どの境界が必要情報かを特定し、隣接色とのコントラストを確認します。

強制色

制作者の背景や影が置換・抑制される環境では、通常テーマで成立した面の差が失われる場合があります。システム色、境界線、文字、ネイティブ部品を使い、Windows 強制色の実環境でも確認します。

アクセシビリティは、境界を増やす理由の一覧ではありません。誰が、どの環境で、何を識別し、何を操作するかという条件です。

5.8 問い――このカードには何枚の枠が必要か

文化祭の予約確認画面を観察します。セクション、予約内容カード、各項目、エラーメッセージ、主要操作に境界があります。

観察条件

• 人：初めて予約内容を確認し、間違いがあれば修正する人
• 課題：日時、会場、人数を確認し、誤った人数を修正して予約する
• 基準：1280 CSS px、マウス、通常状態
• 派生：390 CSS px、キーボードフォーカス、エラー、Windows 強制色を一軸ずつ

本章の操作モデルでは、日時、会場、人数は静的な確認文字として表示し、各項目に独立した「変更」ボタンを置きます。人数の変更ボタンを押すと、人数入力と保存／キャンセルを持つ編集領域が開きます。カード全体はクリック可能にしません。エラー文は人数入力へプログラム上も関連づけ、状態変化の通知とフォーカス位置を検証します。

問い

1. 画面に見える境界を数え、それぞれが何を分けるか書いてください。
2. 境界がなくても構造を示している手がかりは何ですか。
3. 閉合、共通領域、図と地のどれで説明できる現象ですか。説明できないものは何ですか。
4. 一つだけ境界を除く、または加えるならどれですか。
5. 変更によって何が見えやすくなり、何を失う可能性がありますか。
6. 知覚、課題、操作、実装でどう確かめますか。

答えの例

1. 境界と関係を指す

ページ背景と予約セクションの面差、予約カードの境界線、カード内の各項目境界線、エラーの境界線、主要操作の外形があります。予約カードの境界線は予約内容全体を、項目境界線は日時・会場・人数を個別に分けています。

2. 既存の手がかりを見る

各項目は見出しと値が近く、次項目までの距離が広いです。見出しのタイポグラフィと左端も反復しています。項目境界線がなくても、近接、整列、類同から三項目の境界が見える可能性があります。

3. 概念を限定して使う

予約カードの同じ面色と外周は、カード内要素を共通領域としてまとめる説明候補になります。項目境界線を外してもカードの形が閉合によって補われる、と断定する必要はありません。モーダルではないため、図と地だけで予約確認の操作を説明することもできません。

4. 一つの変更仮説

予約カードとエラー境界線は固定し、通常項目の個別境界線だけを除くと、予約全体とエラーの境界を保ちながら、階層の競合を減らせるのではないか。

5. 失うものを残す

項目と独立した変更ボタンの所属が分かりにくくなる可能性があります。カード全体は操作できないという規則を保ち、変更ボタンの範囲、文言、ホバー、フォーカス、アクセシブルネームを確認します。人数のエラー状態で、エラーの所属が距離と文言から伝わるかも見ます。

6. 確かめ方

知覚課題では、どこからどこまでを一つのまとまりとして見たかを記録します。確認課題では、日時・会場・人数を正しく読み、誤った人数を発見できたかを主要指標にします。修正課題では、編集操作を見つけて予約を完了できたかを主要指標にし、誤操作と時間を補助指標にします。

マウス、タッチ、キーボードを別試行にします。キーボードではフォーカス順と表示を確認します。エラー状態では、入力とのプログラム上の関連、状態メッセージなどによる通知、エラー発生時にフォーカスを移すか維持するかを分けます。強制色では面色が変わっても境界と操作を識別できるかを実環境で確認します。基準と派生状態を同時に変えません。

境界を減らす判断表には、線、面、影、空間を分けて実際の結果を残します。

表現意図も別欄に残します。静かな文化施設の案、速報性を持つイベント案、高密度な業務案では、同じ情報階層でも線質、面積、空間、影の調子が異なり得ます。機能条件だけで造形案を一つに決めません。

別の答え方

高密度な業務画面なら、項目境界線を残す方が比較しやすい場合があります。境界線を消す代わりに、予約カードの背景差を弱め、項目の列構造を強くする案もあります。

エラー境界線が他の通常境界線と似すぎているなら、通常境界線を減らすことでエラーを見つけやすくなる可能性があります。一方、色だけに依存せず、エラー文とアイコン、関連づけ、フォーカスも必要です。

よくある考え方

カードが多くてダサいので、境界線と影を全部消します。

この考え方の注意点

どの境界が何を分け、何が既に別の手がかりで伝わり、何を失うかが書かれていません。すべてを一度に消せば、どの変更が結果に関係したかも分かりません。

次のように書きます。

項目境界線と予約カード境界線が同じ強さで、項目と予約全体の階層差が外形に表れていない。カード境界線とエラーは固定し、通常項目境界線だけを除くと、近接と見出しで項目を保ちながら、予約全体の境界を強く読めるのではないか。

必須セルフチェック

• 見える境界と、それが分ける関係を指したか
• 閉合、共通領域、図と地を区別したか
• 境界を一つだけ変え、知覚・課題・操作への影響を確かめたか

発展セルフチェック

• 境界線、背景、影、間隔を同じ「枠」にしていないか
• 実装コンテナのすべてを視覚化していないか
• カードのまとまりとクリック可能範囲を分けたか
• モーダルの背景の覆いと操作上のモーダル性を分けたか
• フォーカス、エラー、200% 文字、強制色を確認したか
• 境界を減らすこと自体を美的正解にしていないか

次章へ

境界や面は、構造を示す静的な手がかりです。しかし、画面内で何かが動けば、境界の強さに関係なく注意を奪う場合があります。動きは状態変化や空間関係を伝える一方、自動再生や反復によって課題を妨げる可能性もあります。

次章では、動きの有無ではなく、面積、速度、距離、方向、反復、目的を分けて観察します。

参考資料

• 入口: York University, “Max Wertheimer, Laws of Organization in Perceptual Forms（英訳）.” 閉合を含む古典的な知覚的組織化の原典英訳です。
• 発展: Johan Wagemans et al., “A Century of Gestalt Psychology in Visual Perception I,” 2012. 閉合、輪郭や面の補完、図と地を含むレビューです。
• 論文: Stephen E. Palmer, “Common region: A new principle of perceptual grouping,” 1992. 共通領域を近接や閉合から区別した研究です。
• 仕様: WHATWG, “The dialog element.” ネイティブダイアログ、showModal()、トップレイヤー、操作不能状態などの定義を確認します。
• 技法: W3C WAI, “H102: Creating modal dialogs with the HTML dialog element.” HTML dialog を使ったモーダルの技法です。WCAG の唯一の必須実装ではありません。
• パターン: W3C WAI-ARIA APG, “Dialog (Modal) Pattern.” フォーカス、キーボード、役割の実務的な参考です。規範的標準そのものではありません。
• 公式解説: W3C WAI, “Understanding Non-text Contrast.” 部品と状態を識別する視覚情報のコントラストを確認します。
• 仕様: W3C, “CSS Backgrounds and Borders Module Level 3.” 背景、境界線、影の仕様です。

検索キーワード：閉合 知覚、amodal completion occlusion、common region perceptual grouping、figure ground organization、HTML dialog showModal inert、modal dialog focus management、non-text contrast border