语义化标签直接决定屏幕阅读器能否正确朗读：、、等提供明确结构标记，使视障用户可快捷跳转；必须全页唯一且不嵌套于或中，仅用于主导航，须含及以上标题，原生控件（如）优于模拟，语义化是无障碍与seo的共同基础。
语义化标签直接决定屏幕阅读器能否正确朗读结构
可读性差的 HTML（比如一堆嵌套 <div class="header">）不是“只是看着乱”，而是让屏幕阅读器失去上下文判断依据。它无法区分哪块是导航、哪块是正文、哪块是页脚，只能线性读出所有文本，用户得靠听完整页才能猜出结构。<p>用 <code><header></header>、<nav></nav>、<main></main> 这类标签，等于给辅助技术打了明确标记。屏幕阅读器支持快捷键跳转到 <nav></nav> 或 <main></main>，视障用户能 3 秒内定位核心内容——这和你 Ctrl+F 搜 “main” 是两回事，这是运行时能力。
-
<main></main>必须全页唯一，且不能被<article></article>或<section></section>包裹，否则会被忽略 -
<nav></nav>不是所有链接集合都适用，“上一篇/下一篇”这类次要导航应使用普通<a></a> -
<section></section>必须有标题（<h2></h2>或更高级别），否则语义不成立，不如用<div> <h3>class 名混乱会破坏键盘焦点流与 ARIA 同步</h3> <p>当用 <code><div class="btn-primary">提交</div>模拟按钮时，它默认不可聚焦、无角色、不响应 Space/Enter 键。即使加了tabindex="0"和role="button"，也得手动绑定所有键盘事件和状态切换（如aria-pressed），稍有遗漏就会卡住键盘用户。换成原生
<button></button>，浏览器自动处理聚焦、按键响应、禁用态、表单提交行为——这些不是“锦上添花”，是底线要求。- 所有交互控件优先用语义化原生元素：
<button></button>、<input type="checkbox">、<select></select> - 避免
<div onclick> + <code>tabindex组合，维护成本高且易出错 - 若必须用
<div>（如复杂组件），需同步管理 <code>role、tabindex、aria-*属性及键盘事件结构清晰度影响 SEO 与无障碍的双重解析逻辑
搜索引擎爬虫和屏幕阅读器共享一套底层解析逻辑：都依赖 DOM 树中的语义层级来判断内容权重与关系。一个没用
<header></header>而用<div id="top-bar"> 的页面，既会让 Google 降低对顶部导航的信任度，也会让 NVDA（常用屏幕阅读器）把 Logo、搜索框、登录链接全当成普通段落读出来。<p>这不是“可能影响”，而是已验证的事实：WCAG 1.3.1（信息与关系）明确要求“通过程序化方式确定的信息、结构和关系必须可通过辅助技术获取”。语义化标签就是最直接的程序化方式。</p> <ul> <li> <code><article></article>内部的<h2></h2>会被识别为该文章的标题，而非整页的二级标题 -
<time datetime="2026-08-26"></time>提供机器可读日期，比纯文本 “2026年8月26日” 更利于解析 - 错误嵌套（如
<main></main>放在<footer></footer>里）会导致部分辅助技术直接跳过该区域
团队协作中“可读即可达”是最省成本的无障碍起点
很多团队把无障碍当成后期补救项，结果改起来要重写 JS 状态管理、重调 CSS 焦点样式、补一堆 ARIA。但如果你从第一行 HTML 就用对
<nav></nav>、<main></main>、<button></button>，90% 的基础可访问性问题其实已经解决。真正容易被忽略的是：语义化不是“加几个新标签就完事”，而是持续判断——这个区块到底有没有独立主题？它是否属于主要内容？它要不要被搜索引荐或被屏幕阅读器单独跳转？这些问题每天写 HTML 时都要问一次。
- 所有交互控件优先用语义化原生元素：
