W3C验证器能发现<img>缺alt属性，因为alt是HTML5规范强制要求的必需属性，省略即为语法错误，会触发“Element img is missing required attribute alt”报错。
W3C验证器只报语法错误，不查可访问性问题
W3C Markup Validation Service 能发现 <img> 缺 alt 属性吗？不能。它只校验 HTML 语法和结构合规性，比如标签是否闭合、嵌套是否合法、doctype 是否存在。可访问性缺陷（如缺失 alt、label 未绑定、role 误用）完全不在它的检测范围内。
这意味着：即使 W3C 报告显示 “No errors found”，页面仍可能对屏幕阅读器用户完全不可用。必须叠加专门的可访问性工具，不能依赖单一验证器。
- W3C 验证器适合检查：
<html>根元素是否存在、<head>和<body>是否完整、自闭合标签写法（如<img src="x" />vs<img src="x">） - axe 或 Lighthouse 才能检测：
<button>没有文字内容、<input type="checkbox">缺<label for="x">、color-contrast不达标 - 人工键盘导航测试是最终防线：Tab 键能否到达所有交互控件？焦点离开模态框后是否回到触发按钮？这些逻辑无法被任何自动化工具覆盖
HTMLHint 默认不启用可访问性规则
很多人把 htmlhint 当作“万能检查器”，但默认配置下它几乎不检查可访问性。例如 <img src="logo.png"> 没写 alt，htmlhint 不会报错——除非你显式开启 attr-accessibility 等插件规则。
在 .htmlhintrc 中必须手动添加：
立即学习“前端免费学习笔记（深入）”；
{
"attr-accessibility": true,
"attr-no-duplication": true,
"id-unique": true,
"head-title": true
}
否则，CI 流程里跑的 htmlhint 就只是个“结构检查员”，对残障用户是否可用毫无发言权。
-
attr-accessibility：强制<img>、<area>、<input type="image">必须含alt或aria-label -
head-title：防止整个页面缺<title>，这是 WCAG 2.1 Level A 强制要求 - 别依赖默认配置：团队应统一维护一份带可访问性规则的
.htmlhintrc，并纳入 Git 仓库根目录
自动化工具漏掉的三类关键问题
axe、Lighthouse 这类工具能扫出 70% 的可访问性问题，但以下三类必须靠人眼+真实操作验证：
-
焦点顺序错乱：视觉上从左到右的按钮组，Tab 键却先跳到页脚再回来——DOM 顺序和 CSS
order/flex-direction冲突时，工具无法判断逻辑是否合理 -
动态内容无通知：表单提交后弹出 success toast，但没发
aria-live，屏幕阅读器用户听不到——工具只看静态 HTML，不执行 JS -
语义滥用：用
<div role="button">替代原生<button>，又没加tabindex="0"和键盘事件监听——工具可能只报“role 可用”，但不会告诉你它实际不可聚焦、不可空格触发
这些必须放进代码审查 checklist，由 reviewer 实际用键盘走一遍流程，而不是等 PR 合并后再补救。
CI 流程里怎么塞进可访问性检查
把可访问性检查硬编码进 CI，不是加一行 npm run axe 就完事。关键在于失败阈值和修复路径要明确：
- CI 中运行
axe-coreCLI 时，用--rules指定只检查 Level A 必须项（如image-alt、label、heading-order），避免因低优先级警告阻塞构建 - 对
color-contrast类问题，允许配置容忍度（如最小对比度设为 4.0 而非严格 4.5），否则设计师配色微调就会导致 CI 失败 - 必须配套提供修复指引：当
axe报form-field-multiple-labels错误时，CI 日志里直接给出示例修复代码，而不是只甩一个链接
最易被忽略的一点：可访问性检查必须在**渲染后**执行。如果 HTML 是 SSR 生成的，直接测源码；如果是客户端渲染（React/Vue），得等 hydration 完成再注入 axe，否则测的是骨架屏或 loading 状态——结果完全失真。
