質問が読み上げられない確認ダイアログ

画面上の文言は修正後とまったく同じです。背後のページはinertになり、Escapeキーも効くため、目視と簡単なキーボードの確認なら通ります。しかし、見出しも説明もダイアログに関連付けられておらず、フォーカスは「プロジェクトを削除」から始まり、その後の trigger.focus() は、たった今取り除かれたボタンを指しています。

role="alertdialog" は応答が必要なダイアログであることをスクリーンリーダーに伝え、aria-labelledby は見出しを名前にし、aria-describedby は説明を一緒に読ませます。autofocus でフォーカスが「キャンセル」から始まるため、うっかり押したEnterではプロジェクトは消えません。showModal() は背後のページを操作できない状態にし、Escapeキーで閉じます。行が消えた後は、フォーカスがbodyに落ちず、一覧の見出しへ移ります。

どちらも基準を満たします。HTML標準の dialog を選んでください。背後のページの無効化、Escapeキー、キャンセル後にフォーカスを戻す処理をブラウザーが行うため、残るコードはこのガイドで扱う部分だけです。独自のダイアログは、「修正前」のようにフレームワークやデザインシステムが独自のオーバーレイを描画している場合に、最も小さな変更で済む方法です。ライブラリの確認ダイアログを使う場合は、両方のボタンに名前を付けられるか、最初のフォーカスをどちらに置くか選べるかを確認してください。

ダイアログの形は、操作の重さで決まります。

• 元に戻せる操作：ダイアログは使いません。すぐに削除し、項目のあった場所に「元に戻す」を置きます。読む前や元に戻す前に消えるトーストを参照してください。
• 元に戻せない操作：確認ダイアログを使い、「キャンセル」から始め、失われるものを、役に立つなら数も添えて書きます（「24個のファイル」）。
• 元に戻せず、他の人にも影響する操作（共有ワークスペースの削除など）：項目の名前を入力するまで削除ボタンが使えないようにし、まだ押せない理由をダイアログ内に書きます。

この例のように、見出しと実行ボタンには操作と対象を書きます（「「春のキャンペーン」を削除しますか？」「プロジェクトを削除」）。スクリーンリーダーが読む名前は、指している見出しの内容しだいです。「よろしいですか？」と「OK」では、誰にも何が起きるか分かりません。

window.confirm() はモーダルで、スクリーンリーダーにも読まれますが、多くのブラウザーでは「OK」から始まり、ボタン名も「OK」と「キャンセル」に固定されるため、このようなダイアログにはできません。

画面で「キャンセル」を先に表示するなら、マークアップでも先に置き、Tabの順序を表示の順序に合わせます。実行ボタンを赤で示す場合も、色だけに頼らないでください。ラベルの「プロジェクトを削除」がすでに内容を伝えています。

削除後のフォーカスの行き先として、一覧の見出しは安全です。次の行の「削除」ボタンは続けて削除する人には速いものの、誤って押しやすいため、そこには置きません。項目が消えたことをページ上で伝えていない場合は、読み上げられるメッセージを追加してください。画面に出ても読み上げられないステータスメッセージで扱っています。

フォーカスがダイアログに入ること、背後のページ、Escapeキーなど、モーダル全体の動作は背後にフォーカスが残るモーダルを参照してください。