5.9 KiB
5.9 KiB
title, type, tags, date, last_updated
| title | type | tags | date | last_updated |
|---|---|---|---|---|
| Accessibility Auditor Agent Personality | source | 2026-04-25 | 2026-05-11 |
Source File
Summary（用中文描述）
- 核心主题：AI Agent 的无障碍审计专家人格定义，专注于 WCAG 标准合规性检测和辅助技术测试
- 问题域：无障碍测试（Accessibility Testing）、WCAG 合规性评估、辅助技术（屏幕阅读器、键盘导航）验证
- 方法/机制：
- 基于 WCAG 2.2 AA 标准进行自动化扫描 + 手动辅助技术测试双重验证
- 四项 POUR 原则评估（可感知 Perceivable、可操作 Operable、可理解 Understandable、健壮 Robust）
- 屏幕阅读器（VoiceOver/NVDA/JAWS）真实交互流测试
- 键盘-only 导航完整测试（含所有交互组件的键盘模式）
- 提供结构化审计报告模板，包含问题严重性分级（Critical/Serious/Moderate/Minor）和修复建议
- 屏幕阅读器测试协议、键盘导航审计清单
- 结论/价值：为 AI Agent 提供一套完整的无障碍审计方法论，确保数字产品对残障用户的真实可用性；区分"技术合规"与"实际可访问"
Key Claims（用中文描述）
- 自动化工具仅能发现约 30% 的无障碍问题，剩余 70% 需手动辅助技术测试发现
- Lighthouse 绿色分数不等于无障碍可用——自定义组件（标签页、模态框、轮播图、日期选择器）在证明无障碍前均视为有问题
- 所有交互流程必须支持纯键盘操作，"鼠标可用"不是有效的无障碍测试
- 语义化 HTML 优于 ARIA——最好的 ARIA 是不需要 ARIA
- 无障碍不是开发末期完成的清单，而是每个阶段都要倡导的实践
Key Quotes
"If it's not tested with a screen reader, it's not accessible." — AccessibilityAuditor 核心原则 "Automated tools catch roughly 30% of accessibility issues — you catch the other 70%" — 自动化 vs 手动测试的差距 "Custom components (tabs, modals, carousels, date pickers) are guilty until proven innocent" — 自定义组件无障碍审查原则 "A green Lighthouse score does not mean accessible" — 合规性检查的诚实评估原则 "Decorative images with alt text and interactive elements without labels are equally harmful" — 平等对待所有无障碍问题
Key Concepts
- WCAG 2.2: Web Content Accessibility Guidelines 2.2，网页内容无障碍指南，审计标准的核心框架，审计基准为 AA 级别
- POUR Principles: 可感知（Perceivable）、可操作（Operable）、可理解（Understandable）、健壮（Robust），WCAG 的四项核心原则
- ARIA: Accessible Rich Internet Applications，WAI-ARIA 规范，用于增强自定义组件的无障碍支持；最佳实践为优先使用语义化 HTML 而非 ARIA
- Screen Reader Testing: 屏幕阅读器测试（VoiceOver/NVDA/JAWS），验证动态内容和交互组件的语音播报正确性，包含读序、焦点管理、实时区域播报
- Keyboard Navigation Audit: 键盘导航审计，确保所有交互元素可通过 Tab/方向键访问且无键盘陷阱，包含跳导航链接、焦点可见性、模态框焦点返回
- axe-core: 自动化无障碍扫描工具，可集成到 CI/CD 流程中用于回归测试
- Focus Management: 焦点管理，动态内容加载时焦点应正确转移且不丢失，是单页应用无障碍的关键
- Live Regions: ARIA 实时区域，用于向屏幕阅读器用户播报状态更新和通知，无需焦点改变即可播报
- WAI-ARIA Authoring Practices: W3C 发布的 WAI-ARIA 创作实践指南，定义自定义组件的标准无障碍模式和键盘交互
- Lighthouse Accessibility Score: Chrome DevTools 内置无障碍分数，仅覆盖约 30% 问题，不能替代真实辅助技术测试
Key Entities
- VoiceOver: Apple 屏幕阅读器（macOS/iOS），AccessibilityAuditor 主要测试环境之一
- NVDA: NonVisual Desktop Access，Windows 平台开源屏幕阅读器
- JAWS: Job Access With Speech，Windows 商业屏幕阅读器
- axe-core: Deque Labs 开发的自动化无障碍测试引擎，支持 CI/CD 集成
- Lighthouse: Chrome DevTools 内置审计工具，可生成无障碍分数但不足以验证真实可用性
- WAI-ARIA: W3C Web Accessibility Initiative 发布的富互联网应用无障碍规范
- Dragon NaturallySpeaking: 语音控制软件，用于验证语音控制兼容性
Connections
- Testing Tool Evaluator ← 协同 → Testing Evidence Collector
- Testing Reality Checker ← 供给无障碍证据 → Accessibility Auditor
- Frontend Developer ← 接收修复建议 → Accessibility Auditor
- UI Designer ← 审计设计 token 对比度/间距/目标尺寸 → Accessibility Auditor
- UX Researcher ← 贡献无障碍发现到用户洞察 → Accessibility Auditor
- Legal Compliance Checker ← 关联 ADA Title III/Section 508/EAA 合规要求 → Accessibility Auditor
- Testing Evidence Collector ← 提供无障碍特定测试用例 → Accessibility Auditor
- Cultural Intelligence Strategist ← 确保简单语言错误恢复不意外剥离文化语境 → Accessibility Auditor
Contradictions
- 与 Testing Tool Evaluator 的潜在冲突：
- 冲突点：自动化工具（如 axe-core/Lighthouse）的充分性评估
- 当前观点（AccessibilityAuditor）：自动化工具只能覆盖 30%，不能替代手动辅助技术测试
- 对方观点（Tool Evaluator）：倾向于相信自动化工具的检测能力和评分
- 建议：两者协同使用，自动化工具作为基线扫描，手动测试作为深度验证
- 与合规性追求的内在张力：
- AccessibilityAuditor 明确反对"合规剧院"（Compliance Theater）——仅追求通过自动化检查而不解决真实可用性问题
- 与部分只看 Lighthouse 分数的利益相关者存在实践层面的分歧