原生语义化标签是屏幕阅读器理解页面结构的唯一可靠依据，<div>和<span>无语义，不被识别为控件或区域；应优先使用<h1>-<h6>、<p>、<ul>/<ol>+<li>、<button>等原生标签，并确保正确嵌套与层级。
原生语义化标签不是“锦上添花”，而是屏幕阅读器理解页面结构的唯一可靠依据。用 <div> 模拟 <button> 或 <nav>，等于主动关闭无障碍支持——没有角色、没有键盘交互、没有焦点管理，辅助技术只能读出“一段文字”，而非“一个可点击的导航区域”。
为什么 screen reader 读不出 <div> 里的内容？
<div> 和 <span> 是纯容器，不携带任何语义信息。屏幕阅读器默认跳过它们的“区块”含义，只朗读其中的文本节点，且不提示上下文（比如“这是个按钮”或“这是导航栏”）。
- 它不会自动获得
tabindex，键盘用户无法聚焦 - 不响应
Enter/Space，即使绑了onclick - 没有隐式
role，NVDA/JAWS 不会将其归类为控件或区域
真正该用的标签：标题用 <h1>–<h6>，段落用 <p>，列表用 <ul>/<ol>+<li>，交互控件优先用 <button>、<a>、<input>。
<button> 和 role="button" 的关键区别在哪？
加 role="button" 只是向辅助技术“声明身份”，但不提供任何运行时能力；而原生 <button> 自带一整套无障碍契约：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 自动获得
tabindex="0"，支持键盘聚焦 - 内置
Enter和Space触发逻辑 - 禁用状态（
disabled）自动移除焦点和交互 - 与
form的原生提交行为集成
除非你必须包裹 SVG 图标且样式完全不可妥协（比如多层嵌套 transform），否则别碰 role="button"。真要用，必须手动补全：tabindex="0"、onkeydown 监听、aria-pressed 状态同步、outline 样式修复——漏一项，就等于把键盘用户挡在门外。
表单里 label 不写对，整个字段就“失明”
屏幕阅读器靠 <label> 与控件的显式关联来播报字段含义。没 <label>，或者只靠 placeholder，等于让视障用户猜：“这个输入框是填邮箱？电话？还是验证码？”
- 推荐写法：用
for+id关联，或直接嵌套<input>在<label>内 -
placeholder不是label替代品——它在输入时消失，且不被所有屏幕阅读器稳定播报 - 分组控件（如单选/复选）必须用
<fieldset>+<legend>，否则每项都孤立无上下文 - 错误提示要通过
aria-describedby或aria-errormessage显式绑定，不能只靠视觉颜色变化
header / nav / main 这些块级标签不是“为了好看”
它们的语义价值体现在运行时：浏览器和辅助技术会根据这些标签建立 DOM 导航树。例如，NVDA 用户按 D 键可快速跳转到下一个 <div> 区域，但按 H 键才能跳 <header>、<nav>、<main>——前提是这些标签真实存在且未被滥用。
-
<main>应有且仅有一个，代表页面核心内容起点 -
<nav>需配aria-label（如aria-label="主导航"）避免多个<nav>时混淆 -
<section>和<article>必须有<h2>–<h6>作为标题，否则屏幕阅读器无法识别其边界 - 别用
<div class="header">代替<header>——CSS 类名对辅助技术完全透明
最常被忽略的一点：语义标签一旦写错层级或嵌套关系（比如 <main> 套在 <header> 里），屏幕阅读器仍会尝试解析，但导航逻辑会混乱，用户可能反复进入同一区域或跳过关键内容。结构正确，比样式漂亮重要得多。
