模态框必须实现闭环焦点管理、Escape键智能拦截、完整ARIA语义和渲染后验证。具体包括：打开时聚焦首个可聚焦元素，Tab键循环控制，aria-modal="true"配合aria-labelledby，屏蔽背景内容，关闭按钮需aria-label，禁用鼠标纯键盘测试确保无障碍。
模态框必须有明确的焦点管理
键盘用户无法操作没有焦点控制的模态框——按 Tab 会跳出框外，Esc 没反应，屏幕阅读器也读不到内容。关键不是“加个 tabindex”，而是建立闭环焦点流。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 打开模态框时，立即将焦点转移到第一个可聚焦元素（如第一个
input、button或带tabindex="0"的容器） - 监听
keydown事件，捕获Tab键：当焦点到达最后一个可聚焦元素时，阻止默认行为并跳回第一个；反之亦然 - 用
document.activeElement+focusableElements = modal.querySelectorAll('button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])')动态获取当前可聚焦项，别硬编码索引 - 确保模态框外的页面主内容被
aria-hidden="true"隔离（但不要设在<body>上，否则屏幕阅读器可能完全失焦）
Escape 键关闭必须可中断且不干扰其他逻辑
很多实现直接在 keydown 里写 if (e.key === 'Escape') close()，但问题在于：如果用户正在 textarea 里输入多行文本，按 Esc 本不该关闭；或者模态框内嵌了 CodeMirror 等富编辑器，Esc 是编辑器快捷键。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 只在模态框根元素上监听
keydown，并检查e.target是否为模态框自身或其子元素（用modal.contains(e.target)） - 排除
input、textarea、contenteditable元素的Escape事件：若e.target.matches('input, textarea, [contenteditable]')，跳过关闭逻辑 - 关闭前调用
modal.focus()再移除，避免焦点丢失到body导致后续Tab行为异常
ARIA 属性不能只写 role="dialog"
仅加 role="dialog" 不足以让屏幕阅读器正确宣布模态框。缺少 aria-labelledby 或 aria-label，它可能只读“对话框”，不读标题；缺少 aria-modal="true"（尤其在 Safari + VoiceOver 下），背景内容仍会被朗读。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 必须配对使用：
role="dialog"+aria-labelledby="dialog-title-id"（指向<h2 id="dialog-title-id">）或aria-label="确认删除文件" -
aria-modal="true"要加在模态框根元素上（不是遮罩层），这是强制隔离背景内容的关键属性 - 遮罩层（overlay）用
role="none"或不设 role，避免被误读为可交互元素 - 关闭按钮必须有
aria-label="关闭"，不能只靠图标或文字“×”
初始渲染后立即验证焦点和语义结构
浏览器渲染时机、框架异步更新、CSS display: none 切换都可能导致 ARIA 属性挂载失败或焦点未落到预期位置。靠肉眼点开看不出来的问题，键盘一按就暴露。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 打开模态框后，立刻执行：
console.assert(modal.contains(document.activeElement), '焦点未落入模态框内') - 用 Chrome DevTools 的 Accessibility 面板检查模态框节点是否包含
name（来自aria-labelledby）、role="dialog"和modal=true - 禁用鼠标，纯用键盘测试：打开 →
Tab循环 →Shift+Tab反向 →Esc→ 回到触发按钮，全程无焦点丢失 - 特别注意 CSS
visibility: hidden或opacity: 0的模态框——它们仍可聚焦，但视觉不可见，属于严重可访问性缺陷
aria-modal 的浏览器支持差异、以及动态内容插入后焦点重置的时机，是三个最容易被忽略的复杂点。 
