アフォーダンス

ボタンやリンクは、見ただけで押せる・たどれると伝わらなければならない。逆に、操作できないものが操作できそうに見えてもいけない。ここでは、その手がかりをどう設計するかを、概念から本チームの規約まで通して定める。

アフォーダンスとシグニファイア

混同しやすいが、2 つは別の概念である。

• アフォーダンスとは、対象が持つ「その操作が可能であること」そのものである。たとえばボタンには「押せる」という性質がある。
• シグニファイアとは、その操作が可能だと利用者に知覚させる手がかりである。形・色・影・カーソルの変化・ラベルなどが該当する。

物理的なボタンは、出っ張りという形そのものが「押せる」を伝える。一方、画面上の要素は実体を持たないため、操作の可能性が自動では伝わらない。そこで、意図的なシグニファイア（押せそうな見た目、ホバーでの変化、フォーカスの輪郭など）を与えて、知覚されるアフォーダンスを作る。これがフラットな UI を設計するうえでの基本になる。

基本原則

• 操作できるものは、操作できるように見せる。クリックやキーボード操作が可能な要素には、それと分かるシグニファイアを必ず与える。手がかりが無いと操作可能性が伝わらない（隠れたアフォーダンス）。
• 操作できないものを、操作できそうに見せない。押せない要素がボタンのように見えると、利用者は混乱する（偽のアフォーダンス）。
• 一貫性を保つ。同じ種類の操作は、同じシグニファイアで揃える。見た目が揃っていると、利用者はどこを操作できるかを学習なしに予測できる。
• 色だけに頼らない。状態や操作可否を色の違いだけで伝えない。形・アイコン・ラベル・位置を併用する。

インタラクティブ状態のモデル

インタラクティブな要素は、次の状態をすべて設計する。状態の取りこぼしは、操作可否やフィードバックが伝わらない原因になる。

hover の動きの付け方はアニメーションに従う。focus の色やコントラストは、次の規約で扱う。

ネイティブ要素の優先

操作には意味に合ったネイティブ要素を使う。動作には button、遷移には a（Next.js では Link）を使う。ネイティブ要素は、キーボード操作や支援技術向けの role を自動で備えるため、アフォーダンスとアクセシビリティを同時に満たせる。やむを得ず非ネイティブの要素を操作可能にする場合のみ、role やキーボード操作を自前で補う。

クリック要素の pointer カーソル

ポインタを重ねたときのカーソルは、操作可否を伝える手がかりである。クリックできる要素には pointer カーソルを出す。

• button は、Tailwind v4 で既定カーソルが default に変わったため、globals.css の base で pointer を一括復元している。個別の対応は不要である。
• a（Link）は、ブラウザの既定で pointer のため対象外である。
• 非ネイティブの要素を操作可能にした場合のみ、cursor-pointer を明示的に付ける。
• 無効状態の要素には pointer を出さない（disabled や pointer-events-none で無効化する）。

可視フォーカスの常時表示

キーボードで到達した要素には、可視のフォーカス標識を出す。ring トークンを用い、focus-visible で付与する。

フォーカス標識は、それが乗る背景に対して十分なコントラストを確保する（WCAG 2.4.11）。そのため、面ごとにリング色を変える。

• 明るい面（カードや背景の上）では、ring トークン（既定のリング色）を使う。
• 色の濃い面（ブランド色のヘッダー帯など）では、背景に埋もれないよう対比する色（primary-foreground など）へ切り替える。

加えて、リングを面から少し浮かせる offset を与えると、輪郭がより読み取りやすくなる。

状態の網羅

前掲のモデルにある状態を、コンポーネントごとに設計する。とくに hover だけ実装して focus を忘れると、キーボード利用者に位置が伝わらない。disabled は、操作できないことを見た目で示しつつ、ポインタ操作を無効化する。

十分なヒット領域

操作対象は、指やポインタで狙いやすい大きさにする（WCAG 2.5.8、最小 24px 相当）。アイコンだけの操作部は、余白で領域を稼ぐ。

関連項目

• アニメーション — hover やフォーカスの動きの付け方