我们构建了一个 accessibility tool，因为 spreadsheet audits 折磨我们

Source: Dev.to

抱歉，您只提供了来源链接，没有提供需要翻译的正文内容。请粘贴您希望翻译的文本，我将为您翻译成简体中文。

The Problem

有一种特定的绝望感，来自打开 WCAG 审计中的第九个电子表格——你几乎可以肯定它是两周前从错误的版本复制过来的——却发现登录流程的第 14 步在你的副本中标记为 “Fail”，而在审阅者的副本中标记为 “Not Tested”。

哪一个才是正确的？没人知道。最初记录它的测试员正在休假。截图散落在 Slack 的某个地方，可能埋在一次部署争论的线程里。

那是我们大约两年前在美国进行一次医疗保健可访问性审计时的情形。客户要求严格，法规要求严格，一切都很严格——除了我们的工具，它们是用 Google 表格、手动日期和希望拼凑在一起的。

我们打开了九个电子表格：

• 一个用于跟踪测试人员。
• 一个用于跟踪严重程度。
• 一个用于跟踪备注。
• 一个显然是另一个表格的备份，但数据不同。

截图保存在 Slack 频道中，有时在私信里，有时作为 Jira 工单的附件，而这些工单又引用了不同版本的 WCAG 标准。

随后我们发现了冲突的报告。相同的用户流程、相同的步骤、两个不同的测试员、两个不同的结果。一个标记为 Fail 并附有缺少 alt 文本的备注，另一个标记为 Not Tested。这两份报告在同一周内都提交给了客户。

那一刻，我们停止了对流程的临时修补，开始着手构建真正的解决方案。

该工具名为 Auditi

它位于 . 我们在 构建它，因为没有其他工具能够匹配我们实际测试可访问性的方式：通过 用户旅程，拆分为 步骤，并且所有内容都可以追溯到特定的测试人员、日期、平台和 WCAG 标准。

核心理念

1. 以用户体验的方式建模旅程——登录流程、结账流程、入职流程等。
2. 每个旅程都有 步骤。
3. 每个步骤都会得到审计结果：通过、未通过 或 不适用。
4. 每个结果都会记录：测试人员姓名、严重程度、备注、证据文件以及时间戳。

这听起来很显而易见，却并非如此。在电子表格的世界里，你需要在列、标签页和文件之间追踪所有这些信息。有人改了列名。有人在中间插入了行。有人按严重程度过滤后忘记取消过滤就发送报告。我曾看到一位经验丰富的 QA 工程师花四十分钟重建一个因 Excel 重新解释日期而崩溃的透视表。

Auditi 为你提供按旅程、测试人员、状态、严重程度、平台、WCAG 级别、设备和日期的过滤功能。如果你曾在电子表格中尝试寻找“上周二 iOS Safari 那个未通过项”，你就会明白这有多重要。

我们实际构建的内容

• 任务对话框和审查队列，让工作在没有 Slack 信息链的情况下分配。
• 每个步骤的通过/未通过/不适用切换——可访问性审计的原子单元。
• 通知用于截止日期和邀请，因为依赖人员每天检查电子表格并不可行。

分析

• 随时间变化的通过率。
• WCAG 合规矩阵。
• 按测试人员、平台、严重程度的细分。

这是管理者真正关心的部分，也是几乎不可能在没有专人更新图表的情况下通过电子表格维护的部分。

报告

• 导出为 Excel、PDF 和 CSV（大多数客户期望的格式）。
• 生成 概览、详细 和 矩阵 报告。
• AI 驱动的智能报告，可生成执行摘要、按 WCAG 等级的得分、按优先级标记的主要问题，并提供修复建议。
  • 诚实说明：AI 摘要之所以有用，是因为它压缩结构化数据，而不是因为它做出判断。测试人员仍然决定哪些通过、哪些未通过；AI 只负责撰写你本来需要花一个小时起草的摘要。

Source: …

如果你尝试让 React 应用符合 WCAG 标准

问题的另一半：修复细节

我们在 BetterQA 生态系统中运行了十三个产品：Vite/React 单页应用、Next.js 应用、一个 Laravel 应用和一个 WordPress 站点。今年早些时候，我们决定使用自研的扫描工具对所有项目进行可访问性检查，该工具通过 Playwright 调用 axe‑core。

结果让人谦卑

• 我们十三个站点中有八个 的可访问性得分低于 60。
• 最大的违规点是什么？颜色对比度——具体来说，是 Tailwind 的 purple‑400 在白色背景上的使用。

每个 Vite/React 单页应用都使用 text-purple-400 来显示链接、徽章、标签、次要文字。这个颜色看起来不错，但相对于白色的对比度只有大约 3.3:1。WCAG AA 对普通文字要求 4.5:1。我们在每个页面上都有数十个对比度检查不合格，涉及八个不同站点，却没有人注意到，因为在我们眼里页面看起来还行。

解决办法： 将颜色改为 purple-600（#9333ea），其对比度为 4.6:1——刚好超过阈值，符合标准。

/* Before: 3.3:1 contrast – fails WCAG AA */
.text-purple-400 { color: #a855f7; }

/* After: 4.6:1 contrast – passes WCAG AA */
.text-purple-600 { color: #9333ea; }

我们在所有八个站点中完成了此更改。有的站点需要更新 24 条独立的类。一个站点 BetterFlow（Laravel/Blade 应用）在 Blade 模板中也出现了同样的模式。

这让我们的可访问性得分从 50 多分提升到了 70‑80 分，但这仅仅是解决了最显而易见的问题。

Source: …

更深入的修复让我们学到了更多

在完成颜色对比的全面检查后，我们进一步深入。

• 仅图标按钮（例如在 jrny.ro 上）没有可访问名称。屏幕阅读器只会朗读为“button”。

  • 修复方式： 添加 aria-label 属性。

• 没有标签的表单输入（例如在 menute.ro 上）。有视力的用户依赖占位符文本；屏幕阅读器却听不到任何有用信息。

  • 修复方式： 为每个输入添加 aria-label（或关联一个 <label> 元素）。

这些更深层次的问题提醒我们，可访问性不仅仅是检查清单——它关乎有意图、可追溯且协作的工作，这正是 Auditi 所实现的。

most was nis2manager.ro

该站点使用 CSS 自定义属性来定义其主色。原始的 --primary 值的 oklch 亮度为 0.65。将其改为 0.48 后，在一行 CSS 中修复了 超过七十 条对比度违规。七十条。只需更改一个变量。

/* One variable, seventy fixes */
--primary: oklch(0.48 0.2 270);  /* was 0.65 */

进入全屏模式
退出全屏模式

这就是我们反复强调的教训：如果你的设计系统使用 CSS 自定义属性或 Tailwind 主题颜色，首先检查基础 token 的对比度。你可以花数小时逐个查找违规元素，或者直接修复源头，让大量违规瞬间消失。

Source: …

自动化工具实际能捕获的内容

我想直截了当地说明这一点，因为我看到太多文章声称自动化可访问性测试可以解决问题。事实是并不能——甚至远远不够。

• 像 axe‑core 这样的自动化工具大约只能捕获 30‑40 % 的 WCAG 问题。
  • 擅长的方面：颜色对比、缺失的 alt 文本、缺失的表单标签、重复的 ID、损坏的 ARIA 属性。
  • 不擅长的方面：任何需要上下文的内容——alt 文本是否有意义、焦点顺序是否合理、定制组件是否可以通过键盘操作、内容在屏幕阅读器线性阅读时是否易于理解。

WCAG 大约有 80 条成功准则，分布在 A、AA、AAA 级别。自动化工具能够可靠检查的只有大约 25‑30 条。其余的需要人类审查者来理解用户流程、内容意图以及在没有鼠标的情况下的使用体验。

这也是 Auditi 以 human‑driven audits 为核心，围绕用户旅程和步骤构建，而不是仅仅依赖自动化扫描结果的原因。自动化对于捕获回归问题很有用，但它不能替代真正使用屏幕阅读器进行网站导航的测试人员。

我们哪里做错了

有几件事，说实话：

1. 复杂性 – Auditi 的第一个版本把每个 WCAG 标准都建模为单独的审计点，迫使测试人员在每一步点击数十个标准，其中大多数并不适用。我们进行了简化，让测试人员只标记重要的内容，跳过其余的。
2. 导出格式 – 早期的导出文件虽然整洁，但不符合合规官的预期。我们添加了特定的报告布局，映射到我们的医疗保健和政府客户已经使用的文档格式。
3. 自审失败 – 我们对自身生态系统的检查发现，在构建无障碍工具的同时，我们仍在发布不可访问的产品。这让我们很受打击。我们已经修复，但这提醒我们，构建工具与持续一致地使用它是两码事。

诚实的数字

我们的生态系统在清理前后的得分：

不是完美的分数——远未达到。但在八个站点上实现了 25‑30 分的跃升，且这是一个可以重复的过程。

在你的技术栈中何时重要

如果你在运行 React 或 Vite SPA 且尚未对其运行 axe‑core，请先进行此操作。 你可能会发现对比度问题、缺失标签以及按钮名称违规——这些在一个下午内即可修复。

之后，更困难的工作开始：

• 键盘导航
• 模态框和动态内容中的焦点管理
• 对状态变化的屏幕阅读器公告

这就是电子表格失效的地方，你需要实际的审计跟踪。

我们构建了 Auditi，因为我们无法用手头的工具做好这项工作。它可在 auditi.ro 查看。

想了解我们在不同领域进行 QA 的方式，请查看 BetterQA 博客。