怎么用HTML语义化快速排查可访问性故障
W3C Validator 能快速定位语法级结构硬伤，如<main>嵌套错误、<nav>误置<p>内、img缺失alt描述等，直接导致屏幕阅读器失效；只需将完整HTML粘贴至validator.w3.org校验即可。
怎么用 W3C Validator 快速定位结构硬伤
W3C Validator 不是万能的，但它能立刻揪出那些让辅助技术直接“迷路”的语法级错误——比如 <main></main> 被嵌套在 <div> 里、<code><nav></nav> 放在 <p></p> 中、<header></header> 缺失闭合标签。这些错误会导致屏幕阅读器跳过整个区域，或把导航栏读成普通段落。
操作很简单：把完整 HTML（含 <!DOCTYPE html>）粘贴到 validator.w3.org 的 “Validate by Direct Input” 里，点 Check。重点关注这几类报错：
-
Stray end tag </main>：说明前面没开<main></main>，或者被非法闭合了 -
Element <nav> is not allowed as child of element <p>：语义嵌套违规，浏览器会自动修正 DOM，但读屏器看不到原始意图 -
Bad value “” for attribute “alt” on element “img”：空 alt 不等于无 alt，装饰图才该用alt=""，内容图必须填描述
怎么靠浏览器开发者工具一眼识别语义缺失
打开 DevTools → Elements 面板，不是看样式，而是盯住 DOM 树里的标签名和属性。真正影响可访问性的语义问题，往往藏在“看起来正常”的地方：
- 所有按钮都是
<div onclick="...">？→ 缺少role="button"+tabindex="0"+ 键盘事件监听，键盘用户根本无法触发 - 表单控件没
<label>，只靠 placeholder 或 title 提示？→ 屏幕阅读器不读 placeholder，title 又不被所有读屏支持 -
<section>下没有<h2>–<h6>？→ 工具不报错，但辅助技术无法建立文档大纲，用户按 H 键跳标题时直接跳过 -
<main>里塞了广告位、登录框、页脚链接？→ 它本该唯一且只包核心内容，多一个无关节点，语音导航就得额外听 3 秒
为什么 axe DevTools 比 Lighthouse 更适合快速验证 ARIA 状态
Lighthouse 的 Accessibility 报告偏重“有没有”，axe DevTools 偏重“对不对”。比如你写了 aria-current="step"，Lighthouse 只会说“已检测到 ARIA 属性”，axe 则会检查它是否真的加在当前激活的 <li> 上、是否和 role="tab" 或 role="listitem" 搭配合理、有没有和 aria-selected 冲突。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 装 axe DevTools 插件后，点页面右上角图标 → Run Analysis，重点看 “Critical” 和 “Serious” 级别问题
- 遇到
ARIA attributes must conform to valid values，不是改拼写就行——查 ARIA spec，确认你用的是"step"而不是"current"或"page" - 如果 axe 报
Form elements must have labels，别急着加<label>，先确认是不是用了aria-labelledby且指向的 ID 真的存在并可访问
最容易被忽略的语义陷阱：标题层级断裂
这不是语法错误，W3C Validator 不报，axe 也不抓，但它会让所有依赖大纲导航的用户崩溃。典型表现：
- 页面开头三个
<h1>（比如 logo、banner、主标题），然后直接<h3>小节 —— 屏幕阅读器按 H 键跳，会反复停在同一个<h1>上 -
<main>外写了<h2>，里面却从<h3>开始 —— 辅助技术认为主内容比页眉还低一级 - 步骤向导里每个
<li>用<h4>，但父容器没<h2>或<h3>统领 —— 大纲里只剩一堆孤立的四级标题
验证方法：装 HeadingsMap 插件，或在 DevTools Console 里运行 document.querySelectorAll('h1, h2, h3, h4, h5, h6').forEach(h => console.log(h.tagName, h.textContent.trim()))，人工扫一遍顺序。
