wcag检查不能只靠人工审计,因其效率低、易漏项、难复现,且无法捕获dom渲染后暴露的问题(如aria-hidden错误包裹焦点元素、role="button"缺键盘事件)。

为什么 WCAG 检查不能只靠人工审计
人工逐条核对 WCAG 2.2 的 78 条成功标准,效率低、易漏项、难复现。更关键的是,很多问题在 DOM 渲染后才暴露——比如 aria-hidden="true" 错误地包裹了焦点元素,或 role="button" 缺少键盘事件监听,这些静态扫描工具可能放过,但屏幕阅读器会直接跳过或报错。
真实项目中,常见漏检点包括:
-
tabindex值为0但元素不可交互(如纯div无onclick或onkeydown) -
label用for关联input,但id值拼写错误或重复 -
img的alt属性值为空字符串alt="",却未加role="presentation"明确声明装饰性
HTMLHint + axe-core 联动检查的最小可行配置
单靠 HTMLHint 只能捕获结构层问题(如缺失 alt、meta charset、doctype),而 axe-core 负责运行时可访问性检测。两者必须串联,否则会漏掉 60% 以上高风险项。
推荐配置方式:
- 开发阶段:VS Code 安装
HTMLHint和axe DevTools插件,前者实时标出img[alt]缺失,后者在浏览器调试时一键触发完整扫描 - CI 流程:在
npm test中加入axe-coreCLI 调用,对本地服务的/index.html页面做快照检测,失败时阻断构建 - 忽略策略要精确:用
exclude而非disable,例如只排除某类动态生成的iframe,而非整个frame规则
语义化标签不是“换名游戏”,而是无障碍树的准入凭证
浏览器解析 HTML 时,会并行构建渲染树和无障碍树(Accessibility Tree)。只有原生语义标签(如 nav、main、article)能自动注入无障碍树;div 加 role 是补救手段,但需手动补全所有相关属性(aria-labelledby、aria-expanded 等),稍有遗漏就会断裂。
使用 PptxGenJS 和 Python 解析,将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint(.pptx)演示文稿。
典型翻车场景:
- 用
div role="navigation"替代nav,但没加aria-label,屏幕阅读器读作“region”,用户无法识别这是导航区 -
section内没配h2~h6,导致结构扁平,语音导航时跳过整块内容 -
button元素内嵌svg,但svg未设aria-hidden="true",屏幕阅读器会重复读出图标描述
表单控件的可访问性闭环必须包含三要素
一个可被屏幕阅读器准确识别、键盘操作流畅、状态反馈明确的表单,缺一不可。只加 label 或只写 aria-describedby 都是半残废。
必须同时满足:
-
input有唯一id,且对应label的for值完全一致(注意空格、大小写) - 错误状态用
aria-invalid="true"+aria-describedby指向实时错误文案容器(不能只靠 CSS 隐藏/显示) - 禁用态用
disabled属性,而非仅靠opacity: 0.5+pointer-events: none,否则键盘仍可聚焦
最常被忽略的是:所有表单字段必须落在 form 标签内,且 form 应有 aria-labelledby 指向主标题,否则多页表单中屏幕阅读器无法建立上下文。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










