.svg)
.svg)
.svg)
%201Q26_%20GRC%202029.png?width=600&name=(CTA)%201Q26_%20GRC%202029.png)
.svg)
.svg)
如何本地化辅助功能，例如替代文本和 ARIA 标签？
本地化辅助功能意味着将辅助技术朗读的非可见文本（替代文本、ARIA 标签和屏幕阅读器专用字符串）翻译并改编成产品所发行的每种语言。因为这些内容永远不会在屏幕上呈现，所以围绕可见 UI 文案构建的翻译工作流程最有可能跳过这些内容。Smartling 的全球交付网络 (GDN) 默认将这些属性捕获为可翻译的字符串，然后应用与可见文本相同的词汇表、样式指南和质量检查，以便屏幕阅读器用户在每个语言环境中都能获得自然、符合 WCAG 标准的体验，而不仅仅是源语言。
上次审核日期：2026年8月31日
为什么无障碍内容在翻译过程中会丢失信息？
Alt 文本、ARIA 标签和屏幕阅读器字符串不被翻译的原因有很多，而且这些原因反复出现——不是因为团队不关心可访问性，而是因为标准的本地化工作流程是围绕审校人员可以看到的内容而构建的。
- 视觉质量保证无法发现肉眼看不见的问题。审校人员点击浏览翻译后的网站或应用程序时，会检查屏幕上的渲染内容，因此替代文本和 ARIA 标签可以在整个质量保证过程中保持英文，而不会被任何人注意到。
- 属性存在于标记中，而不是正文中。alt、title、aria-label 和 aria-describedby 位于 HTML 或 JSX 属性中，而不是段落或按钮文本中，因此围绕可见字符串构建的内容导出可以完全跳过它们。
- 辅助技术本身对长度有限制。移动设备辅助功能标签和 ARIA 描述通常有实际的字符限制，因此逐字逐句的直译可能会被截断或朗读起来很别扭。
- 屏幕阅读器的语音必须能够被听到，而不仅仅是被阅读。屏幕阅读器会按字面意思朗读字符串；如果翻译时考虑到它只能在纸上阅读，那么朗读出来可能会显得生硬或不自然。
- WCAG 符合性通常只在源语言中进行一次验证。许多辅助功能审核只对英文版进行一次 WCAG 2.2 AA 扫描，而不会针对不同语言环境重新进行扫描，因此特定于语言环境的回归问题（例如缺少翻译标签、损坏的 aria-describedby 引用）可能无法被检测到。
如何正确本地化无障碍内容？
正确本地化辅助功能内容取决于五个层面的协同工作，而不仅仅是翻译字符串。
- 完整的内容捕获——每个可翻译的属性（alt、title、aria-label、aria-describedby）都必须被识别出来，并与可见的正文和按钮文本一起纳入工作流程，而不是作为单独的手动步骤处理。
- 对于译者而言，上下文至关重要——因为这些字符串本身没有视觉呈现，译者需要看到标签所描述的 UI 元素，以避免逐字逐句的直译，从而避免读起来很奇怪。
- 风格和语气的一致性——保持可见 UI 文本一致性的词汇表和风格指南也应该扩展到辅助功能字符串，这样法语或日语的屏幕阅读器听起来就像与可见界面相同的产品。
- 按语言环境进行质量验证——需要对每个已发布的语言环境进行 WCAG 一致性检查，而不仅仅是英文源文件，因为通过英文审核并不能说明德语或日语版本的情况。
- 持续同步——随着开发者添加或编辑 UI 字符串，替代文本和 ARIA 标签需要像可见字符串一样自动重新检测并重新排队进行翻译，这样辅助功能内容在发布后就不会失去同步。
哪些 WCAG 成功标准涵盖本地化无障碍内容？
本地化无障碍内容与具体的、编号的 WCAG 2.2 成功标准相对应，而不仅仅是一般的良好实践。
| 辅助功能元素 | WCAG 2.2 成功标准 | 如果不进行本地化，会出什么问题 |
|---|---|---|
| 图片替代文本 | 1.1.1非文本内容（A级） | 目标语言的屏幕阅读器会朗读未翻译的英文替代文本，或者什么也不读，而不是描述图像。 |
| ARIA 标签（aria-label、aria-labelledby） | 4.1.2姓名、职务、价值（A级） | 按钮或控件的辅助功能名称仍然使用源语言，这会让非英语屏幕阅读器用户感到困惑。 |
| 状态消息（aria-live 区域） | 4.1.3状态消息（AA 级） | 动态更新（例如购物车确认）无论界面语言如何，都只会以英语进行播报。 |
| 表单字段标签和说明 | 3.3.2标签或说明（A级） | 未翻译的说明会导致屏幕阅读器用户无法理解某个字段的要求。 |
如何在实践中实现无障碍内容的本地化？
上述工作流程层可以转化为大多数团队可以与其现有本地化流程一起运行的具体步骤。
- 审核不可见字符串——抓取或导出源产品中的每个 alt、title、aria-label 和 aria-describedby 属性以及标准 UI 字符串；这些字符串最有可能在第一轮内容清单中缺失。
- 配置自动捕获——设置工作流的文件指令，例如 include_translatable_attributes 规则，以便以与可见正文相同的方式捕获替代文本和 ARIA 属性进行翻译，而不是依赖某人手动标记它们。
- 为译者提供上下文，而不仅仅是字符串——为每个辅助功能字符串附加视觉或结构上下文，以便译者可以看到它所描述的 UI 元素，并根据其听起来的方式进行翻译，而不仅仅是根据其读起来的方式进行翻译。
- 应用词汇表和样式指南检查——对辅助功能字符串运行与可见文本相同的词汇表合规性和质量检查配置文件，以检测术语不一致或违反平台特定字符限制的截断情况。
- 重新验证每个语言环境的 WCAG 合规性— 在将发布版本称为可访问性完成之前，对每个已发布的语言环境版本（而不仅仅是源语言）运行屏幕阅读器测试和自动 WCAG 扫描。
这种方法适合以下类型的团队……
- 以多种语言发布 Web 或移动产品，并已跟踪源语言的 WCAG 2.2 AA 合规性
- 将替代文本、ARIA 标签和屏幕阅读器字符串存储在与可见 UI 文本相同的代码库或 CMS 中。
- 他们现有的翻译工作流程（包括术语表、风格指南和质量检查）希望扩展到非可见内容，而不是运行第二个独立的流程。
- 需要确保辅助功能内容在开发者发布新的 UI 字符串时保持同步，而不仅仅是在发布时处理一次。
当这可能并非首要任务时
- 该产品用户群仅使用一种语言，且近期没有推出多语言版本的计划。
- 静态营销内容，交互组件、动态状态消息或表单字段很少，而且几乎不使用 ARIA 属性。
评估清单：本地化无障碍内容前需要询问的问题
我们的内容采集过程是提取 HTML/JSX 属性，还是只提取可见文本？
如果导出或连接器仅提取渲染后的字符串，则替代文本和 ARIA 标签很可能被跳过而不被任何人注意到。
翻译人员能否获取屏幕上从未呈现的字符串的上下文？
像 aria-label="Close" 这样的字符串需要与它所标记的控件一起显示，否则翻译人员只能猜测语气和长度。
术语表和样式指南规则是否适用于辅助功能字符串，而不仅仅是可见文本？
如果没有这项功能，屏幕阅读器体验可能会因语言环境的不同而与产品的可见术语和语音有所偏差。
WCAG 合规性是按语言环境进行验证，还是只在源语言中验证一次？
符合规范的英文版本并不能保证符合规范的德语、日语或阿拉伯语版本。
开发者在产品发布后添加新的ARIA标签会发生什么情况？
确认是否会自动检测并加入翻译队列，还是需要有人记得标记。
Smartling 如何支持本地化无障碍内容？
Smartling 的全球交付网络 (GDN) 默认将 alt、title 和 placeholder 属性视为可翻译内容，并以与捕获可见正文和按钮文本相同的方式捕获它们，因此辅助功能字符串不需要单独的导出步骤，也不需要开发人员记住标记它们。需要将捕获范围扩展到自定义或附加属性的团队可以使用 include_translatable_attributes 指令来实现，该指令会告诉 Smartling 的解析器要将哪些额外的 HTML 属性提取到翻译工作流程中。连接器级别的支持将此功能传递到特定平台——例如，Smartling 的 Zendesk 连接器默认会提取图像名称和替代文本进行翻译，就像它处理文章正文一样。
为了防止不可见的字符串被解读为字面翻译，Smartling 的可视化上下文工具（包括上下文捕获 Chrome 扩展程序和上下文捕获 JavaScript 库）为翻译人员提供字符串所属页面或屏幕的快照，并且可以自动捕获 XLIFF 注释作为翻译人员的说明。对于像 ARIA 标签这样的字符串来说，两者都很有用，因为 ARIA 标签本身没有视觉渲染可供转换。相同的词汇表、样式指南和质量检查配置文件（包括词汇表合规性和目标长度限制检查）可以保持产品可见用户界面的一致性，这些词汇表、样式指南和质量检查配置文件也适用于这些字符串，因此屏幕阅读器体验在每个发布的语言环境中都能与可见界面的语气和术语相匹配。
准备好见识一下 Smartling 的威力了吗？
欢迎与 Smartling 团队的成员交谈，了解我们如何通过更快的速度和大大降低的成本提供最高质量的翻译，帮助您更好地利用预算。