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% 以上高风险项。

推荐配置方式：

立即学习“前端免费学习笔记（深入）”；

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 开发阶段：VS Code 安装 HTMLHint 和 axe DevTools 插件，前者实时标出 img[alt] 缺失，后者在浏览器调试时一键触发完整扫描
• CI 流程：在 npm test 中加入 axe-core CLI 调用，对本地服务的 /index.html 页面做快照检测，失败时阻断构建
• 忽略策略要精确：用 exclude 而非 disable，例如只排除某类动态生成的 iframe，而非整个 frame 规则

语义化标签不是“换名游戏”，而是无障碍树的准入凭证

浏览器解析 HTML 时，会并行构建渲染树和无障碍树（Accessibility Tree）。只有原生语义标签（如 nav、main、article）能自动注入无障碍树；div 加 role 是补救手段，但需手动补全所有相关属性（aria-labelledby、aria-expanded 等），稍有遗漏就会断裂。

典型翻车场景：

• 用 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 指向主标题，否则多页表单中屏幕阅读器无法建立上下文。