モーダルとは｜モードレス・ポップアップとの違いと使いどころを実測で

画面の上に何かが重なる表示には、いくつも呼び名があります。見分ける軸は「後ろの画面を操作できるか」と「相手の操作を待つか」の2つです。

flowchart TD
    S[画面の上に重ねたい] --> A{後ろを操作<br>させない?}
    A -->|はい| M[モーダル<br>確認・必須入力]
    A -->|いいえ| B{返事を待つ?}
    B -->|はい| D[モードレス<br>ダイアログ]
    B -->|いいえ| T[トースト<br>ポップオーバー]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、Python 3.13.18 の http.server を 127.0.0.1 のポートに起動し、自作のテストページ（長い本文・z-index 9999 の固定ヘッダー・<dialog>・div と z-index の自作モーダル・popover）を置きました。そのページを Chromium 153.0.8010.12（Playwright 1.63.0・Python 版）で開き、PC 幅 1200×800 とスマホ幅 375×667 で、showModal()・show()・自作 div（対策なし／inert と overflow の対策あり）・closedby="any"・popover（auto／manual）・alert／confirm／prompt を開き、フォーカスの移り先、Tab の順、座標でクリックしたときに反応した要素、ホイールでの背景のスクロール量、::backdrop、Esc と外側クリック、支援技術に渡るアクセシビリティツリー（Chrome DevTools Protocol の Accessibility.getFullAXTree）を計測しました。言葉の定義は MDN・WAI-ARIA Authoring Practices Guide・Apple の Human Interface Guidelines で確かめています。図は mermaid 11.16.0 で描画を確かめました（確認日 2026年10月29日）。

モーダルとは（意味と語源）

この節では、モーダルという言葉の意味と、なぜ「モーダル」と呼ぶのかが分かります。

モーダル（modal）とは、「ある操作を終える（または取り消す）まで、他の操作ができない状態」のことです。 語源は mode（様式・状態）で、「モードを持つ」が直訳です。Web やアプリの文脈では、画面の上に重ねて表示され、閉じるまで後ろの画面を操作できないウィンドウやダイアログを指して「モーダル」「モーダルウィンドウ」「モーダルダイアログ」と呼びます。Apple の Human Interface Guidelines は、モダリティを「専用のモードでコンテンツを表示して利用者の注意を集めるデザイン手法で、親ビューを操作できず、明示的な操作をしないと閉じられない」と定義しています。

厳密には、モーダルは「状態」の名前で、ダイアログは「部品」の名前です。モーダルなダイアログもあれば、モーダルでない（モードレスの）ダイアログもあります。ただ、Web の記事や会話では「モーダル」だけでモーダルダイアログを指すことが多く、この記事でもそう使います。

IT 以外の「モーダル」

検索すると、UI 以外の意味も混ざって出てきます。この記事は UI のモーダルの話ですが、取り違えないように並べます。

モーダルとモードレスの違い

この節では、モーダルとモードレスを分ける1つの基準と、それぞれの向き不向きが分かります。

違いは「表示している間、後ろの画面を操作できるか」だけです。 できなければモーダル、できればモードレスです。見た目（中央に出る・暗い背景がある）では決まりません。暗い背景があっても後ろをクリックできれば、それはモードレスです。

モーダルは「利用者の手を止める」仕組みなので、必要なときだけ使います。使いすぎると、確認を読まずに OK を押す癖がつき、本当に止めたいときに止められなくなります。

ダイアログ・ポップアップ・トースト・ポップオーバーとの違い

この節では、似た言葉を「後ろを操作できるか」「返事を待つか」「どう閉じるか」で整理した表が分かります。

言葉の使い方はチームや製品ごとに揺れますが、次の表の軸で分けると迷いません。 「ポップアップ」は「重ねて出す表示」全般を指す広い言葉で、別ウィンドウで開く広告も、ページの中に重ねるお知らせも含みます。

HTML には、この表に対応する標準の部品が増えています。モーダルは <dialog> の showModal()、モードレスのダイアログは show()、メニューやツールチップのような「外側を押すと消える」表示は popover 属性です。MDN は、Popover API で作るポップオーバーは常に非モーダルで、モーダルにしたいなら <dialog> を使う、と説明しています。Bottom Sheets のように、デザインシステムによってモーダル版とモードレス版の両方が定義されている部品もあります。

モーダルの種類と使いどころ

この節では、モーダルがよく使われる4つの場面と、それぞれで気をつけることが分かります。

モーダルの役割は「利用者の手を止めてでも、返事や注意をもらう」ことです。 使われる場面は、おおむね次の4つに分かれます。

どの場面でも共通する決まりは、1つのモーダルに1つの目的、見出しとボタンの文言で「何が起きるか」が分かること、必ず閉じられること、モーダルの上にモーダルを重ねないこと、の4つです。入れ子については、デザインシステムによって「重ねない」か「フォーカスの管理ができていれば2段まで」かの差はありますが、「重ねないのが基本」という点は共通しています。

4つの作り方を実物で比較（showModal・show・div・alert）

この節では、同じ「確認を出す」を4通りで作り、Chromium で開いたときに何が起きたかを1つの表で比べた結果が分かります。

「モーダルらしさ」を作っているのは、見た目ではなく、フォーカスの移動・後ろの無効化・Esc・閉じたあとのフォーカスの戻りです。 <dialog> の showModal() はこれらをブラウザが行い、div と z-index で作ると自分で書くことになります。テストページで使った中心の部分です。

<!-- 1. dialog 要素（モーダル） -->
<dialog id="dlg" aria-labelledby="dt">
  <h2 id="dt">本当に削除しますか？</h2>
  <input id="dInput" placeholder="理由（任意）">
  <p><button id="dOk">削除する</button> <button id="dCancel">閉じる</button></p>
</dialog>
<script>
  openBtn.onclick = () => dlg.showModal();   // モーダル
  // openBtn.onclick = () => dlg.show();     // モードレス
  dCancel.onclick = () => dlg.close('cancel');
</script>

自作版は、全画面を覆う要素（position:fixed; inset:0; z-index:1000）の中に箱を置き、クラスの付け外しで表示します。対策なしの版は表示を切り替えるだけ、対策ありの版は次の処理を足しました。

// 2. 自作（対策あり）：表示に加えて 4 つの仕事を自分で行う
function openCustom() {
  prevFocus = document.activeElement;              // (1) 戻り先を覚える
  overlay.classList.add('open');
  for (const el of document.body.children)         // (2) 後ろを inert にする
    if (el !== overlay) el.inert = true;
  document.body.style.overflow = 'hidden';         // (3) 背景のスクロールを止める
  overlay.querySelector('input').focus();          // (4) フォーカスを中へ
}
function closeCustom() {
  overlay.classList.remove('open');
  for (const el of document.body.children) el.inert = false;
  document.body.style.overflow = '';
  prevFocus && prevFocus.focus();                  // 戻り先へ戻す
}
document.addEventListener('keydown', (e) => {       // Esc も自分で
  if (e.key === 'Escape' && overlay.classList.contains('open')) closeCustom();
});

開く前に本文の入力欄へフォーカスを置き、開いたあとに Tab を6回押し、固定ヘッダーのボタンと本文のボタンの座標をクリックし、ホイールで 600px 分スクロールし、Esc を押しました。結果です。

Tab の列の「…」は、中の最後の要素からブラウザ自体の UI へ一度移り、そのあと中の最初の要素へ戻る動きです（後ろのページには移りません）。

この表から、showModal() で足りないのは「背景のスクロール」だけだと分かります。逆に、対策なしの div は「見た目はモーダル、動きはモードレス」で、固定ヘッダーのボタンが押せてしまうなど、モーダルの条件を1つも満たしていません。

フォーカスの移動・Tab・支援技術から見えるもの（inert と aria-modal）

この節では、モーダルで最も大切な「フォーカスの扱い」と、スクリーンリーダーなどの支援技術に何が渡っているかの計測が分かります。

WAI-ARIA の Authoring Practices Guide は、モーダルダイアログの条件として、開いたらフォーカスがダイアログの中へ移ること、Tab と Shift+Tab がダイアログの中で循環すること、Escape で閉じること、閉じたら開いた要素へフォーカスが戻ること、を挙げています。 これを手元の4通りで確かめたのが前の節の表です。

支援技術に何が渡っているかは、Chrome DevTools Protocol でアクセシビリティツリーを取り出して数えました。

閉じているとき        : 79 ノード  本文のボタン1=あり  ヘッダーのボタン=あり
showModal()           : 27 ノード  本文のボタン1=なし  ヘッダーのボタン=なし  dialog modal=true
show()                : 79 ノード  本文のボタン1=あり  ヘッダーのボタン=あり  dialog modal=false
div + aria-modal=true : 80 ノード  本文のボタン1=あり  ヘッダーのボタン=あり  dialog modal=true
div + inert           : 30 ノード  本文のボタン1=なし  ヘッダーのボタン=なし  dialog modal=true
div（aria-modal なし）: 80 ノード  本文のボタン1=あり  ヘッダーのボタン=あり  dialog modal=false

• showModal() は、後ろの要素をアクセシビリティツリーから外し、aria-modal を書かなくても modal=true として伝えます。 MDN も、showModal() で開いたダイアログは暗黙に aria-modal="true" になり、show() や open 属性では aria-modal="false" として扱われる、と説明しています。
• div 版で aria-modal="true" を書いただけでは、後ろの 50 個余りの要素は支援技術に見えたままでした。APG も、aria-modal="true" は「後ろの操作をすべての利用者に対して防いでいる」ときに限って付けるべきだ、としています。見た目だけ覆って属性を付けると、スクリーンリーダーの利用者には「モーダルと言われたのに後ろが読める」矛盾した状態になります。
• inert 属性を後ろに付けると、Tab でもクリックでも触れなくなり、ツリーからも外れました。座標でヘッダーのボタンをクリックしたとき、対策なしの版ではヘッダーのボタンが反応し、inert ありの版では覆いが受けました。inert な要素はクリックの対象からも外れるためです。

開いたときの最初のフォーカスは、showModal() では中の最初のフォーカスできる要素に移りました。MDN は、最初に操作してほしい要素に autofocus を付けること、無ければ閉じるボタンかダイアログ自体に付けることを勧めています。APG は、削除のような取り消せない操作の確認では、最も破壊的でないボタン（キャンセル側）に置く考え方も示しています。

背景がスクロールする問題（showModal でも起きる）

この節では、モーダルを開いているのに後ろのページが動いてしまう原因と、2つの直し方の計測結果が分かります。

showModal() は後ろの操作を無効にしますが、ホイールやスワイプでのスクロールまでは止めません。 手元では、モーダルを開いた状態でホイールを回すと、後ろのページが 600px 動きました。長い本文の上でモーダルを出すと、閉じたときに見ていた場所が変わっている、という不具合になります。

直し方は2つを組み合わせます。1つ目は、モーダルが開いている間だけ body のスクロールを止めることです。:has() と :open を使うと JS なしで書けます。

/* dialog が開いている間だけ、後ろのスクロールを止める */
body:has(dialog:open) { overflow: hidden; }

対策なし                    : scrollY 0 → 600（ホイール 600px で後ろが動いた）
body:has(dialog:open){overflow:hidden} : scrollY 0 → 0（止まった）

2つ目は、モーダルの中が長くてスクロールするときの「連鎖」です。中を端までスクロールしてさらにホイールを回すと、後ろのページへスクロールが伝わります（スクロールチェイン）。overscroll-behavior: contain で止まります。中身を 60 段落に増やしてホイールを 12 回回した結果です。

既定                           : dialog の scrollTop 1640（端まで）→ 後ろの scrollY 1895（伝わった）
dialog{overscroll-behavior:contain} : dialog の scrollTop 1640（端まで）→ 後ろの scrollY 0（止まった）

dialog { overscroll-behavior: contain; max-height: calc(100dvh - 32px); overflow: auto; }

overflow: hidden を使うと、スクロールバーの幅の分だけページの横幅が変わり、開いた瞬間に背景が横にずれることがあります。手元の Chromium はオーバーレイ型のスクロールバー（幅 0px）だったので起きませんでしたが、Windows のように幅のあるスクロールバーでは scrollbar-gutter: stable を html に付けるとずれを防げます。

閉じ方：Esc・外側クリック・closedby・入れ子

この節では、モーダルをどう閉じるべきか、ブラウザが何を自動で行うか、外側クリックで閉じる設定の実物が分かります。

モーダルは「必ず閉じられる」ことが条件です。 APG は、閉じるための目に見えるボタン（×やキャンセル）をタブ順に含めることを強く勧めています。Esc や外側クリックは補助で、ボタンの代わりにはなりません。

• closedBy の既定値を読むと "closerequest" でした。MDN によると、closedby は any（外側クリック・Esc・自分の仕組み）、closerequest（Esc と自分の仕組み）、none（自分の仕組みだけ）の3つで、showModal() で開いたときの既定は closerequest です。外側クリックで閉じたいときは <dialog closedby="any"> と書くだけで、クリックの位置を自分で判定する必要がなくなりました。
• Esc で閉じたとき、cancel イベントの後に close イベントが発生し、returnValue は空のままでした。入力の途中で Esc を押したときに「破棄してよいか」を聞きたいなら、cancel で preventDefault() します。
• popover（auto）は、外側をクリックすると閉じると同時に後ろのボタンも押せました（light dismiss）。後ろを触らせたくない用途には向かず、メニューやツールチップのような「どいてほしい表示」に向きます。

入れ子にしたとき

モーダルの上にもう1つ showModal() で開くと、フォーカスは2つ目へ移り、1つ目のボタンは focus() しても受け付けなくなりました（1つ目も inert になる）。Esc を1回押すと2つ目だけが閉じ、1つ目は開いたままで、フォーカスは1つ目の入力欄へ戻りました。ブラウザは入れ子を正しく扱いますが、使う側の負担は増えるので、設計としては避けます。

エラーの原文

show() で開いたあとに showModal():
InvalidStateError: Failed to execute 'showModal' on 'HTMLDialogElement': The dialog is already open as a non-modal dialog, and therefore cannot be opened as a modal dialog.

showModal() を 2 回: エラーなし（開いたまま）

open 属性を直接付けて開くとモードレスになり、後ろの要素に focus() できました。MDN も、open 属性ではなく show()・showModal() を使うよう勧めています。

alert・confirm・promptとの違い（JS が止まる）

この節では、ブラウザ標準の alert()・confirm()・prompt() がモーダルとどう違うのか、計測した結果が分かります。

alert() などは、ページの JavaScript そのものを止める「同期のモーダル」です。 見た目や文言をほとんど変えられず、ブラウザによっては「このページで追加のダイアログを表示しない」が出て以後は出なくなります。手元で、ダイアログに応答するまで 300ms 待たせたときの結果です。

alert('…') が戻るまで        : 305ms（応答するまで JS が止まる）
alert 中に setTimeout(…, 10)  : alert が戻るまで発火しない
confirm → OK                 : true
confirm → Esc（キャンセル）   : false
prompt → 入力して OK          : "入力した値"
prompt → キャンセル           : null

confirm() の「はい・いいえ」を <dialog> で置き換えるときは、close('ok') のように値を渡し、close イベントで dialog.returnValue を読みます。<form method="dialog"> を使うと、ボタンの value がそのまま returnValue になります。

スマホ幅での崩れ方と直し方（375px で計測）

この節では、PC では問題なかったモーダルがスマホで「上が切れて閉じられない」「横にはみ出す」になる原因と、直した前後の数値が分かります。

原因は、モーダルの高さが画面を超えたときに、中央寄せが箱の上下を画面の外へ押し出すことです。 幅 375×高さ 667 の画面で、中身を 40 段落に増やして開きました。

• 自作版は、箱の上端が y=-519px、つまり画面の 519px 上に出ていました。箱自体はスクロールしない（overflow: visible）ので、見出しも OK ボタンも触れません。スマホで「閉じられないモーダル」になる典型です。箱に最大の高さと overflow: auto を付けると、箱の中がスクロールするようになり、ボタンに届きました。
• <dialog> は、既定で max-width と max-height が calc(100% - 38px)、overflow: auto になっていて、中身が長くても中でスクロールしました。ただし、width: 360px に padding と枠線が足されて、375px の画面で幅 383px にはみ出しました。box-sizing: border-box を付けると 337px に収まります。
• 高さの単位は vh ではなく dvh を使います。スマホのブラウザはアドレスバーの分だけ表示領域が伸び縮みし、100vh は大きい方の高さで固定されるためです。

z-index で下に隠れる・transform の親で崩れる

この節では、自作モーダルが固定ヘッダーの下に隠れたり、画面を覆わなくなったりする原因と、<dialog> が影響を受けない理由が分かります。

showModal() で開いた dialog は「最上位レイヤー（top layer）」に置かれ、ページ内のどんな z-index よりも上に出ます。 div と z-index で作ると、重なり順は z-index とスタッキングコンテキストの規則で決まり、2つの典型的な崩れ方が起きます。

2つ目は見落としやすい崩れ方です。position: fixed は普通は画面を基準にしますが、祖先に transform・filter・will-change などがあると、その祖先を基準にします。アニメーションのために親へ transform を付けた途端、覆いが画面を覆わなくなります。z-index を 999999 にしても、親のスタッキングコンテキストの中で比べられるだけで、外のヘッダーには勝てません。スタッキングコンテキストの原因の一覧は、関連記事「CSS z-indexが効かない｜スタッキングコンテキスト原因一覧」で扱っています。

フレームワークで作るときは、モーダルの要素を body 直下へ移す仕組みが用意されています。React は関連記事「React createPortalの使い方｜モーダルとz-index」、Vue は関連記事「Vue Teleportの使い方｜モーダルをbodyへ移動・defer対応」で扱っています。Next.js の App Router では、URL を持つモーダル（一覧から詳細を開いても戻るで閉じられる）を関連記事「Next.js Parallel・Intercepting Routesでモーダル実装」で扱っています。

使う場面・使わない場面の判断表

この節では、「モーダルにするか、別の見せ方にするか」を決める順番と、場面ごとの判断が分かります。

次の順に問うと、モーダルを使いすぎずに済みます。

1. 1返事をもらわないと先に進めないか → いいえならモーダルにしない保存完了・軽い案内はトーストやインラインの文言
2. 2取り消せない操作か → はいなら確認のモーダル削除・送信・決済。取り消せるなら「元に戻す」付きのトースト
3. 3後ろの画面を見ながら作業するか → はいならモードレスか別ページメール本文を見ながらの返信・検索と置換
4. 4入力が多い・何段階もあるか → はいなら専用ページスマホ幅で 1 画面に収まらない入力はページにする
5. 5モーダルの中から別のモーダルを開くか → はいなら設計を見直す重ねない。1 つにまとめるかページへ
6. 6ここまで残ったものだけモーダルにする1 つの目的・2 つまでのボタン・必ず閉じられる

よくある不具合と直し方

この節では、モーダルで起きやすい不具合を、原因と直し方の対応表で確かめられます。

• 1開いたらフォーカスが中へ移るTab を押して中の要素だけを回るか
• 2後ろをクリックしても反応しない固定ヘッダーのボタンも押せないか
• 3Esc と目に見える閉じるボタンの両方で閉じる閉じたら開いたボタンへフォーカスが戻るか
• 4後ろがスクロールしない中を端まで送っても後ろに伝わらないか
• 5375px 幅でボタンまで届くいちばん長い内容で確かめる
• 6見出しが aria-labelledby で結ばれているスクリーンリーダーが「何のダイアログか」を読めるか

コピーして使える <dialog> の完成形（開閉・Esc・外側クリック・スクロール固定・アニメーション・a11y）は、関連記事「HTML dialog要素でモーダル実装｜コピペ完成版とa11y対応」で扱っています。この記事は「モーダルとは何か・どれを選ぶか」の入口で、実装の細かい手順はそちらに任せています。

よくある質問

Q. モーダルとは何ですか？ A. 閉じるまで他の操作ができない「モード」に入る表示の仕組みです。Web では、画面の上に重なって後ろを操作できなくするウィンドウやダイアログを指します。語源は mode（様式・状態）です。

Q. モーダルとモードレスの違いは何ですか？ A. 表示している間に後ろの画面を操作できるかどうかです。できなければモーダル、できればモードレスです。見た目（中央に出る・背景が暗い）では決まりません。

Q. モーダルウィンドウとモーダルダイアログは同じですか？ A. Web の文脈ではほぼ同じ意味で使われます。厳密には「モーダル」は状態の名前、「ダイアログ」「ウィンドウ」は部品の名前です。OS のウィンドウとしてのモーダルウィンドウと、Web ページの中に重ねるモーダルダイアログを区別する人もいます。

Q. ポップアップとモーダルの違いは何ですか？ A. ポップアップは「重ねて出す表示」全般の広い言葉で、別ウィンドウの広告も含みます。モーダルはその中で「後ろを操作できないもの」です。後ろを操作できるポップアップはモードレスです。

Q. トーストとは何ですか？ A. 画面の端に数秒だけ出て自動で消える短い通知です。「保存しました」のような、返事の要らない知らせに使います。後ろは操作できるのでモードレスです。Material Design ではスナックバーと呼びます。

Q. HTML でモーダルを作るにはどうしますか？ A. <dialog> 要素を置き、dialog.showModal() で開きます。後ろの無効化・Esc・フォーカスの移動と戻り・最上位レイヤーへの配置をブラウザが行います。手元の計測では、足りないのは背景のスクロールだけで、body:has(dialog:open){overflow:hidden} を足します。

Q. div と z-index で作ってはいけませんか？ A. 作れますが、フォーカスの移動と戻り・後ろの inert 化・Esc・スクロール固定を自分で書く必要があります。手元では 17 行足して同じ挙動になりました。書き忘れると「見た目だけモーダル」になり、固定ヘッダーのボタンが押せる・Tab で後ろへ抜ける、が起きます。

Q. モーダルは SEO に影響しますか？ A. モーダルの中身も HTML にあれば検索エンジンは読めます。ただし Google 検索セントラルは、ページ全体を覆うインタースティシャルや、プロモーション用のダイアログを「煩わしいインタースティシャル」として避けるよう求めています。年齢確認のように法的に必要なものは例外ですが、その場合もコンテンツの上に重ねて一部は読める形にし、同意のために別ページへ転送しないことを勧めています。開いた直後に全面を覆うお知らせは出さず、必要なときだけ出します。

Q. alert() を使うのはいけませんか？ A. 開発中の確認には便利ですが、JavaScript が止まり、文言や見た目を変えられず、自動テストでも扱いが別になります。利用者に見せる画面では <dialog> に置き換えます。

Q. モーダルの上にモーダルを開いてもよいですか？ A. ブラウザは入れ子を正しく扱い、Esc で上の1つだけが閉じました。ただし利用者の負担が増えるので、設計としては重ねないのが基本です。1つにまとめるか、専用ページにします。

Q. 外側をクリックしたら閉じるべきですか？ A. 内容によります。画像の拡大やメニューは閉じてよく、入力の途中や取り消せない操作の確認は、誤って閉じると困るので閉じない方が安全です。<dialog closedby="any"> で切り替えられます。どちらでも、目に見える閉じるボタンは必ず置きます。

Q. スマホでモーダルが閉じられなくなります。 A. 箱の高さが画面を超え、中央寄せで上下が画面の外に出ているのが典型です。箱に max-height: calc(100dvh - 32px); overflow: auto を付けると、中がスクロールしてボタンに届きます。

まとめ

• モーダルとは、閉じるまで他の操作ができない「モード」に入る表示。後ろを操作できればモードレス（トースト・ポップオーバー・モードレスダイアログ）で、見た目では決まらない。
• HTML では <dialog> の showModal() がモーダルの標準。手元の計測で、フォーカスの移動と戻り・Tab の循環・後ろの無効化・Esc・最上位レイヤーへの配置をブラウザが行い、支援技術に渡る要素は 79 個から 27 個に減った。
• 足りないのは背景のスクロールだけ。body:has(dialog:open){overflow:hidden} と overscroll-behavior:contain で止まった（600px → 0px）。
• div と z-index の自作は、inert・フォーカス・Esc・スクロール固定を自分で書かないと「見た目だけモーダル」になる。aria-modal="true" を書いても後ろは支援技術に見えたまま（80 個）だった。
• 使うのは「取り消せない操作の確認」と「続けるのに必須の入力」だけ。1つの目的・2つまでのボタン・必ず閉じられる・重ねない。スマホ幅では max-height と overflow:auto で上が切れないようにする。

参考・出典

確認日はいずれも 2026年10月29日です。

• MDN「<dialog>: ダイアログ要素」：https://developer.mozilla.org/ja/docs/Web/HTML/Reference/Elements/dialog
• MDN「HTMLDialogElement: showModal() メソッド」：https://developer.mozilla.org/ja/docs/Web/API/HTMLDialogElement/showModal
• MDN「inert」：https://developer.mozilla.org/ja/docs/Web/HTML/Reference/Global_attributes/inert
• MDN「ポップオーバー API」：https://developer.mozilla.org/ja/docs/Web/API/Popover_API
• MDN「ポップオーバー API の使用」：https://developer.mozilla.org/ja/docs/Web/API/Popover_API/Using
• MDN「最上位レイヤー（Top layer）」：https://developer.mozilla.org/ja/docs/Glossary/Top_layer
• W3C WAI「Dialog (Modal) Pattern」ARIA Authoring Practices Guide：https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
• Apple「モダリティ」Human Interface Guidelines：https://developer.apple.com/jp/design/human-interface-guidelines/modality
• Google 検索セントラル「煩わしいインタースティシャルとダイアログを避ける」：https://developers.google.com/search/docs/appearance/avoid-intrusive-interstitials
• Playwright「Dialogs」：https://playwright.dev/python/docs/dialogs

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。