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