Back to Details

manual-testing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Manual Accessibility Testing Skill

手动可访问性测试Skill

Canonical source: 
examples/MANUAL_ACCESSIBILITY_TESTING_GUIDE.md
in 
mgifford/ACCESSIBILITY.md
This skill is derived from that file. When in doubt, the example is authoritative.
Apply these rules when planning or reviewing manual accessibility testing.
标准来源：
mgifford/ACCESSIBILITY.md
中的
examples/MANUAL_ACCESSIBILITY_TESTING_GUIDE.md
本Skill源自该文件。如有疑问，以示例文件为准。
在规划或评审手动可访问性测试时，请遵循以下规则。

Severity Scale (this skill)

严重程度分级（本Skill）

LevelMeaning
CriticalIssue completely blocks a core task for one or more disability groups
SeriousSignificantly impairs access; workaround unreasonable to expect
ModerateCreates friction; workaround exists and is not too burdensome
MinorBest-practice gap; marginal impact on access
级别含义
Critical（严重）问题完全阻碍一个或多个残疾群体完成核心任务
Serious（较严重）严重影响访问；无法期望用户使用合理的替代方案
Moderate（中等）造成使用阻碍；存在替代方案且不会带来过重负担
Minor（轻微）最佳实践缺失；对访问的影响极小

Core Principle

核心原则

Manual testing reveals issues that automated tools cannot detect, including:
  • Screen reader announcement quality and user experience
  • Keyboard navigation flow and logical sequence
  • Focus management in dynamic interfaces
  • Context and orientation for assistive technology users
  • Forced colors mode (Windows High Contrast) — automated tools cannot simulate OS-level color overrides
  • Real-world usability barriers
手动测试能发现自动化工具无法检测的问题，包括：
  • 屏幕阅读器的播报质量与用户体验
  • 键盘导航流程与逻辑顺序
  • 动态界面中的焦点管理
  • 辅助技术用户的上下文与定位
  • forced colors mode（Windows高对比度模式）——自动化工具无法模拟系统级颜色覆盖
  • 真实场景中的可用性障碍

Critical: When Manual Testing Is Required

Critical：必须进行手动测试的场景

Perform manual testing:
  • Before each release — test critical user flows end to end
  • After UI changes — test all affected components
  • For new features — test complete user workflows
  • When automated tests pass — validate actual user experience
  • When accessibility bugs are reported — reproduce and verify fixes
Getting started: test keyboard-only first (easiest entry point), then learn basic screen reader commands for your platform. Practice on familiar websites before testing your own. Focus on one component or flow at a time.
在以下场景执行手动测试：
  • 每次发布前——端到端测试关键用户流程
  • UI变更后——测试所有受影响的组件
  • 新功能上线时——测试完整用户工作流
  • 自动化测试通过后——验证实际用户体验
  • 收到可访问性缺陷报告时——复现并验证修复效果
入门建议：先从纯键盘测试开始（最容易上手），然后学习对应平台的基础屏幕阅读器命令。先在熟悉的网站上练习，再测试自己的项目。一次专注于一个组件或流程。

Critical: Keyboard-Only Testing

Critical：纯键盘测试

Every interactive element must be reachable and operable by keyboard alone.
Steps:
  1. Click in the browser address bar, then press Tab to start from page top
  2. Tab through entire page; check each focusable element:
    • Is focus visible (clear outline or highlight)?
    • Is focus order logical (follows visual/reading order)?
    • Can you activate it? (Enter for links/buttons, Space for buttons/checkboxes)
  3. Press Shift+Tab to reverse through elements
  4. Confirm there are no keyboard traps (can you Tab away from every element?)
Key shortcuts to verify:
KeyExpected behaviour
TabMove focus forward
Shift+TabMove focus backward
EnterActivate links, buttons, submit forms
SpaceActivate buttons, toggle checkboxes
Arrow keysNavigate within components (menus, tabs, radio groups)
EscapeClose dialogs, cancel operations
Home / EndJump to start/end of component
Component-specific checks:
  • Forms: all fields reachable; labels and required state announced; errors appear and are announced; Enter submits; can cancel/reset if applicable
  • Buttons: Enter and Space both activate; visual feedback on activation; focus moves appropriately after activation
  • Links: Enter activates; destination clear from link text; skip links work
  • Dropdowns/select menus: arrow keys navigate options; Escape closes; selected value announced
  • Modal dialogs: focus moves in on open; focus trapped inside; Escape closes (unless critical); focus returns to trigger on close
  • Custom widgets (tabs, accordions, carousels): follow WAI-ARIA keyboard patterns; arrow keys and Home/End work as documented; state changes are clear
每个交互元素都必须仅通过键盘即可访问和操作。
步骤：
  1. 点击浏览器地址栏，然后按Tab键从页面顶部开始导航
  2. 按Tab键遍历整个页面；检查每个可获取焦点的元素：
    • 焦点是否可见（清晰的轮廓或高亮）？
    • 焦点顺序是否符合逻辑（遵循视觉/阅读顺序）？
    • 是否可以激活？（链接/按钮用Enter，按钮/复选框用Space）
  3. 按Shift+Tab反向遍历元素
  4. 确认不存在键盘陷阱（能否从每个元素Tab离开？）
需要验证的快捷键：
按键预期行为
Tab向前移动焦点
Shift+Tab向后移动焦点
Enter激活链接、按钮，提交表单
Space激活按钮，切换复选框状态
方向键在组件内导航（菜单、标签页、单选按钮组）
Escape关闭对话框，取消操作
Home / End跳转到组件的开头/结尾
组件专项检查：
  • 表单：所有字段均可访问；标签和必填状态会被播报；错误信息会显示并被播报；按Enter可提交；如有需要可取消/重置
  • 按钮：Enter和Space均可激活；激活时有视觉反馈；激活后焦点移动合理
  • 链接：按Enter可激活；链接文本能清晰体现跳转目标；跳转链接可正常工作
  • 下拉菜单/选择框：方向键可导航选项；Escape可关闭；选中值会被播报
  • 模态对话框：打开时焦点移入；焦点被限制在对话框内；Escape可关闭（除非是关键操作）；关闭后焦点返回触发元素
  • 自定义组件（标签页、折叠面板、轮播图）：遵循WAI-ARIA键盘交互模式；方向键和Home/End可按文档说明工作；状态变化清晰可见

Critical: Screen Reader Testing

Critical：屏幕阅读器测试

Recommended platform pairings:
  • NVDA + Firefox or Chrome (Windows)
  • JAWS + Chrome or Firefox (Windows)
  • VoiceOver + Safari (macOS / iOS)
  • TalkBack + Chrome (Android)
Basic test procedure:
  1. Start screen reader (NVDA: Ctrl+Alt+N; VoiceOver macOS: Cmd+F5)
  2. Navigate by headings (NVDA/JAWS: H / Shift+H) — do they form a logical outline?
  3. Navigate by landmarks (NVDA/JAWS: D / Shift+D) — are 
    <nav>
    , 
    <main>
    , 
    <header>
    identified?
  4. Navigate by form controls (NVDA/JAWS: F / Shift+F) — are labels announced?
  5. Read all content — is order logical? Any missing or confusing announcements?
Component-specific screen reader checks:
  • Images: decorative images ignored (empty alt/
    aria-hidden
    ); informative images have descriptive alt text; complex images have longer descriptions
  • Links: purpose clear from announcement alone; text meaningful (not "click here"); external links/new windows indicated
  • Buttons: label describes the action; pressed/toggle state announced; disabled state announced
  • Form fields: label announced before field type; required state, instructions/hints, error messages, and success messages all announced
  • Dynamic content: new/deleted content announced via live regions; loading states and progress communicated
  • Tables: navigate by rows/cells (Ctrl+Alt+Arrow in NVDA/JAWS); column and row headers announced with each cell; table purpose clear (caption or 
    aria-label
    )
  • Custom widgets: role announced (e.g., "tab", "menu", "dialog"); state announced (e.g., "selected", "expanded"); instructions provided for complex widgets
For each interactive element, verify:
  • Element type is announced (button, link, heading…)
  • Label/name is clear and descriptive
  • Current value is announced (form fields)
  • State is announced (checked, selected, expanded…)
  • Changes are announced (dynamic updates, live regions)
推荐平台组合：
  • NVDA + Firefox或Chrome（Windows）
  • JAWS + Chrome或Firefox（Windows）
  • VoiceOver + Safari（macOS / iOS）
  • TalkBack + Chrome（Android）
基础测试流程：
  1. 启动屏幕阅读器（NVDA：Ctrl+Alt+N；VoiceOver macOS：Cmd+F5）
  2. 按标题导航（NVDA/JAWS：H / Shift+H）——标题是否构成逻辑大纲？
  3. 按地标导航（NVDA/JAWS：D / Shift+D）——
    <nav>
    、
    <main>
    、
    <header>
    是否被正确识别？
  4. 按表单控件导航（NVDA/JAWS：F / Shift+F）——标签是否被播报？
  5. 阅读所有内容——顺序是否符合逻辑？是否有缺失或易混淆的播报？
组件专项屏幕阅读器检查：
  • 图片：装饰性图片被忽略（空alt属性/
    aria-hidden
    ）；信息性图片有描述性alt文本；复杂图片有详细说明
  • 链接：仅通过播报即可明确用途；文本有意义（避免使用“点击这里”）；外部链接/新窗口有明确标识
  • 按钮：标签描述操作内容；按下/切换状态会被播报；禁用状态会被播报
  • 表单字段：字段类型前会播报标签；必填状态、说明/提示、错误信息、成功信息均会被播报
  • 动态内容：新增/删除内容通过实时区域播报；加载状态和进度会被传达
  • 表格：按行/单元格导航（NVDA/JAWS：Ctrl+Alt+方向键）；每个单元格都会播报列标题和行标题；表格用途清晰（有标题或
    aria-label
    ）
  • 自定义组件：角色会被播报（如“tab”、“menu”、“dialog”）；状态会被播报（如“selected”、“expanded”）；复杂组件会提供操作说明
对每个交互元素，需验证：
  • 元素类型被正确播报（按钮、链接、标题等）
  • 标签/名称清晰且具有描述性
  • 当前值被播报（表单字段）
  • 状态被播报（已勾选、已选中、已展开等）
  • 变化被播报（动态更新、实时区域）

Serious: Forced Colors Mode Testing

Serious：forced colors mode测试

Why automated tools miss this: forced colors is triggered by an OS-level setting that replaces all author-defined colors with a constrained system palette. Automated tools cannot simulate the OS-level override, detect which elements become invisible when custom colors are stripped, or assess whether focus indicators/icons/custom controls survive the substitution.
How to enable:
  • Windows 11: Settings → Accessibility → Contrast themes → choose a theme → Apply
  • Windows 10: Settings → Ease of Access → High Contrast → turn on (or 
    Alt+Left Shift+Print Screen
    )
  • Chrome/Edge DevTools: F12 → More Tools → Rendering → "Emulate CSS media feature forced-colors" → 
    active
  • Firefox: 
    about:config
    → 
    ui.forcedColors
    → set to 
    1
    (
    -1
    to reset)
  • Polypane includes a forced-colors emulation panel
Always verify with real OS settings before release — DevTools emulation is convenient but not fully equivalent.
What to look for:
  • All text is readable against its background (
    CanvasText
    on 
    Canvas
    )
  • Buttons have a visible boundary; links distinguishable from body text; form fields have visible borders
  • Keyboard focus outlines are visible (
    outline
    is preserved; 
    box-shadow
    may not be)
  • SVG icons are visible (use 
    currentColor
    for 
    fill
    /
    stroke
    )
  • Custom checkboxes / radio buttons remain visible and distinguishable; toggle state shown via text/ARIA/outline, not color alone
  • Error states are identifiable without relying on color alone; required fields marked with text or icons, not only color
  • Background images that convey meaning have a text/ARIA alternative
  • Charts/data visualizations use pattern/texture/label alternatives
Common fixes:
IssueFix
box-shadow
focus ring disappears		Replace with 
outline
SVG icon invisibleUse 
currentColor
for 
fill
/
stroke
Custom checkbox invisibleAdd visible border; use 
forced-color-adjust
override
Error marked by color onlyAdd icon, text label, or 
aria-invalid
Input invisible (
border: none
)		Add 
border: 1px solid ButtonBorder
in 
@media (forced-colors: active)
Background image removedAdd visible text, caption, or 
aria-label
CSS system color keywords for patching:
css
@media (forced-colors: active) {
  :focus-visible {
    outline: 3px solid Highlight;
    outline-offset: 2px;
  }
  .custom-checkbox::before {
    forced-color-adjust: none;
    border: 2px solid ButtonBorder;
    background-color: ButtonFace;
  }
  .custom-checkbox[aria-checked="true"]::before {
    background-color: Highlight;
  }
}
Relevant keywords: 
Canvas
, 
CanvasText
, 
ButtonFace
, 
ButtonText
, 
ButtonBorder
, 
Highlight
, 
HighlightText
, 
LinkText
, 
VisitedText
, 
GrayText
.
Use 
forced-color-adjust: none
only as a last resort — it opts the element out of forced colors entirely and can negate the user's accessibility settings.
自动化工具为何遗漏此问题：forced colors由系统级设置触发，会将所有自定义颜色替换为受限的系统调色板。自动化工具无法模拟系统级覆盖，无法检测自定义颜色被移除后变得不可见的元素，也无法评估焦点指示器/图标/自定义控件在替换后是否仍可正常显示。
启用方法：
  • Windows 11：设置 → 辅助功能 → 对比度主题 → 选择主题 → 应用
  • Windows 10：设置 → 轻松使用 → 高对比度 → 开启（或按
    Alt+Left Shift+Print Screen
    ）
  • Chrome/Edge开发者工具：F12 → 更多工具 → 渲染 → "模拟CSS媒体特性forced-colors" → 
    active
  • Firefox：
    about:config
    → 
    ui.forcedColors
    → 设置为
    1
    （设置为
    -1
    重置）
  • Polypane包含forced-colors模拟面板
发布前务必使用真实系统设置验证——开发者工具模拟虽便捷，但无法完全替代真实环境。
检查要点：
  • 所有文本在背景上均可读（
    CanvasText
    在
    Canvas
    上）
  • 按钮有可见边界；链接与正文文本可区分；表单字段有可见边框
  • 键盘焦点指示器可见（
    outline
    会被保留；
    box-shadow
    可能不会）
  • SVG图标可见（
    fill
    /
    stroke
    使用
    currentColor
    ）
  • 自定义复选框/单选按钮保持可见且可区分；切换状态通过文本/ARIA/轮廓显示，而非仅依赖颜色
  • 错误状态无需仅依赖颜色即可识别；必填字段用文本或图标标记，而非仅颜色
  • 传达意义的背景图片有文本/ARIA替代方案
  • 图表/数据可视化使用图案/纹理/标签替代方案
常见修复方案：
问题修复方法
box-shadow
焦点环消失		替换为
outline
SVG图标不可见
fill
/
stroke
使用
currentColor
自定义复选框不可见添加可见边框；使用
forced-color-adjust
覆盖
仅用颜色标记错误添加图标、文本标签或
aria-invalid
输入框不可见（
border: none
）		在
@media (forced-colors: active)
中添加
border: 1px solid ButtonBorder
背景图片被移除添加可见文本、标题或
aria-label
用于修复的CSS系统颜色关键字：
css
@media (forced-colors: active) {
  :focus-visible {
    outline: 3px solid Highlight;
    outline-offset: 2px;
  }
  .custom-checkbox::before {
    forced-color-adjust: none;
    border: 2px solid ButtonBorder;
    background-color: ButtonFace;
  }
  .custom-checkbox[aria-checked="true"]::before {
    background-color: Highlight;
  }
}
相关关键字：
Canvas
, 
CanvasText
, 
ButtonFace
, 
ButtonText
, 
ButtonBorder
, 
Highlight
, 
HighlightText
, 
LinkText
, 
VisitedText
, 
GrayText
.
仅在万不得已时使用
forced-color-adjust: none
——它会让元素完全脱离forced colors控制，可能会违背用户的辅助功能设置。

Moderate: Visual Accessibility Checks

Moderate：视觉可访问性检查

Color contrast

颜色对比度

  • Normal text (< 18 pt or < 14 pt bold): 4.5:1 minimum
  • Large text (≥ 18 pt or ≥ 14 pt bold): 3:1 minimum
  • UI components and graphics: 3:1 minimum
  • Focus indicators: 3:1 against adjacent colors
Test with: WebAIM Contrast Checker, browser DevTools. Test light and dark color modes separately.
  • 普通文本（<18号或<14号粗体）：最低4.5:1
  • 大文本（≥18号或≥14号粗体）：最低3:1
  • UI组件和图形：最低3:1
  • 焦点指示器：与相邻颜色对比度最低3:1
测试工具：WebAIM对比度检查器、浏览器开发者工具。分别测试亮色和暗色模式。

SC 1.4.4 Resize Text vs. SC 1.4.10 Reflow — do not conflate

SC 1.4.4 调整文本大小 vs. SC 1.4.10 重排——不要混淆

These are two distinct success criteria with different tests. A page can pass one and fail the other, and horizontal scrolling at 200% zoom is not automatically a failure of either.
SC 1.4.4 Resize Text (AA): content must be resizable up to 200% without loss of content or functionality. Checks text enlargement specifically — it does not itself require eliminating horizontal scrolling.
  1. Set browser zoom to 200% (Ctrl/Cmd + +)
  2. Verify all content is readable and not cut off or overlapping
  3. Verify functionality (menus, forms, controls) still works at 200%
  4. Also test with OS-level screen magnification (Windows Magnifier, macOS Zoom)
SC 1.4.10 Reflow (AA): content must be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at a viewport width equivalent to 320 CSS pixels (a common way to test this on desktop is a 1280px-wide viewport at 400% zoom — the two are equivalent).
  1. Set the viewport to 320 CSS pixels wide (or 400% zoom on a 1280px viewport)
  2. Verify content does not require horizontal scrolling to read, for non-excepted content — see the exception below
  3. Verify no content is cut off, overlapped, or hidden
  4. Verify interactive elements remain operable
  5. Verify reading order, relationships, and operation are preserved without relying on the original visual layout
The exception, precisely: SC 1.4.10 exempts only parts of content that require two-dimensional layout for their usage or meaning — not the page as a whole. Normative examples: data tables, maps, diagrams, video players, games, presentations, interfaces requiring a persistently visible toolbar. An excepted component does not exempt the rest of the page (the heading above a data table, filters, search, pagination must still reflow). Within an excepted component, individual sections may still need to reflow. "Requires" is a meaning test, not a convenience test — a component that merely looks better in a wide fixed layout, without losing information or functionality if it reflowed, is not exempt.
A page that triggers horizontal scroll at 400% zoom (or the 320px equivalent) is a high-value indicator that Reflow has not been achieved, but investigate whether the overflowing content falls within the exception before concluding a failure. See Behavioral Accessibility Automation (
skills/behavioral-a11y/SKILL.md
) for a reusable, tested Playwright Reflow risk indicator and its documented limitations — it is an indicator, not a Reflow conformance check; human judgment is still required to confirm the exception, verify content isn't cut off, and test actual content at 400% zoom.
这是两个不同的成功准则，测试方法也不同。页面可能通过其中一个但未通过另一个，且200%缩放时出现水平滚动并不自动意味着违反任一准则。
SC 1.4.4 调整文本大小（AA级）：内容可放大至200%而不丢失内容或功能。专门检查文本放大——本身不要求消除水平滚动。
  1. 将浏览器缩放设置为200%（Ctrl/Cmd + +）
  2. 验证所有内容可读，无截断或重叠
  3. 验证功能（菜单、表单、控件）在200%缩放时仍可正常工作
  4. 同时测试系统级屏幕放大功能（Windows放大镜、macOS缩放）
SC 1.4.10 重排（AA级）：内容必须在不丢失信息或功能、无需双向滚动的情况下呈现，视口宽度相当于320 CSS像素（桌面端常见测试方式为1280px宽视口设置400%缩放——两者等效）。
  1. 将视口设置为320 CSS像素宽（或在1280px视口上设置400%缩放）
  2. 验证非豁免内容无需水平滚动即可阅读——见下方豁免说明
  3. 验证无内容被截断、重叠或隐藏
  4. 验证交互元素仍可操作
  5. 验证阅读顺序、元素关系和操作逻辑无需依赖原始视觉布局即可保留
明确豁免规则：SC 1.4.10仅豁免因使用或含义需要二维布局的内容部分——而非整个页面。标准示例：数据表、地图、图表、视频播放器、游戏、演示文稿、需要持续显示工具栏的界面。豁免组件不代表页面其余部分也可豁免（数据表上方的标题、筛选器、搜索、分页仍需重排）。在豁免组件内，个别部分可能仍需重排。“需要”是指含义层面的需求，而非便利性需求——仅在宽固定布局中显示效果更好，但重排后不会丢失信息或功能的组件，不属于豁免范围。
在400%缩放（或等效320px视口）时触发水平滚动的页面，是未达到重排要求的重要信号，但在判定失败前，需调查溢出内容是否属于豁免范围。详情请见Behavioral Accessibility Automation（
skills/behavioral-a11y/SKILL.md
），其中包含可复用、经过测试的Playwright重排风险指示器及其文档化限制——它仅作为指示器，而非重排合规性检查；仍需人工判断以确认豁免情况、验证内容未被截断，并在400%缩放时测试实际内容。

Focus indicator: three distinct success criteria

焦点指示器：三个不同的成功准则

SC 2.4.7 Focus Visible (AA): every keyboard-focusable element must have a visible focus indicator. Binary check — either a visible indicator exists or it does not.
  • Focus indicator is visible for every focusable element
  • Focus indicator is not removed unless replaced with a superior alternative
  • Focus indicator is not obscured by other content
SC 1.4.11 Non-text Contrast (AA): focus indicators on UI components must have a contrast ratio of at least 3:1 against adjacent colors. Applies to the indicator itself, not the component's normal state.
  • Focus indicator contrast meets 3:1 against adjacent colors, measured against the indicator color and the adjacent background/component color
  • Custom focus styles meet the contrast requirement (not just the default outline)
SC 2.4.13 Focus Appearance (AAA): stricter than SC 2.4.7 — requires a minimum area equal to the focusable element's perimeter × 2 CSS pixels, a 3:1 contrast ratio between focused and unfocused states, and the indicator must not be fully obscured by author-created content. Projects targeting AA are not required to meet this, but meeting it provides stronger accessibility; document whether your project targets it.
Behavioral screenshot-difference testing: the CWAC project's 
FocusIndicatorAudit
sends real Tab presses and compares whole-page screenshots before/after each press, reporting a finding when no pixels changed. It does not measure contrast (SC 1.4.11), prove a detected change is local to the focused element (its comparison is whole-page), determine an indicator is sufficiently perceptible, or distinguish a missing indicator from one obscured by other content. This repository's own reusable implementation (
skills/behavioral-a11y/SKILL.md
, 
focus-visible-risk.mjs
) is an independent reimplementation of the documented method that instead captures a fresh unfocused/focused screenshot pair scoped to a padded region around each element, closing some of CWAC's whole-page limitations while introducing its own documented tradeoffs. Neither implementation, nor any screenshot-diff approach alone, verifies SC 1.4.11 (contrast) or SC 2.4.13 (minimum area). Use screenshot-difference testing as a supplementary check alongside manual verification, not as a sole focus indicator test.
SC 2.4.7 焦点可见（AA级）：每个可通过键盘获取焦点的元素必须有可见的焦点指示器。二元检查——要么存在可见指示器，要么不存在。
  • 每个可获取焦点的元素都有可见的焦点指示器
  • 焦点指示器未被移除，除非替换为更优的替代方案
  • 焦点指示器未被其他内容遮挡
SC 1.4.11 非文本对比度（AA级）：UI组件上的焦点指示器与相邻颜色的对比度必须至少为3:1。适用于指示器本身，而非组件的正常状态。
  • 焦点指示器与相邻颜色的对比度达到3:1，需针对指示器颜色与相邻背景/组件颜色进行测量
  • 自定义焦点样式符合对比度要求（不仅是默认轮廓）
SC 2.4.13 焦点外观（AAA级）：比SC 2.4.7更严格——要求焦点指示器的最小面积等于可获取焦点元素的周长×2 CSS像素，聚焦与非聚焦状态的对比度为3:1，且指示器不得被作者创建的内容完全遮挡。目标为AA级的项目无需满足此要求，但满足此要求可提供更强的可访问性；请记录你的项目是否以此为目标。
行为截图差异测试：CWAC项目的
FocusIndicatorAudit
会发送真实的Tab按键，并比较每次按键前后的整页截图，当像素无变化时报告问题。它不测量对比度（SC 1.4.11），无法证明检测到的变化仅局限于聚焦元素（其对比为整页范围），无法判断指示器是否足够明显，也无法区分缺失的指示器与被其他内容遮挡的指示器。本仓库的独立实现（
skills/behavioral-a11y/SKILL.md
，
focus-visible-risk.mjs
）是该文档化方法的重新实现，改为捕获每个元素周围填充区域的新鲜未聚焦/聚焦截图对，弥补了CWAC整页对比的部分局限，但也引入了自身的文档化权衡。无论是哪种实现，还是任何仅依赖截图差异的方法，都无法验证SC 1.4.11（对比度）或SC 2.4.13（最小面积）。请将截图差异测试作为补充检查，与手动验证配合使用，而非作为焦点指示器的唯一测试方法。

Testing Workflows by Component Type

按组件类型划分的测试流程

Forms: navigate to form with keyboard only → fill all fields (check Tab order) → trigger validation errors → verify errors appear and are announced → correct and revalidate → submit with Enter/Space → verify success message is announced. With a screen reader, also confirm field labels/instructions/types are announced and errors are in logical reading order.
Modal dialogs: activate trigger → verify focus moves into modal → Tab through all elements → verify Tab doesn't leave modal (focus trap) → Escape or close button dismisses → verify focus returns to trigger. With a screen reader, confirm the modal is announced (
role="dialog"
, 
aria-labelledby
) and content is in logical reading order.
Single Page Applications: click a navigation link → verify content changes → verify focus moves to main heading/content → verify page title changes → verify the route change is announced or focus provides context. Confirm the back button works and new page structure (landmarks, headings) is clear.
表单：仅通过键盘导航到表单 → 填写所有字段（检查Tab顺序）→ 触发验证错误 → 验证错误显示并被播报 → 修正并重新验证 → 按Enter/Space提交 → 验证成功消息被播报。使用屏幕阅读器时，还需确认字段标签/说明/类型被播报，且错误信息处于逻辑阅读顺序。
模态对话框：激活触发元素 → 验证焦点移入对话框 → 按Tab遍历所有元素 → 验证Tab不会离开对话框（焦点陷阱）→ 按Escape或关闭按钮关闭 → 验证焦点返回触发元素。使用屏幕阅读器时，确认对话框被播报（
role="dialog"
、
aria-labelledby
），且内容处于逻辑阅读顺序。
单页应用（SPA）：点击导航链接 → 验证内容变化 → 验证焦点移动到主标题/内容 → 验证页面标题变化 → 验证路由变化被播报或焦点提供上下文。确认返回按钮可正常工作，且新页面结构（地标、标题）清晰。

Documenting Test Results

测试结果记录

For each issue found, record: component/page tested (URL or name), issue description, expected behavior, numbered steps to reproduce, assistive technology name/version, browser name/version, OS name/version, and severity. Optionally include a screenshot/recording and the WCAG success criterion violated.
markdown
undefined
对于发现的每个问题，记录：测试的组件/页面（URL或名称）、问题描述、预期行为、编号的复现步骤、辅助技术名称/版本、浏览器名称/版本、操作系统名称/版本，以及严重程度。可选添加截图/录屏，以及违反的WCAG成功准则。
markdown
undefined

Accessibility Issue: [Brief Description]

可访问性问题：[简要描述]

Component: [URL or component name] Issue: [Description of what doesn't work] Expected: [What should happen] Severity: [Critical/High/Medium/Low]
Steps to Reproduce:
  1. [Step 1]
  2. [Step 2]
Testing Environment:
  • Screen Reader: [Name and version]
  • Browser: [Name and version]
  • OS: [Operating system and version]
WCAG Criterion: [If applicable] Suggested Fix: [If you have one]

(For structured findings, use `skills/bug-reporting/SKILL.md`.)

---
组件：[URL或组件名称] 问题：[描述故障现象] 预期：[应有的行为] 严重程度：[Critical/Serious/Moderate/Minor]
复现步骤：
  1. [步骤1]
  2. [步骤2]
测试环境：
  • 屏幕阅读器：[名称和版本]
  • 浏览器：[名称和版本]
  • 操作系统：[操作系统和版本]
WCAG准则：[如适用] 建议修复方案：[如有]

（如需结构化记录问题，请使用`skills/bug-reporting/SKILL.md`。）

---

Encouraging Participation from People with Disabilities

鼓励残障人士参与测试

People with disabilities are the experts in identifying barriers and validating solutions — their lived experience surfaces issues automated tools and non-disabled testers miss, and validates that fixes actually work.
  • Remove barriers to participation: clear jargon-free instructions, flexible timeframes, asynchronous feedback, compensation for testing time, accessible issue-reporting formats
  • Invite diverse testers: screen reader users, keyboard-only users, voice control users, users with cognitive disabilities, users with multiple disabilities
  • Credit and compensate testers fairly; create opportunities for ongoing involvement
残障人士是识别障碍和验证解决方案的专家——他们的亲身经历能发现自动化工具和非残障测试人员遗漏的问题，并验证修复方案是否真正有效。
  • 消除参与障碍：使用清晰无术语的说明、灵活的时间框架、异步反馈方式、为测试时间提供报酬、提供可访问的问题报告格式
  • 邀请多样化的测试人员：屏幕阅读器用户、纯键盘用户、语音控制用户、认知障碍用户、多重障碍用户
  • 公平地认可和报酬测试人员；创造持续参与的机会

Quick Reference Checklists

快速参考检查清单

30-minute keyboard-only test: Tab start to end; focus visible everywhere; activate all buttons (Enter/Space) and links (Enter); fill and submit a form; open/close a modal; use custom widgets; navigate menus; check for keyboard traps.
30-minute screen reader test: navigate by headings, landmarks, and form fields; read full page content; activate buttons/links; fill and submit a form; test a custom widget; verify images have alt text; verify dynamic content updates are announced.
Visual accessibility quick check: 200% zoom; focus indicator visibility; color contrast (text and UI components); content readable without color alone; light and dark modes; forced colors mode.
30分钟纯键盘测试：从开头到结尾按Tab遍历；所有位置焦点可见；激活所有按钮（Enter/Space）和链接（Enter）；填写并提交表单；打开/关闭模态框；使用自定义组件；导航菜单；检查键盘陷阱。
30分钟屏幕阅读器测试：按标题、地标和表单字段导航；阅读完整页面内容；激活按钮/链接；填写并提交表单；测试自定义组件；验证图片有alt文本；验证动态内容更新被播报。
视觉可访问性快速检查：200%缩放；焦点指示器可见性；颜色对比度（文本和UI组件）；无需依赖颜色即可阅读内容；亮色和暗色模式；forced colors mode。

Definition of Done Checklist

完成标准检查清单

  • Keyboard-only test completed; all interactions reachable and operable
  • No keyboard traps found
  • Focus order is logical
  • Screen reader test completed with at least one platform combination
  • All images, icons, and charts have correct text alternatives
  • Dynamic content changes are announced by screen reader
  • Color contrast verified for text and UI components
  • Forced colors mode tested for all custom UI components
  • Zoom at 200% tested; no content cut off or horizontally scrolling
  • Component workflow tests run for forms, modals, and SPA navigation where applicable
  • Findings documented with URL, element, WCAG SC, severity, and steps to reproduce
  • 完成纯键盘测试；所有交互均可访问和操作
  • 未发现键盘陷阱
  • 焦点顺序符合逻辑
  • 使用至少一种平台组合完成屏幕阅读器测试
  • 所有图片、图标和图表都有正确的文本替代方案
  • 动态内容变化被屏幕阅读器播报
  • 验证文本和UI组件的颜色对比度
  • 测试所有自定义UI组件的forced colors mode
  • 完成200%缩放测试；无内容截断或水平滚动
  • 针对表单、模态框和SPA导航（如适用）运行组件流程测试
  • 记录测试结果，包含URL、元素、WCAG准则、严重程度和复现步骤

Key WCAG Criteria

关键WCAG准则

  • 1.1.1 Non-text Content (A)
  • 1.3.1 Info and Relationships (A)
  • 1.4.1 Use of Color (A)
  • 1.4.3 Contrast Minimum (AA)
  • 1.4.11 Non-text Contrast (AA)
  • 2.1.1 Keyboard (A)
  • 2.1.2 No Keyboard Trap (A)
  • 2.4.3 Focus Order (A)
  • 2.4.7 Focus Visible (AA)
  • 2.4.11 Focus Appearance (AA — WCAG 2.2)
  • 4.1.2 Name, Role, Value (A)
  • 4.1.3 Status Messages (AA)
  • 1.1.1 非文本内容（A级）
  • 1.3.1 信息与关系（A级）
  • 1.4.1 颜色使用（A级）
  • 1.4.3 最低对比度（AA级）
  • 1.4.11 非文本对比度（AA级）
  • 2.1.1 键盘（A级）
  • 2.1.2 无键盘陷阱（A级）
  • 2.4.3 焦点顺序（A级）
  • 2.4.7 焦点可见（AA级）
  • 2.4.11 焦点外观（AA级——WCAG 2.2）
  • 4.1.2 名称、角色、值（A级）
  • 4.1.3 状态消息（AA级）

References

参考资料

Standards horizon: These rules target WCAG 2.2 AA. Monitor: https://www.w3.org/TR/wcag-3.0/
标准前沿：本规则针对WCAG 2.2 AA级。 关注：https://www.w3.org/TR/wcag-3.0/