必须使用语义化标签而非“看起来像”的div：<nav>自带role="navigation"且为地标，需aria-label区分多个；<main>须为body直接子元素且唯一，缺失将导致跳转至页眉h1；<button>必设type避免意外提交，图标按钮需aria-label；禁用状态须用disabled属性；所有语义标签需通过DevTools验证可访问性树是否正确生成。
必须用对标签，而不是“看起来像”——<nav>、<main>、<button> 这些不是装饰，是屏幕阅读器唯一能依赖的语义锚点；写错一个，用户可能得手动按键十几次才能摸到正文。
为什么 <div class="nav"> 在读屏软件里等于静音
<div> 没有内置 role，浏览器生成的可访问性树里它就是 generic，读屏器既不播报“导航”，也不响应快捷键（比如 NVDA 的 N 键跳导航）。而 <nav> 自带 role="navigation"，且被所有主流读屏器固化为地标（landmark）。
- 多个
<nav>必须加aria-label，否则全读作“导航”——用户分不清哪个是主导航、哪个是页脚面包屑 -
<nav>不能嵌套在<table>或<ul>里，HTML 校验会失败，部分浏览器直接丢弃节点 - 里面必须直接包裹可聚焦元素（如
<a>、<button>），纯文本不构成有效导航内容
<main> 缺失或嵌套错误时，用户怎么找正文
<main> 是屏幕阅读器定位“用户真正想看的内容”的唯一可信锚点。缺失时，系统退而求其次：先找 role="main"，再找不到就从第一个 <h1> 开始算正文——但页眉里常有 <h1>，结果“跳到主要内容”跳到了 Logo 上。
-
<main>必须是<body>的直接子元素，不能被<div class="container">包着 - 全页只能有一个，重复或嵌套在
<header>、<footer>、<nav>内都会导致语义断裂 - 里面不应混入广告、侧边栏、弹窗等非核心内容；若只有一个
<section>，不如直接用<main><h2>
<button> 不写 type 属性会触发意外提交
省略 type 时，浏览器默认为 submit。放在表单里，点一下就会触发表单提交——不仅功能错乱，还会打断读屏器对当前上下文的判断（比如正在编辑，突然跳转）。
立即学习“前端免费学习笔记（深入）”；
-
type="button"是最安全的兜底选择，尤其在组件库中封装按钮时应默认设该值 - 图标按钮（如 ×、?️）必须配
aria-label，仅靠title无效，且title不被键盘用户感知 - 禁用按钮必须用
disabled属性，不能只靠style="opacity: 0.5"，否则辅助技术仍认为可操作
检查语义是否真生效的实操方式
光写对标签不够，得验证浏览器和辅助技术是否识别它。打开 Chrome DevTools → Elements 面板，右键元素 → “Inspect Accessibility Properties”，看 role、name、level 是否符合预期。
-
<img>缺alt，或写成alt=""却没确认是否真为装饰图，会导致读屏器跳过关键信息 -
<time datetime="2026-06-15">的datetime值格式错误（如写成"2026/06/15"），机器无法解析时间语义 - 用
<div role="button">替代<button>，却漏了tabindex="0"和键盘事件监听，键盘用户完全无法操作
最容易被忽略的点是：语义失效往往不是“没写标签”，而是“写了但嵌套错了”——比如 <main> 被包在 <section> 里，或者 <fieldset> 中间插了个 <div>，这些结构断裂在视觉上毫无痕迹，却会让可访问性树直接断掉。
