语义化需内容与标签含义匹配，确保角色、名称、状态正确；标题层级须严格递进且唯一h1；ARIA仅在原生语义不足时精准补救；表单控件必须有可访问名称。
用对 <header> <nav> <main> 这些标签，不等于语义化
语义化不是把 <div> 换成 <section> 就完事。屏幕阅读器靠的是元素的隐含角色（role）、名称（name）和状态（state）来理解结构，而原生语义标签只是提供默认角色的一种快捷方式。比如 <nav> 默认有 role="navigation"，但如果你把它套在一堆无链接的 <span> 上，它就失去了导航意义。
实操建议：
- 优先使用原生语义标签，但必须确保内容匹配其隐含含义：例如
<nav>内至少包含一个有效的<a>或带href的<button> - 避免“语义漂移”：不要用
<article>包裹广告位，哪怕它看起来像一个独立区块 - 检查 DOM 中每个语义标签是否被辅助技术正确识别——可用浏览器 DevTools 的 Accessibility 面板查看 computed role 和 name
标题层级断裂是可访问性最常被忽略的硬伤
很多页面从 <h2> 开始，或者在 <main> 外堆了三个 <h1>，这会让屏幕阅读器用户完全迷失上下文。标题不只是样式，它是文档大纲（outline）的骨架，辅助技术靠它生成导航树。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 用
<h2>做 logo 文字（应为<h1>或纯文本 +aria-label） -
<aside>里的小标题用了<h3>，但主内容还没出现<h2>，导致大纲跳级 - CSS 隐藏了
<h1>却没加aria-hidden="true"，造成视觉与语音双重混乱
正确做法：全页只允许一个 <h1>（代表页面主主题），其余按逻辑嵌套递进；用 <h2> 分割主要板块（如“产品介绍”“客户评价”），<h3> 描述板块内子模块。
aria-labelledby 和 aria-describedby 不是装饰，是补救关键路径
当语义标签无法覆盖真实交互逻辑时（比如一个图标按钮、动态加载的弹窗、或由 JS 控制的折叠面板），就得靠 ARIA 显式声明关系。但乱加 aria-* 属性反而会破坏可访问性——比如给一个已有 <input> + <label> 的表单控件再加 aria-labelledby，可能让读屏重复播报两次。
使用场景与要点：
- 模态框必须同时设置
role="dialog"、aria-labelledby（指向标题元素 ID）和aria-modal="true" - 图标按钮（如 ?）必须用
aria-label或aria-labelledby提供操作意图，不能只靠 title 属性 -
aria-describedby适合关联错误信息或额外说明，但目标元素必须存在且非display: none - 永远优先用原生 HTML（如
<label for="id">）替代aria-labelledby，除非 DOM 结构不允许
表单控件缺失 label 或 aria-label 是高频致命错误
没有关联标签的 <input type="text">，对键盘用户意味着无法知道这是填邮箱还是收货地址；对屏幕阅读器用户则是完全不可操作的“黑盒”。CSS 隐藏的 <label> 也必须配合 aria-label 或视觉隐藏类（如 clip-text），否则会被直接忽略。
参数差异与兼容性注意：
-
<input>必须有可访问名称来源：显式<label for="id">、内部<label>包裹、或aria-label/aria-labelledby -
placeholder不是 label 替代品——它会在输入时消失，且部分读屏不会播报 - 自定义复选框/单选按钮需手动同步
checked状态并透传至底层<input>，否则 JS 获取值时可能丢失 - React/Vue 中用
ref或v-model绑定时，别忘了同步id和for关联
复杂点在于：语义结构要和交互行为对齐，而不是和视觉设计对齐。一个看似简单的折叠菜单，如果展开后内容没有进入焦点流、没有更新 aria-expanded、也没有用 aria-controls 关联目标区域，那它在可访问性层面就是断裂的。
