语义化标签直接决定屏幕阅读器能否正确识别页面结构，如<nav>、<main>等自带role属性，而<div>是无意义“黑盒”；label与input必须严格绑定，button不可用div模拟；搜索引擎与辅助技术共享DOM解析逻辑，语义化是基础层而非可选优化。
语义化标签直接决定屏幕阅读器能否正确识别页面结构
没有语义化标签，<div> 就是“黑盒”——它不告诉屏幕阅读器这是导航、主内容还是页脚。用户只能靠听一连串“段落、段落、段落”硬啃，没法跳转到 <main> 或绕过重复的 <header>。而 <nav> 自带 role="navigation"，<main> 自带 role="main"，这些不是可选配置，是浏览器原生支持的契约。
label 和 button 这类表单/交互元素的语义不可替代
一个没用 <label for="email"> 绑定的 <input id="email">，屏幕阅读器只会读“编辑文本”，不会说“邮箱地址”。同理，用 <div onclick> 模拟按钮，键盘用户按 Space 或 Enter 根本没反应——因为缺失 role="button" 和焦点管理能力。真实项目里，90% 的表单无障碍问题都卡在这两个标签的绑定是否严格匹配上：
-
input必须有非空、唯一、无空格/大小写混用的id -
label的for值必须与该id完全一致（不含#） - 不能用
placeholder当label，也不能用 CSS 遮住label的点击区域（比如pointer-events: none）
搜索引擎和辅助技术依赖同一套语义解析逻辑
Google 爬虫和 TalkBack 屏幕阅读器其实共享底层 DOM 解析机制。你写 <article> 而不是 <div class="post">，既让搜索结果更准（核心内容权重提升），也让视障用户能用快捷键 Ctrl+Alt+1 直接跳到第一个 <article>。这不是“多做一点优化”，而是避免在两个关键通道上同时降级——否则 SEO 掉量 + 无障碍投诉会同步出现。
ARIA 是补丁，不是替代；语义化才是基础层
很多人以为加一堆 aria-label 就能解决无障碍，但错了。ARIA 是给无法用原生语义表达的复杂组件（比如自定义下拉菜单）兜底的，它不能覆盖原生标签已有的能力。比如你给一个 <div role="button"> 加了 aria-pressed，还得手动处理 tabindex、keydown、焦点样式……而一个原生 <button>，这些全自带。真正容易被忽略的是：语义化不是“写对标签就完事”，它要求整个文档骨架从 <header> 到 <footer> 保持层级连贯，中间不能突然插一个没包裹的 <h2> 或漏掉 <main> ——结构断层会让所有依赖语义的工具集体失焦。
立即学习“前端免费学习笔记（深入）”；
