判断HTML5元素是否被屏幕阅读器正确识别，关键看其在可访问性树中是否暴露正确的role、name、state和properties；需用Chrome DevTools的Accessibility Inspector验证Computed Role、Name及States。
怎么判断一个 HTML5 元素是否被屏幕阅读器正确识别为语义化组件
关键不是“用了 HTML5 标签就自动无障碍”，而是看它是否生成了正确的 role、name、state 和 properties，这些最终由浏览器的可访问性树（Accessibility Tree）暴露给辅助技术。比如 默认有 role="navigation"，但若被 CSS 设为 display: none 或 JS 移除了，就会从可访问性树中消失——屏幕阅读器根本“看不见”它。
验证方法很简单：用 Chrome DevTools 打开「Elements」面板 → 右键元素 → 「Inspect Accessibility Properties」，或按 Cmd+Shift+P（Mac）/ Ctrl+Shift+P（Win）输入 “Accessibility” 快速打开 Accessibility Inspector。重点看：Computed Role 是否符合预期，Name 是否可读（非空且有意义），States（如 disabled、expanded）是否同步更新。
什么时候必须用 ARIA 补 HTML5 语义缺失
HTML5 标签覆盖了大部分常见结构（、 等），但交互组件仍常需 ARIA 显式标注。典型场景包括：
- 这类自定义选项卡容器，必须加
role="tablist"；每个选项卡项加role="tab"并用aria-controls指向对应面板缺少可读的当前值说明，需配合aria-valuetext或aria-labelledby关联可见文本- 动态加载内容（如无限滚动列表），新增项未自动获得焦点或通知，要用
aria-live="polite"包裹容器- 模态框（
已原生支持，但旧浏览器 fallback 时需手动加role="dialog"+aria-modal="true"+ 焦点管理ARIA 属性和 HTML5 原生属性冲突怎么办
优先用 HTML5 原生语义，ARIA 是补丁，不是替代品。以下组合会出问题：
立即学习“前端免费学习笔记（深入）”；
-
：错误。按钮就是按钮，想跳转应改用，否则破坏键盘操作逻辑（按钮回车触发，链接空格不触发） -
：冗余且危险。aria-checked会覆盖原生checked状态，导致 JS 同步失效 -
标题
内容本身是role="region"或role="complementary"，更推荐直接用—— 语义更准，兼容性更好原则：只要原生属性能表达状态（
disabled、required、hidden）、角色（type="submit"、type="search"）、名称（alt、label、title），就别用 ARIA 覆盖。哪些 ARIA 模式在 HTML5 中已有原生等价但常被忽略
开发者常手写 ARIA 模式，却不知 HTML5 已内置支持，既增加维护成本，又易出错：
......真正容易被忽略的是：
自带value和min/max，比role="progressbar"+ 手动同步aria-valuenow更可靠。复杂交互组件（如树形控件、日历）仍需完整 ARIA 实现，但日常开发里，先查 MDN 上对应 HTML5 元素的「Accessibility concerns」小节，往往就能避开 70% 的 ARIA 误用。
