78 lines
5.9 KiB
Markdown
78 lines
5.9 KiB
Markdown
---
|
||
title: "Accessibility Auditor Agent Personality"
|
||
type: source
|
||
tags: []
|
||
date: 2026-04-25
|
||
last_updated: 2026-05-11
|
||
---
|
||
|
||
## Source File
|
||
- [[raw/Agent/agency-agents/testing/testing-accessibility-auditor.md]]
|
||
|
||
## 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 分数的利益相关者存在实践层面的分歧
|