语义化HTML是保障可访问性与机器可读性的基础，应优先使用<header><main><section><article>等语义标签替代无意义的<div>套娃，正确设置alt、<th>/<td>、<label>for/id匹配及<fieldset><legend>结构。
为什么 <div> 不该是第一个想到的容器
很多人一想“要包一块内容”，立刻写 <div>，结果页面全是 <div class="wrapper"> 套娃。这不是错，但会丢失语义——搜索引擎和屏幕阅读器无法从中推断结构意图。
-
<header>用于页眉或区块头部，含 logo、主导航等；不是所有顶部区域都该用它，比如一个卡片标题就该用<h2>+<div> -
<main>在整个文档中只能出现一次，代表主体内容唯一入口；若页面有多个“主要内容区”（如仪表盘多卡片），说明结构设计有问题 -
<section>必须自带标题（<h2>–<h6>），否则语义断裂；纯样式分组请继续用<div> - 嵌套层级别太深：避免
<div><div><div><p>，优先用<article>或<section>承载逻辑单元
<img> 的 alt 属性到底怎么填才不算“凑数”
alt 不是可选字段，也不是 SEO 关键词堆砌位。它的核心作用是：当图片不显示时，用户靠这段文字理解“这里本该有什么”。
- 信息图、数据图表：写清关键结论，例如
alt="柱状图显示2025年Q3华东区销售额同比增长23%，高于全国均值" - 装饰性图标（如按钮旁的 ✅）：用空字符串
alt=""，确保屏幕阅读器跳过 - 带链接的图片：如果链接行为已由周围文本说明（如
<a href="/blog"><img src="icon.png" alt="">博客</a>），图标本身可alt="" - 绝对不要写
alt="图片"、alt="logo"或留空不写——后者会导致屏幕阅读器读出文件名，非常混乱
表格里 <th> 和 <td> 混用会带来什么实际问题
表面看只是加粗/居中差异，但错误使用会让表格在无障碍场景下完全不可读。尤其当列数多、数据复杂时，屏幕阅读器依赖 <th> 的 scope 属性定位上下文。
- 每张表必须有且仅有一个
<thead>，里面每个<th>都应带scope="col"（列头）或scope="row"（行头） - 合并单元格时，
colspan和rowspan不能破坏行列对应关系；例如<th colspan="2">成绩</th>后，下一行两个<td>才算归属该表头 - 避免用
<td>冒充表头：即使加了 CSS 加粗，屏幕阅读器仍当它是普通数据单元格，不会作为导航锚点 - 无标题表格（如纯布局用表）已淘汰多年，现代 CSS Grid/Flex 完全可替代，继续用属于技术债
表单中 <label> 和 for/id 匹配失败的典型表现
用户点击标签文字无法聚焦输入框，是这个错误最直接的后果。但更隐蔽的问题是：自动填充失效、语音控制失灵、测试工具报 ARIA 错误。
立即学习“前端免费学习笔记（深入）”；
-
for值必须与目标<input id="xxx">的id完全一致（大小写敏感），且全局唯一；重复id会导致只绑定到第一个元素 - 嵌套式写法（
<label>用户名<input name="user"></label>）虽合法，但不利于复杂表单项（如带图标的输入框）和 JS 动态操作 - 复选框/单选按钮组必须用
<fieldset>+<legend>包裹，否则屏幕阅读器无法识别“这是一组相关选项” - 禁用
pointer-events: none或opacity: 0遮盖原生<input>的做法，会直接切断 label 绑定链路
语义不是“写得漂亮”的装饰，而是让 HTML 在脱离 CSS 和 JS 时仍能被机器和人正确解析。最容易被忽略的是：每次新增一个 <div> 或删掉一个 alt，都在悄悄降低页面的鲁棒性。
