Back to Details

accessibility-audit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Accessibility Audit

无障碍审计

Run a thorough accessibility audit and produce a remediation plan. Stack-agnostic. Anchored to WCAG 2.1 AA, with notes on AAA where relevant.
This skill goes deeper than the accessibility checks in 
qa-testing
and 
design-standards
. Use this when accessibility itself is the goal.
执行全面的无障碍审计并制定整改方案。与技术栈无关。以WCAG 2.1 AA为核心标准，相关处会标注AAA级要求。
此技能比
qa-testing
和
design-standards
中的无障碍检查更深入。当无障碍性本身作为目标时使用此技能。

When to use

使用场景

  • Pre-launch accessibility verification
  • Compliance preparation (ADA, EN 301 549, AODA, Section 508)
  • Remediation after an audit finding or complaint
  • Annual or quarterly accessibility health check
  • Onboarding accessibility into a team that hasn't prioritized it before
  • 上线前无障碍验证
  • 合规准备（ADA、EN 301 549、AODA、Section 508）
  • 审计发现或投诉后的整改
  • 年度或季度无障碍健康检查
  • 向之前未重视无障碍性的团队引入无障碍规范

When NOT to use

不适用场景

  • General QA after deploys (use 
    qa-testing
    )
  • Component-level accessibility implementation (use 
    frontend-component-build
    )
  • Color contrast for design tokens (use 
    design-standards
    or 
    brand-identity
    )
  • 部署后的常规QA测试（使用
    qa-testing
    ）
  • 组件级无障碍实现（使用
    frontend-component-build
    ）
  • 设计令牌的颜色对比度检查（使用
    design-standards
    或
    brand-identity
    ）

Required inputs

必要输入

  • The site or product under audit
  • The scope (full site, specific section, specific user flow)
  • The target standard (WCAG 2.1 AA is most common)
  • Any specific concerns or known issues
  • Tools available (automated scanners, screen readers, manual testing)
  • 待审计的网站或产品
  • 审计范围（全站、特定板块、特定用户流程）
  • 目标标准（最常用的是WCAG 2.1 AA）
  • 任何特定关注点或已知问题
  • 可用工具（自动化扫描器、屏幕阅读器、手动测试工具）

The framework: WCAG's 4 principles

框架：WCAG的四大原则

WCAG organizes accessibility around four principles. The audit covers each in depth.
WCAG围绕四大原则组织无障碍要求，审计会深入覆盖每个原则。

1. Perceivable

1. 可感知

Information and UI must be presentable in ways users can perceive.
Audit checks:
  • Text alternatives. All non-decorative images have descriptive 
    alt
    text. Decorative images use 
    alt=""
    . Complex images (charts, infographics) have long descriptions.
  • Time-based media. Videos have captions. Pre-recorded audio has transcripts. Live audio has live captions where required.
  • Adaptable. Content structure is conveyed through markup (semantic HTML), not just visual styling. Reading order makes sense when CSS is disabled.
  • Distinguishable. Color is not the sole means of conveying information. Text contrast meets AA (4.5:1 normal, 3:1 large). UI element contrast meets 3:1. Audio can be paused, stopped, or muted.
信息和UI必须以用户可感知的方式呈现。
审计检查项：
  • 文本替代方案：所有非装饰性图片都有描述性
    alt
    文本。装饰性图片使用
    alt=""
    。复杂图片（图表、信息图）有详细说明。
  • 基于时间的媒体：视频配有字幕。预录制音频有文字转录。必要时直播音频提供实时字幕。
  • 可适应性：内容结构通过标记（语义化HTML）传达，而非仅依赖视觉样式。禁用CSS时阅读顺序仍合理。
  • 可区分性：颜色不是传达信息的唯一方式。文本对比度符合AA级标准（普通文本4.5:1，大文本3:1）。UI元素对比度达到3:1。音频可暂停、停止或静音。

2. Operable

2. 可操作

UI components and navigation must be operable.
Audit checks:
  • Keyboard accessible. All functionality available via keyboard alone. No keyboard traps. Focus visible.
  • Enough time. Time limits can be adjusted, paused, or extended. Auto-updating content can be paused.
  • Seizures and physical reactions. No content that flashes more than 3 times per second.
  • Navigable. Skip links present. Pages have descriptive titles. Focus order is logical. Link purpose clear from text or context. Multiple ways to find pages (sitemap, search, navigation). Headings and labels are descriptive.
  • Input modalities. Pointer gestures have keyboard alternatives. Pointer cancellation supported (mouse-up, not mouse-down for activation). Labels match accessible names. Motion-triggered functionality has alternatives.
UI组件和导航必须可操作。
审计检查项：
  • 键盘可访问：所有功能仅通过键盘即可使用。无键盘陷阱。焦点可见。
  • 充足时间：时间限制可调整、暂停或延长。自动更新的内容可暂停。
  • 避免癫痫和生理反应：无每秒闪烁超过3次的内容。
  • 可导航：存在跳转链接。页面有描述性标题。焦点顺序符合逻辑。链接用途可通过文本或上下文明确。有多种方式查找页面（站点地图、搜索、导航栏）。标题和标签具有描述性。
  • 输入方式：指针手势有键盘替代方案。支持指针取消（激活操作在鼠标抬起时触发，而非按下时）。标签与可访问名称匹配。动效触发的功能有替代方案。

3. Understandable

3. 可理解

Information and operation must be understandable.
Audit checks:
  • Readable. Page language declared (
    <html lang="...">
    ). Unusual words and abbreviations have definitions or expansions. Reading level appropriate to audience.
  • Predictable. Focus does not change context unexpectedly. Input does not change context unexpectedly. Navigation is consistent across pages. Components that look similar behave similarly.
  • Input assistance. Errors are identified clearly. Labels and instructions are provided for input. Error suggestions are given where possible. For pages handling legal commitments or financial transactions, errors can be reviewed and corrected before submission.
信息和操作必须易于理解。
审计检查项：
  • 可读性：声明页面语言（
    <html lang="...">
    ）。生僻词汇和缩写有定义或扩展说明。阅读水平符合目标受众需求。
  • 可预测性：焦点不会意外改变上下文。输入不会意外改变上下文。导航在各页面保持一致。外观相似的组件行为一致。
  • 输入辅助：错误被清晰标识。输入项配有标签和说明。尽可能提供错误修正建议。对于处理法律承诺或金融交易的页面，提交前可查看并修正错误。

4. Robust

4. 健壮性

Content must be robust enough to work with current and future user agents.
Audit checks:
  • Compatible. Markup is valid. Name, role, and value of UI components are programmatically determinable. Status messages can be programmatically determined and announced.
内容必须足够健壮，以适配当前和未来的用户代理。
审计检查项：
  • 兼容性：标记有效。UI组件的名称、角色和值可通过程序识别。状态消息可通过程序识别并播报。

Audit methodology

审计方法

Stage 1: Automated scan

阶段1：自动化扫描

Run automated scanners across the priority pages. These catch 30 to 50 percent of issues but miss the rest.
Tools:
  • axe DevTools (browser extension)
  • Lighthouse (Chrome DevTools accessibility audit)
  • WAVE (browser extension)
  • Pa11y (CLI for batch scanning)
Output: A list of automated findings, by page.
对优先级页面运行自动化扫描器。这类工具可发现30%至50%的问题，但会遗漏其余部分。
工具：
  • axe DevTools（浏览器扩展）
  • Lighthouse（Chrome DevTools无障碍审计）
  • WAVE（浏览器扩展）
  • Pa11y（批量扫描CLI工具）
输出： 按页面整理的自动化扫描发现列表。

Stage 2: Manual keyboard testing

阶段2：手动键盘测试

Unplug the mouse. Navigate the priority user flows using only keyboard.
Test:
  • Tab and Shift+Tab move through interactive elements in logical order
  • Enter activates buttons and links
  • Space activates buttons (and toggles checkboxes)
  • Arrow keys navigate within composite widgets (tabs, menus, listboxes)
  • Escape dismisses modals, popovers, menus
  • Focus is always visible
  • Focus returns to a sensible place after modals or popovers close
  • No keyboard trap (focus can always leave)
Document: Any flow where keyboard navigation breaks down.
拔掉鼠标，仅使用键盘导航优先级用户流程。
测试内容：
  • Tab和Shift+Tab按逻辑顺序遍历交互元素
  • Enter激活按钮和链接
  • Space激活按钮（并切换复选框）
  • 箭头键在复合组件（标签页、菜单、列表框）内导航
  • Escape关闭模态框、弹出层、菜单
  • 焦点始终可见
  • 关闭模态框或弹出层后焦点返回合理位置
  • 无键盘陷阱（焦点始终可离开）
记录： 键盘导航失效的任何流程。

Stage 3: Screen reader testing

阶段3：屏幕阅读器测试

Test with at least one real screen reader. Each combination has quirks.
Common combinations:
  • VoiceOver + Safari (macOS / iOS)
  • NVDA + Firefox or Chrome (Windows)
  • JAWS + Chrome (Windows; commercial but common in enterprise)
  • TalkBack + Chrome (Android)
Test:
  • Page structure announced correctly (headings, landmarks)
  • Form labels read with their inputs
  • Errors announced when they appear
  • Status changes announced (loading, success, error)
  • Modal context announced when opened
  • Images have meaningful alt text (or are correctly identified as decorative)
使用至少一款真实屏幕阅读器进行测试，每种组合都有其特性。
常见组合：
  • VoiceOver + Safari（macOS / iOS）
  • NVDA + Firefox或Chrome（Windows）
  • JAWS + Chrome（Windows；商用但企业中常用）
  • TalkBack + Chrome（Android）
测试内容：
  • 页面结构被正确播报（标题、地标）
  • 表单标签与输入项一同读取
  • 错误出现时被播报
  • 状态变化被播报（加载、成功、错误）
  • 模态框打开时上下文被播报
  • 图片有有意义的alt文本（或被正确识别为装饰性）

Stage 4: Visual testing

阶段4：视觉测试

Verify the visual aspects of accessibility.
Test:
  • Color contrast for all text/background pairs (use a contrast checker)
  • UI element contrast (3:1 for icons, borders, focus rings)
  • Color-blindness simulation (deuteranopia at minimum)
  • Zoom to 200% - content remains usable, no horizontal scroll
  • Reflow at 320px viewport
  • Text spacing applied (line height, letter spacing) - no content cut off
  • Motion can be reduced (
    prefers-reduced-motion
    honored)
验证无障碍性的视觉层面。
测试内容：
  • 所有文本/背景对的颜色对比度（使用对比度检查器）
  • UI元素对比度（图标、边框、焦点环需达到3:1）
  • 色盲模拟（至少测试绿色盲）
  • 放大至200% - 内容仍可用，无水平滚动
  • 在320px视口下重排
  • 应用文本间距（行高、字间距） - 无内容被截断
  • 动效可被减少（遵循
    prefers-reduced-motion
    设置）

Stage 5: Cognitive accessibility

阶段5：认知无障碍

Often overlooked. Critical for inclusive products.
Test:
  • Reading level appropriate
  • Instructions clear
  • Error messages explain how to fix the error, not just that one occurred
  • Forms allow correction before submission
  • Time limits avoidable or extendable
  • Important content not dependent on memory of prior pages
常被忽视，但对包容性产品至关重要。
测试内容：
  • 阅读水平合适
  • 说明清晰
  • 错误消息解释修复方法，而非仅提示错误存在
  • 表单允许提交前修正
  • 时间限制可避免或延长
  • 重要内容不依赖对之前页面的记忆

Workflow

工作流程

  1. Define scope. Full site? Specific flows? Specific page templates?
  2. Run automated scans. Document findings per page.
  3. Manual keyboard pass. Test all priority flows.
  4. Screen reader pass. Test with at least one combination.
  5. Visual checks. Contrast, zoom, color blindness, motion.
  6. Cognitive checks. Reading level, error handling, time limits.
  7. Score against WCAG. Per success criterion (level A, AA, AAA).
  8. Prioritize findings. Critical (blocks users), Important (degrades experience), Minor (polish).
  9. Write the report. Use the template in 
    references/audit-report-template.md
    .
  10. Build a remediation plan. Sequenced fixes with effort and impact estimates.
  1. 定义范围：全站？特定流程？特定页面模板？
  2. 运行自动化扫描：按页面记录发现结果。
  3. 手动键盘测试：测试所有优先级流程。
  4. 屏幕阅读器测试：使用至少一种组合测试。
  5. 视觉检查：对比度、缩放、色盲、动效。
  6. 认知检查：阅读水平、错误处理、时间限制。
  7. 对照WCAG评分：按成功标准（A级、AA级、AAA级）评分。
  8. 优先级排序：严重（阻碍用户）、重要（降低体验）、次要（优化项）。
  9. 撰写报告：使用
    [references/audit-report-template.md](references/audit-report-template.md)
    中的模板。
  10. 制定整改计划：按顺序排列修复项，并评估工作量和影响。

Severity classification

严重程度分类

For prioritization:
Critical (P0):
  • Blocks an entire user flow for an assistive-tech user
  • Renders a key page completely inaccessible
  • Examples: form with no labels, modal without focus management, primary CTA not keyboard-accessible
Important (P1):
  • Significantly degrades the experience for assistive-tech users
  • Examples: missing alt text on key images, low-contrast body text, error messages that don't announce
Minor (P2):
  • Affects edge cases or specific assistive technology combinations
  • Examples: minor focus order issues, missing decorative alt attributes, edge case keyboard handling
Polish (P3):
  • Above-AA improvements that benefit accessibility but aren't compliance-blocking
  • Examples: AAA contrast targets, additional reduced-motion variants, language attributes on inline foreign words
用于优先级排序：
严重（P0）：
  • 阻碍辅助技术用户完成整个用户流程
  • 导致关键页面完全无法访问
  • 示例：无标签的表单、无焦点管理的模态框、主要CTA无法通过键盘访问
重要（P1）：
  • 显著降低辅助技术用户的体验
  • 示例：关键图片缺少alt文本、正文文本对比度低、错误消息未播报
次要（P2）：
  • 影响边缘情况或特定辅助技术组合
  • 示例：轻微焦点顺序问题、装饰性图片缺少alt属性、边缘情况键盘处理问题
优化（P3）：
  • 超出AA级的无障碍改进，有助于提升体验但不影响合规
  • 示例：AAA级对比度目标、额外的减少动效变体、内联外文词汇的语言属性

Failure patterns

常见错误模式

  • Automated scan only. Catches 30 to 50 percent of issues. The remaining 50 to 70 percent are in keyboard, screen reader, and cognitive testing.
  • Testing only on the home page. The home page is usually the most accessible. Bugs hide in deeper flows.
  • Treating accessibility as a one-time project. Accessibility erodes with every deploy. Bake it into the development cycle.
  • Fixing without root cause. Patching individual issues without understanding why they happened means new ones keep appearing.
  • Ignoring screen reader testing. Hard to do well, easy to skip. Single biggest source of "we thought we were accessible" surprises.
  • Confusing AA and AAA. AAA is rarely the right target. AA is the practical baseline for most products.
  • Treating accessibility as a designer or developer responsibility alone. Content, product, QA, and leadership all need to participate.
  • Assuming compliance equals accessibility. WCAG conformance is a floor, not a ceiling. Real users may still struggle.
  • 仅依赖自动化扫描：仅能发现30%至50%的问题，剩余50%至70%存在于键盘、屏幕阅读器和认知测试中。
  • 仅测试首页：首页通常是最无障碍的页面，问题隐藏在更深层的流程中。
  • 将无障碍视为一次性项目：每次部署都会削弱无障碍性，需将其融入开发周期。
  • 修复而不找根本原因：仅修补个别问题而不理解原因，会导致新问题不断出现。
  • 忽略屏幕阅读器测试：难以做好但容易跳过，是“我们以为自己无障碍”这类意外的最大来源。
  • 混淆AA级和AAA级：AAA级很少是合适的目标，AA级是大多数产品的实用基线。
  • 将无障碍仅视为设计师或开发者的责任：内容、产品、QA和管理层都需要参与。
  • 认为合规等同于无障碍：WCAG合规是底线而非上限，真实用户仍可能遇到困难。

Output format

输出格式

Default output is a comprehensive audit report at 
accessibility-audit.md
.
Structure:
  1. Executive summary
  2. Methodology (tools used, pages tested, screen readers used)
  3. Findings by WCAG principle
  4. Critical findings (P0) with specific URLs and fixes
  5. Important findings (P1)
  6. Minor findings (P2)
  7. Polish (P3)
  8. Remediation roadmap (sequenced and prioritized)
  9. Appendices (full automated scan results, keyboard navigation notes, screen reader notes)
Plus a remediation tracking spreadsheet with one row per finding.
默认输出为
accessibility-audit.md
中的全面审计报告。
结构：
  1. 执行摘要
  2. 方法（使用的工具、测试的页面、使用的屏幕阅读器）
  3. 按WCAG原则分类的发现结果
  4. 严重发现（P0），含具体URL和修复方案
  5. 重要发现（P1）
  6. 次要发现（P2）
  7. 优化项（P3）
  8. 整改路线图（按顺序和优先级排列）
  9. 附录（完整自动化扫描结果、键盘导航记录、屏幕阅读器记录）
此外还有一个整改跟踪表格，每条发现对应一行。

Reference files

参考文件

  • references/audit-report-template.md
     - Full audit report template.
  • references/wcag-quick-reference.md
     - Condensed WCAG 2.1 AA criteria with audit checks.
  • references/aria-patterns.md
     - Decision-grade ARIA patterns. Semantic-HTML-first principle, common interactive widgets (accordion, tabs, modal, toggle, disclosure, navigation), live regions, hiding patterns, labeling, state indicators, anti-patterns.
  • [references/audit-report-template.md](references/audit-report-template.md)
    - 完整审计报告模板。
  • [references/wcag-quick-reference.md](references/wcag-quick-reference.md)
    - 浓缩版WCAG 2.1 AA标准及审计检查项。
  • [references/aria-patterns.md](references/aria-patterns.md)
    - 决策级ARIA模式。以语义化HTML优先原则，涵盖常见交互组件（折叠面板、标签页、模态框、切换器、披露组件、导航）、实时区域、隐藏模式、标签、状态指示器、反模式。