无障碍审查¶

简介¶

在 Mozilla，无障碍是我们使命中不可或缺的一部分，旨在确保互联网“对所有人开放和无障碍”，帮助赋予人们权力，无论其能力如何，都能为公益做出贡献。无障碍审查是由 Mozilla 无障碍团队提供的服务，旨在审查功能和更改，以确保它们对残疾人士具有无障碍性和包容性。

我是否需要无障碍审查？¶

如果您不确定您的更改是否对残疾人士无障碍，则应考虑请求无障碍审查。无障碍审查是可选的，但如果您引入了新的用户界面或正在对现有用户界面进行重大重新设计，则强烈建议进行审查。应在设计方面和工程方面都请求审查。

何时应该请求无障碍审查？¶

通常，最好尽早请求无障碍审查，甚至在产品需求或 UI 设计阶段。特别是对于更复杂的用户界面，当将无障碍性融入设计中时，它更容易实现，而不是在实施进行到后期时才试图进行事后补救。

无障碍团队已开发了Mozilla 无障碍发布指南，其中概述了使用户界面无障碍所需的内容。为了加快无障碍审查速度，您可能希望在请求无障碍审查之前尝试验证和实施这些指南。

对于设计审查，请在审查请求和预期工程移交之间至少留出 1 周时间。工程审查请求的截止日期是发布中预期发布功能/更改的第一个星期的星期五。这与 PI 请求截止日期相同。

请求设计审查¶

设计审查应使用 #accessibility Slack 频道中的无障碍审查请求工作流进行请求。要访问此工作流，请单击 #accessibility Slack 频道标题或链接侧边栏中的工作流链接。您也可以在任何频道或 DM 中键入/accessibility design review request。然后，填写所需的信息。

请在请求审查之前完成以下自我审查任务。注意：以下某些链接需要 SSO 身份验证。

执行对比度审计：使用审计对比度的 Figma 插件，检查您的设计是否满足颜色对比度要求。您的设计至少应达到“AA”等级才能通过无障碍审查。“AAA”等级更好！如果某些组件难以调整以满足“AA”标准，请在 Figma 文件中记下，无障碍团队将在审查期间提供具体指导。
添加焦点顺序和角色注释：焦点顺序注释描述了键盘用户在浏览您的设计时应预期的行为。通常，这遵循阅读顺序。请注意，我们只关心可聚焦元素（即链接、按钮、输入等）。角色注释帮助屏幕阅读器和其他辅助技术识别他们正在浏览的组件的“类型”。这些映射向用户公开语义信息。您可以在这里找到常见角色列表。您可能希望为此过程使用注释焦点和角色的 Figma 插件。您不需要注释设计中的每个视图，选择具有最多新内容的视图。
创建 Windows 高对比度模式 (HCM) 模型：我们的设计应该对运行 HCM的用户具有无障碍性。您可以阅读更多关于HCM 如何影响颜色选择以及如何为 HCM 设计的信息。使用“夜空”HCM 调色板，将您的设计转换为高对比度。请记住，我们必须从语义上使用这些颜色，而不是基于对特定美学的追求。颜色根据其用途进行标记——Background 用于页面背景，Button Text 用于按钮或控件文本，Selected Item Background 用于选中或活动项目的背景等。您不需要模拟设计中的每个视图，选择具有最多新内容的视图。您可以在此处找到以前 HCM 模型的示例。在可能的情况下，我们应该依赖 SVG 和 PNG 用于图像内容以提高适应性。

请求工程审查¶

对于以工程为中心的审查，您通过在 Bugzilla 中的 bug 上将 a11y-review 标志设置为“requested”并填写出现在评论字段中的模板来提交审查请求。对于跨越多个 bug 的功能，您可能希望为无障碍审查创建一个新的专用 bug。否则，特别是对于较小的更改，您可以在现有 bug 上执行此操作。请注意，如果您提交了一个新的 bug，您将需要提交该 bug，然后对其进行编辑以设置标志。

在审查过程中，无障碍团队将修改 a11y-review 标志

已分配：审查已由团队进行分类，并且已为审查分配了一名工程师。如果在专门为审查目的而提交的 bug 上设置了标志（即，该 bug 没有附加其他工程工作，并且该 bug 不是元 bug），则审查分配者将为自己分配该 bug。否则，他们将在 bug 上发表评论，以便您知道他们是谁 :)
已通过：要么不需要更改，要么需要一些更改，但无障碍团队认为在发布之前没有必要审查或验证这些更改。通常，如果存在未解决的 s2 或某些严重影响的 s3 无障碍缺陷，这些缺陷可能会阻止功能或更改发布，则不会通过审查。但是，尽管严重程度很高，但某些 s2 缺陷很容易修复（例如，缺少无障碍标签），因此无障碍团队可以选择在条件下通过审查，即这些缺陷应立即得到修复。
需要更改：需要更改，并且无障碍团队需要在确定功能或更改的无障碍性是否可接受以进行发布之前审查或验证这些更改。请求工程团队有责任在进行更改以解决无障碍团队的初始反馈后重新请求无障碍审查。

Phabricator 审查小组¶

Phabricator 上还有一个accessibility-frontend-reviewers 小组。这通常仅在以下情况下使用

补丁是根据上述描述的无障碍审查请求的更改；或
补丁中实现了无障碍性的某个非常具体的方面，并且您希望无障碍团队确认它是否已正确实现。

如果您希望无障碍团队评估功能或更改是否具有足够的无障碍性，请按照上述说明请求无障碍工程审查。如果没有此操作，无障碍团队将没有足够的上下文或对更改或如何测试更改的了解，这对于彻底评估其无障碍性是必要的。

问题？¶

如果您有任何疑问，请随时联系无障碍团队

#accessibility 在Matrix 或Slack 上
电子邮件：[email protected]
请避免直接联系团队成员——在这些渠道中包含审查请求和问题有助于我们平衡工作量。谢谢！