应优先用原生HTML语义化元素替代div：模态框用<dialog>，折叠面板用<details><summary>，标签页用<button role="tab">配<div role="tabpanel">，分页用<nav>包裹<ul><li>或<button>并设aria-current="page"。
用原生HTML元素替代div做动态容器
很多动态内容可访问性问题，根源在于用 <div> 硬套所有交互逻辑。屏幕阅读器对 <div> 没有语义预期，也不会主动播报变化。优先选用带隐式语义的原生标签，能省掉大量 ARIA 补充工作。
常见场景对应关系：
- 模态框 → 用
<dialog>，它自带aria-modal="true"、焦点陷阱和关闭语义 - 手风琴/折叠面板 → 用
<details>+<summary>，浏览器自动处理aria-expanded和键盘（Space/Enter 展开） - 标签页 → 不要用
<div class="tab">，改用<button role="tab">配合<div role="tabpanel">（注意：role 是补充，不是替代；<button>本身已可聚焦） - 分页导航 → 包裹在
<nav>内，页码用<ul><li><a>或<button>，当前页加aria-current="page"
用标准属性控制状态与关联，而非手动写ARIA
HTML5 提供了一批内置属性，它们比手写 ARIA 更可靠、更轻量，且部分会自动同步到辅助技术的属性树中。
关键可用属性：
立即学习“前端免费学习笔记（深入）”；
-
hidden：隐藏内容时用它，比display: none或aria-hidden="true"更安全——它同时移除 DOM 可访问性树和视觉渲染 -
disabled：用于<button>、<input>等原生控件，会自动触发aria-disabled="true"，且阻止键盘聚焦 -
required、minlength、pattern：表单验证属性，屏幕阅读器会读出约束，无需额外aria-invalid（除非需自定义错误文案） -
for+id：<label for="email">关联<input id="email">，比aria-labelledby更直接、更兼容
用 aria-live 区域声明动态更新范围
当内容靠 JS 插入（如搜索结果、通知、表单提交反馈），仅靠 DOM 变化无法被屏幕阅读器感知。必须用 aria-live 显式标记“这里的内容会变，请监听”。
选择策略：
- 重要且需立即播报（如表单成功提示）→
aria-live="polite"或aria-live="assertive"（后者会打断当前播报） - 非关键更新（如实时计数器）→
aria-live="off"+ 手动触发aria-atomic="true"控制播报粒度 - 避免把整个页面或大块区域设为
aria-live，否则容易淹没用户；应精准包裹目标容器，例如：<div aria-live="polite" aria-atomic="true"></div> - 不要依赖
title属性做动态提示——它不触发aria-live，且在多数屏幕阅读器中被忽略或延迟播报
动态内容出现时，焦点必须明确落点
这是最容易被忽略的环节：内容加载完成 ≠ 用户知道该看哪。若新内容无焦点，键盘用户会卡在原位置，屏幕阅读器可能跳过它。
实操要点：
- 模态框打开 → 焦点必须移到
<dialog>内第一个可聚焦元素（如关闭按钮或主操作按钮），不能留在触发按钮上 - 手风琴展开 → 若内容区含可操作项，焦点应移到该区域起始处（如第一个
<button>或<input>）；若纯文本，可设tabindex="-1"后.focus() - 列表项新增（如聊天消息）→ 不要自动聚焦新消息（会打断用户当前操作），但需确保其位于 DOM 顺序合理位置，并用
aria-live通知 - 禁用
autofocus属性：它在 Safari 和部分屏幕阅读器中行为不可靠，应由 JS 显式控制焦点时机
aria-expanded 必须和视觉状态严格一致，aria-current 必须随路由或 UI 状态实时更新，任何延迟或错位都会导致辅助技术“说错话”。 
