具体来说，有几个容易踩坑的地方：

• 只适用于主导航链接集合。页脚里那些“关于我们”“条款”之类的链接，不建议塞入其中，用 配合普通列表更合适。
• 代表可独立分发或复用的内容，例如博客正文、新闻条目。侧边栏里的推荐卡片不属于
  ，应使用 。
• 在页面中只能出现一次，且不能嵌套在
  或 内部。
• 不要为了调整样式而随意使用
  到
  。标题层级必须反映内容的逻辑结构。跳级（例如
  后面直接跟
  ）会破坏屏幕阅读器的导航体验。

如何检查语义是否真正生效

标签写对并不等于万事大吉，还需要验证浏览器和辅助技术是否真正识别。最直接的验证方式：打开 Chrome DevTools 的 Elements 面板，右键元素选择“Inspect Accessibility Properties”，查看 role、name、level 等属性是否符合预期。

常见问题场景包括：

• 被设置为 display: block，又手动添加了点击事件，但忘记加 type="button"，导致表单意外提交。
• 缺少 alt 属性，或者写了空的 alt=""，却没有确认它是否为装饰图——只有装饰图才该留空，数据图必须有描述。
• 5月20日 中的 datetime 格式写错（例如写成 "2023/05/20"），机器无法解析。
• 用
  替代 ，却忘记加 tabindex="0" 和键盘事件（Enter/Space），键盘用户无法操作。

  与 CSS、JS 协作时的语义边界

  样式和交互代码不能反过来破坏 HTML 的语义基础。例如，用 JS 动态切换 class 来控制显隐时，不要只靠 display: none 把关键导航隐藏，需同步添加 aria-hidden="true"。CSS 重置时（比如去掉了 的默认边框），必须确保焦点状态（:focus-visible）仍然清晰可见。

  还有一些常见陷阱：

  • 组件库封装时，不要将 包进
    再通过 label[for] 关联——ID 冲突或丢失会导致语义断裂。
  • 使用
    制作折叠面板时，不要用 JS 强行改写
    的默认行为。其自带的展开/收起功能已内置键盘支持（Space/Enter）和正确的语义角色。
  • 在服务端渲染页面中，如果用 data-* 属性向 JS 传参，不要占用语义属性。例如 data-id 没有问题，但 data-role="header" 会覆盖
    的原生语义。

  归根结底，语义化的真正难点不在于标签选择本身，而在于能否持续对抗“视觉优先”的惯性。当设计稿没有区分主副标题层级，当产品经理说“这个按钮就放这儿，别动结构”，你需要清楚哪里可以妥协。而一旦某个地方松了口，后续的可访问性补救成本会指数级上升。