企业网站无障碍验收：测试项与缺陷证据

本文提供企业网站无障碍验收的实操指南，涵盖测试环境准备、键盘操作与焦点管理、语义结构与ARIA、颜色对比度与视觉呈现四大模块，并附缺陷记录模板，帮助QA工程师系统化执行验收。

验收准备与测试环境

无障碍验收的第一步是建立可重复的测试环境。没有标准化的环境，测试结果难以对比，缺陷也无法复现。本节明确测试范围、工具和基线，确保每次验收都有据可依。

### 确定测试范围与页面清单

首先，定义需要验收的页面清单。并非所有页面都需要同等深度的测试，但清单应覆盖典型用户流程和关键功能。建议至少包含以下类型：

– **首页**：作为入口，需验证整体导航和关键内容可达性。
– **表单页**：如注册、登录、搜索、联系表单，验证标签、提示和错误处理。
– **动态内容页**：如新闻列表、产品展示，验证动态加载、弹窗、轮播等组件。
– **核心业务流程页**：如购物车、结算、预约，确保完整流程可操作。

在测试前，记录每个页面的URL、页面名称和测试优先级。优先级可基于用户流量、业务关键性或已知风险。例如，高流量页面和涉及法律义务的页面（如隐私政策）应优先测试。

### 配置测试工具与辅助技术

无障碍测试需要结合自动化工具和人工测试。自动化工具能快速发现常见问题，但无法替代人工判断。建议配置以下工具：

– **浏览器**：至少使用最新版Chrome和Firefox，因为不同浏览器对ARIA和HTML5的支持有差异。同时，测试应覆盖桌面和移动视口。
– **辅助技术**：屏幕阅读器是核心工具。在Windows上使用NVDA（免费），在macOS上使用VoiceOver（内置）。此外，可选用JAWS（商业）进行补充测试，但NVDA和VoiceOver已覆盖大部分场景。
可调整示例假设：- **自动化工具**：axe（浏览器扩展）和Lighthouse（Chrome DevTools内置）能快速扫描常见问题，如对比度不足、缺失替代文本等。但自动化工具只能检测约30%的WCAG标准，需结合人工测试。

记录测试环境信息至关重要。在测试日志中，记录测试日期、测试人员、浏览器名称和版本、操作系统、辅助技术名称和版本。例如：

### 建立测试基线

测试基线是指已知的可访问性状态，用于对比后续改进。在首次测试前，可先运行自动化工具获取基线扫描结果，记录通过和失败的项目。此后，每次修复后重新扫描，对比结果以验证改进。

基线还应包括手动测试的已知问题列表。例如，如果已知某个弹窗无法用键盘关闭，应记录在案，作为回归测试的参考。

### 测试执行与记录

测试执行应遵循既定流程。建议按页面或组件模块进行，每完成一项测试，记录结果。对于发现的问题，立即填写缺陷记录模板（见文末），确保信息完整。

测试过程中，保持环境一致性。例如，关闭浏览器扩展，避免干扰；使用无痕模式，排除缓存影响。

键盘操作与焦点管理

键盘操作是无障碍的核心，因为许多用户依赖键盘而非鼠标。本节验证所有功能可通过键盘操作，焦点顺序合理且可见。

### 测试Tab键遍历顺序

Tab键应按照视觉顺序遍历页面元素。测试方法：从页面顶部开始，按Tab键依次移动焦点，观察焦点是否按预期顺序移动。

– **预期结果**：焦点顺序与视觉布局一致，通常从左到右、从上到下。
– **常见问题**：焦点跳转到隐藏元素、顺序混乱（如先跳到页脚）、或陷入循环。

例如，在导航菜单中，Tab应依次经过每个菜单项，然后进入主内容区。如果页面有侧边栏，焦点顺序应遵循DOM顺序，但视觉上可能不同，需确保逻辑合理。

### 验证焦点可见性

焦点必须清晰可见，以便用户知道当前位置。测试方法：按Tab键移动焦点，观察是否有明显的焦点环（outline）或其他视觉指示。

– **预期结果**：焦点元素有可见的边框或背景变化，对比度足够。
– **常见问题**：开发者移除outline（如outline: none），导致焦点不可见。

修复方法：使用CSS为焦点元素添加样式，如`outline: 2px solid #4a90e2`。确保焦点样式在浅色和深色背景下都可见。

### 测试快捷键和跳过导航链接

跳过导航链接允许键盘用户直接跳到主内容。测试方法：按Tab键，在页面顶部应出现“跳到主内容”链接，按Enter激活后，焦点应移至主内容区域。

– **预期结果**：链接可见（通常仅在获得焦点时显示），且能正确跳转。
– **常见问题**：链接不可见、跳转目标错误或不存在。

此外，测试自定义快捷键。例如，某些页面可能定义快捷键（如Alt+1跳转到首页），需确保不与浏览器冲突，且提供说明。

### 测试弹窗和下拉菜单的键盘操作

弹窗、下拉菜单等动态组件必须能用键盘打开和关闭。测试方法：

– 使用Tab键将焦点移至触发按钮，按Enter或空格键打开弹窗。
– 弹窗打开后，焦点应移入弹窗内，并限制在弹窗内循环（焦点陷阱）。
– 按Esc键关闭弹窗，焦点应返回触发按钮。

例如，一个下拉菜单，按Enter展开后，使用方向键选择选项，按Esc收起。测试时，记录每一步是否正常。

### 焦点管理缺陷记录

当发现焦点问题时，记录具体步骤。例如：

– 缺陷ID：A11y-001
– 标题：弹窗关闭后焦点未返回触发按钮
– 页面URL：/contact
– 测试步骤：1. 按Tab键聚焦“打开表单”按钮；2. 按Enter打开弹窗；3. 按Esc关闭弹窗。
– 预期结果：焦点返回“打开表单”按钮。
– 实际结果：焦点移至页面顶部。

语义结构与ARIA

语义化HTML是辅助技术理解页面的基础。本节确保页面结构语义化，ARIA属性使用正确。

### 检查标题层级

标题应使用h1-h6标签，且层级合理。测试方法：使用浏览器开发者工具或屏幕阅读器查看标题列表。

– **预期结果**：页面有且仅有一个h1，标题层级不跳级（如h1直接到h3）。
– **常见问题**：使用div或span模拟标题，或层级混乱。

例如，首页的h1应为网站名称或主要标题，h2用于各板块标题，h3用于子标题。如果发现h1缺失，应记录。

### 验证列表、表格和按钮的标签

列表应使用ul/ol/li，表格使用table/tr/th/td，按钮使用button或input[type=button]。测试方法：检查HTML源码。

– **预期结果**：列表项在屏幕阅读器中会播报“列表项”，表格播报“表格”和行列信息。
– **常见问题**：使用div模拟列表，或表格缺少表头。

例如，导航菜单应使用ul/li，而不是div加样式。表格的表头应使用th，并关联scope属性。

### 检查ARIA属性的使用

ARIA（Accessible Rich Internet Applications）用于增强无障碍，但错误使用反而有害。测试方法：检查ARIA属性是否必要且正确。

– **aria-label**：用于为无文本标签的元素提供名称，如图标按钮。测试时，确保aria-label内容清晰。
– **aria-expanded**：用于指示展开状态，如手风琴。测试时，点击后属性值应变化。
– **aria-hidden**：用于隐藏装饰性内容，但不应隐藏可聚焦元素。

例如，一个搜索按钮，如果只有图标，应添加aria-label="搜索"。如果按钮有文本，则无需aria-label。

### 确保iframe有title属性

iframe（如嵌入视频）必须有title属性，描述其内容。测试方法：检查iframe标签。

– **预期结果**：每个iframe都有title，如“产品介绍视频”。
– **常见问题**：iframe无title，屏幕阅读器会播报“iframe”或空白。

### 语义缺陷记录

记录语义问题时，注明具体元素和位置。例如：

– 缺陷ID：A11y-010
– 标题：页面缺少h1标题
– 页面URL：/about
– 测试步骤：使用屏幕阅读器查看标题列表。
– 预期结果：存在一个h1。
– 实际结果：无h1，最高为h2。

颜色对比度与视觉呈现

颜色对比度影响低视力用户的可读性。本节确保文本和UI组件满足对比度要求，且不依赖颜色传达信息。

### 测试文本对比度

使用工具（如WebAIM Contrast Checker）测试文本颜色与背景色的对比度。WCAG要求：

– 正文文本（小于18pt或14pt粗体）对比度至少4.5:1。
– 大文本（大于等于18pt或14pt粗体）对比度至少3:1。

测试方法：从页面提取文本颜色和背景色，输入工具计算。自动化工具（如axe）可自动检测，但需人工确认。

例如，灰色文本（#999）在白色背景上对比度约为2.8:1，不通过。应改为更深的颜色，如#595959。

### 测试UI组件对比度

UI组件（如输入框边框、图标）的视觉信息对比度至少3:1。测试方法：检查输入框边框、按钮背景、图标颜色等。

– **预期结果**：组件边界清晰可辨。
– **常见问题**：浅色边框在白色背景上不可见。

例如，输入框边框颜色为#e0e0e0，在白色背景上对比度不足，应加深。

### 验证不依赖颜色传达信息

错误提示、状态指示等不应仅用颜色区分。测试方法：检查是否有图标、文本或样式变化。

– **预期结果**：错误提示有图标（如感叹号）和文本描述，链接有下划线。
– **常见问题**：仅用红色文字表示错误，或链接仅靠颜色区分。

例如，表单验证失败时，输入框边框变红，同时显示错误消息“请输入有效邮箱”。

### 对比度缺陷记录

记录对比度问题时，注明具体元素和颜色值。例如：

– 缺陷ID：A11y-020
– 标题：正文文本对比度不足
– 页面URL：/blog
– 测试步骤：使用WebAIM Contrast Checker测试。
– 预期结果：对比度至少4.5:1。
– 实际结果：对比度2.8:1（#999 on #fff）。

表单与输入辅助

缺陷记录是验收的核心输出。以下模板包含必要字段，确保缺陷可复现、可跟踪。

使用模板时，确保每个缺陷都填写完整。截图能直观展示问题，环境信息有助于开发人员复现。复测状态用于跟踪修复进度。

例如，一个完整的缺陷记录：

– 缺陷ID：A11y-001
– 标题：弹窗关闭后焦点未返回触发按钮
– 页面URL：/contact
– 测试步骤：1. 按Tab键聚焦“打开表单”按钮；2. 按Enter打开弹窗；3. 按Esc关闭弹窗。
– 预期结果：焦点返回“打开表单”按钮。
– 实际结果：焦点移至页面顶部。
– 严重级别：高
– 截图：/screenshots/A11y-001.png
– 环境信息：Chrome 120, NVDA [填写记录日期], Windows 11
– 复测状态：待复测

通过系统化记录，团队能高效修复问题，并验证修复效果。

替代文本与多媒体

表单是用户与网站交互的核心，无障碍验收需确保所有用户，包括使用屏幕阅读器或键盘的用户，都能理解并操作表单。本节提供具体的测试步骤和通过标准。

### 标签关联测试

**测试步骤**：
1. 使用键盘Tab键遍历页面所有输入框、下拉框和文本区域。
2. 对每个控件，检查是否有一个`<label>`元素通过`for`属性或包裹方式与其关联。
3. 在浏览器开发者工具中检查DOM，确认`<label>`的`for`属性值与控件`id`一致。
4. 使用屏幕阅读器（如NVDA、VoiceOver）聚焦到控件，听取是否读出标签文本。

**通过标准**：
– 每个输入控件都有可见的文本标签，且标签与控件正确关联。
– 屏幕阅读器读出标签时，用户能明确知道该输入框的用途。

**常见失败**：
– 使用`placeholder`作为唯一提示，但未提供标签。
– 标签与控件未关联，导致屏幕阅读器无法读出。

### 错误提示关联测试

**测试步骤**：
1. 故意提交一个空表单或输入无效数据（如错误的邮箱格式）。
2. 观察错误提示是否出现，并检查提示文本是否通过`aria-describedby`或`aria-labelledby`与对应输入框关联。
3. 使用屏幕阅读器聚焦到出错字段，听取是否读出错误信息。
4. 检查错误提示是否以文本形式显示在页面中，而非仅依赖颜色或图标。

**通过标准**：
– 错误提示与输入框关联，屏幕阅读器能自动读出。
– 错误提示提供具体修正建议，例如“请输入有效的邮箱地址”。

**常见失败**：
– 错误提示仅通过红色边框或图标表示，无文本。
– 错误提示未关联，屏幕阅读器无法感知。

### 必填字段标识测试

**测试步骤**：
1. 检查所有必填字段是否有可见标识，如星号（*）或“必填”字样。
2. 验证标识是否在标签中或通过`aria-required="true"`属性告知辅助技术。
3. 使用屏幕阅读器聚焦到必填字段，听取是否提示“必填”。

**通过标准**：
– 必填字段有可见标识，且辅助技术能感知。
– 标识不依赖颜色（如仅红色星号），需有文本或符号。

**常见失败**：
– 必填字段无任何标识。
– 使用`required`属性但未在标签中体现，屏幕阅读器可能不读出。

### 错误汇总测试

**测试步骤**：
1. 提交包含多个错误的表单。
2. 检查页面顶部或表单上方是否出现错误汇总列表，列出所有错误字段和原因。
3. 验证错误汇总是否通过`aria-live`区域或自动聚焦到汇总区域，以便屏幕阅读器立即读出。
4. 点击错误汇总中的链接，焦点是否跳转到对应字段。

**通过标准**：
– 错误汇总以文本形式呈现，且能被辅助技术感知。
– 用户能通过汇总快速定位到错误字段。

**常见失败**：
– 错误仅显示在字段下方，无汇总。
– 汇总区域无`aria-live`，屏幕阅读器不自动读出。

动态内容与状态变化

非文本内容如图片、视频和音频，必须提供替代文本，以确保信息不丢失。本节测试覆盖静态和动态媒体。

### 信息性图片的替代文本

**测试步骤**：
1. 遍历页面所有`<img>`元素，识别哪些图片传达信息（如产品图、图表、图标）。
2. 检查这些图片是否具有`alt`属性，且内容准确描述图片目的。
3. 使用屏幕阅读器浏览页面，听取`alt`文本是否合理。
4. 对于复杂图片（如数据图表），检查是否提供详细文字说明（如表格或长描述）。

**通过标准**：
– 信息性图片有非空的`alt`文本，且能替代图片信息。
– 复杂图片有额外文字说明。

**常见失败**：
– `alt`文本为空或仅写“图片”。
– `alt`文本冗长重复，或包含无关信息。

### 装饰性图片的空替代文本

**测试步骤**：
1. 识别用于装饰的图片（如背景纹理、纯装饰性边框）。
2. 检查这些图片是否使用`alt=""`或`role="presentation"`，以从辅助技术中隐藏。
3. 使用屏幕阅读器，确认装饰性图片不被读出。

**通过标准**：
– 装饰性图片的`alt`为空字符串，或使用`role="presentation"`。
– 屏幕阅读器跳过这些图片。

**常见失败**：
– 装饰性图片有`alt`文本，导致冗余朗读。
– 使用`title`属性但未设置`alt`，可能被读出。

### 视频字幕与转录

**测试步骤**：
1. 检查页面所有视频是否提供字幕（如WebVTT）或文字转录。
2. 播放视频，验证字幕是否同步显示。
3. 检查转录文本是否在视频附近或通过链接提供。
4. 测试视频控件是否可通过键盘操作，并支持暂停。

**通过标准**：
– 视频有字幕或转录，且内容完整。
– 字幕同步准确，转录可访问。

**常见失败**：
– 视频无字幕，也无转录。
– 字幕不同步或错误。

### 音频内容的文字替代

**测试步骤**：
1. 检查页面所有音频（如播客、语音消息）是否提供文字转录。
2. 验证转录是否准确，并易于访问。
3. 测试音频播放控件是否可通过键盘操作。

**通过标准**：
– 音频内容有文字转录，且转录内容完整。
– 转录链接清晰可见。

**常见失败**：
– 音频无转录，或转录需登录才能访问。

缺陷记录与复测

动态内容（如AJAX加载、弹窗、轮播）必须确保辅助技术用户能感知变化并控制交互。本节测试动态组件的可访问性。

### AJAX加载内容的通知

**测试步骤**：
1. 触发一个AJAX操作（如点击“加载更多”按钮）。
2. 观察新内容是否插入到页面中。
3. 检查新内容区域是否具有`aria-live`属性（如`aria-live="polite"`或`assertive`），且设置正确。
4. 使用屏幕阅读器，确认新内容被自动读出。

**通过标准**：
– 动态插入的内容位于`aria-live`区域内，屏幕阅读器能自动播报。
– 播报内容简洁，不打断用户操作。

**常见失败**：
– 新内容无`aria-live`，屏幕阅读器不感知。
– `aria-live`区域设置不当，导致播报混乱。

### 弹窗焦点管理

**测试步骤**：
1. 打开一个弹窗（如模态框）。
2. 检查焦点是否自动移入弹窗内，并停留在第一个可聚焦元素上。
3. 使用Tab键，确认焦点在弹窗内循环，不会移出到背景内容。
4. 关闭弹窗后，焦点是否返回触发弹窗的控件。
5. 检查弹窗是否具有`role="dialog"`和`aria-modal="true"`，且标题正确关联。

**通过标准**：
– 弹窗打开时焦点移入，关闭时返回触发元素。
– 焦点被困在弹窗内，背景内容不可聚焦。
– 屏幕阅读器能识别弹窗及其标题。

**常见失败**：
– 弹窗打开后焦点仍在背景。
– 关闭弹窗后焦点丢失，或未返回触发元素。

### 轮播图的可暂停与替代导航

**测试步骤**：
1. 检查轮播图是否自动播放。
2. 验证是否有暂停/停止按钮，且可通过键盘操作。
3. 检查轮播图是否提供替代导航方式（如上一张/下一张按钮、幻灯片列表）。
4. 测试键盘用户能否独立操作轮播图。

**通过标准**：
– 自动播放的轮播图有暂停按钮，且键盘可操作。
– 提供多种导航方式，不依赖鼠标滑动。

**常见失败**：
– 轮播图自动播放且无法暂停。
– 导航仅支持鼠标悬停或滑动。

### 状态变化的提示

**测试步骤**：
1. 触发一个状态变化（如加载中、操作成功、内容更新）。
2. 检查状态变化是否通过文本或`aria-live`区域提示。
3. 使用屏幕阅读器，确认提示被读出。

**通过标准**：
– 状态变化有明确提示，如“加载中…”或“保存成功”。
– 提示通过`aria-live`区域自动播报。

**常见失败**：
– 状态变化仅通过图标或颜色表示，无文本。
– 提示区域无`aria-live`，屏幕阅读器不感知。

缺陷记录是验收的核心，标准化记录有助于跟踪和修复。本节提供缺陷记录模板和复测流程。

### 缺陷记录字段定义

每个缺陷应记录以下字段，确保信息完整。

### 缺陷示例

以下是一个完整缺陷记录示例，用于说明填写方式。

– **缺陷ID**：DEF-001
– **标题**：弹窗打开时焦点未移入
– **页面URL**：[填写来源URL]
– **测试步骤**：
1. 使用键盘Tab键导航到“联系我们”按钮。
2. 按Enter键打开弹窗。
3. 观察焦点位置。
– **预期结果**：弹窗打开后，焦点应自动移入弹窗内的第一个可聚焦元素（如关闭按钮）。
– **实际结果**：焦点仍停留在背景页面的“联系我们”按钮上，键盘用户无法操作弹窗。
– **严重级别**：严重
– **截图**：screenshot_def001.png
– **环境信息**：Chrome 120, Windows 11, NVDA [填写记录日期]
– **复测状态**：待复测

### 复测流程

1. **提交缺陷**：将缺陷记录提交给开发团队，并附上完整信息。
2. **修复验证**：开发修复后，测试人员根据“测试步骤”重新执行测试。
3. **更新状态**：如果实际结果符合预期，将“复测状态”更新为“通过”；否则更新为“未通过”，并注明原因。
4. **回归测试**：确保修复未引入新问题，特别是相关功能。
5. **关闭缺陷**：复测通过后，关闭缺陷记录。

### 缺陷记录工具建议

可使用电子表格或项目管理工具（如Jira）来管理缺陷。确保每个缺陷都有唯一ID，并定期审查未关闭的缺陷。

通过系统化记录和复测，可以确保无障碍问题得到有效解决，提升网站的整体可访问性。

下一步

立即下载缺陷记录模板，开始您的无障碍验收测试。