Accessibility and AI Foundations — 数字可访问性与 AI 基础

01 了解数字可访问性与 AI

什么是数字可访问性（a11y）？

可访问性（a11y — 取自 accessibility 的 a 和 y 中间 11 个字母）描述了设计产品和服务的实践，使其能够被最广泛能力范围的人独立有效地使用。a11y 致力于创造一个公平的体验，确保每个人都能感知、理解、导航和与产品或服务交互。世界卫生组织估计超过 10 亿人（约全球人口 16%）有残疾。这意味着开发者必须为所有人设计，包括有永久视觉、听觉、身体、言语、认知或神经残疾的人。

数字可访问性的四大好处

包容性用户体验：确保任何人可使用产品，包括各种残疾人士。
市场扩张：移除障碍将产品开放给更大受众，也包括临时或情境性限制 — 手臂骨折、直射阳光下使用应用、嘈杂环境中消费内容。a11y 惠及每个人。
法律合规：遵循 WCAG、ADA、Section 508、EAA 等法律标准，最小化法律和财务风险。
更干净的代码和更易维护：可访问编码实践带来更结构化、更语义化的代码，改善辅助技术的内容体验，也使代码更易维护和更新。

AI 核心能力

AI 使计算机能够执行通常需要人类智能的任务。当主动和负责任地使用时，AI 可以显著增强所有人的体验，包括残疾人。

机器学习（ML）：训练计算机模型从数据中做出预测和得出结论 — 用于天气预测、销售预测、风险评估和定价优化
生成式 AI：创建原创内容 — 自然语言文本、图像、代码
回答问题：GPT 等模型解释问题意图并生成详细对话式响应
摘要（Summarization）：LLM 压缩和重混文本 — 用于会议笔记或文章摘要
翻译（Translation）：LLM 学习不同语言结构规则（包括编程语言）以准确翻译
计算机视觉（Computer Vision）：通过视频和图像分析进行视觉解释。在引导式图像生成中，用户描述图像让 AI 创建

语音和文本 AI 能力

语音识别（ASR / STT）：将人类语音转换为书面格式。为运动残疾用户提供语音控制，为聋/重听用户提供实时字幕。

文本转语音（TTS）：AI 将文本转换为语音，能够分析和再现特定人的独特语音模式。为视障用户提供内容消费。

纠错：AI 检测和纠正语法/拼写错误，使用上下文填补语音转文本中缺失的单词（如自动字幕），提高转录的准确性。

要充分实现 AI 在可访问性方面的潜力，需要采取主动方法：清楚理解 AI 为 a11y 带来的挑战和限制，并积极努力减轻它们。

02 应对 AI 偏见和伦理挑战

AI 是一个强大但必须负责任使用的工具。Salesforce 致力于让 AI 可访问、包容和可信。负责任地使用 AI 意味着将其视为合作伙伴和头脑风暴工具，而非快速解决方案或人类决策的替代品。

AI 的四大挑战与局限性

偏见与公平性问题：AI 模型反映和放大训练数据中存在的偏见，因数据可能未充分代表多样化人群。AI 输出可能强化社会偏见。
准确性与可靠性问题：AI 可能生成幻觉（Hallucinations） — 不准确或虚构的信息。结果可能"自信地错误"，使错误更难检测。
人工监督缺失：存在过度依赖 AI 而没有足够人工验证的风险，团队可能不知道如何正确监督 AI 输出。
组织与采纳障碍：团队将 AI 集成到工作流程时经历摩擦和不确定性，导致采纳程度不均。

AI 偏见如何创建可访问性障碍

AI 系统未能考虑多样化需求，特别是残疾人的需求，构成了重大风险。

语音识别偏见：训练数据缺乏多样化语音模式或口音的样本 → 模型对这些人表现差 → 创建了直接障碍。

替代文本（Alt Text）生成：幻觉可能影响 alt 文本（视障用户通过屏幕阅读器理解图像的关键工具），生成不正确或无意义的描述。AI 模型从海量互联网数据中学习，这些数据包含社会偏见和不准确信息。错误的 alt 文本在医疗和金融等领域可能造成严重危害。

代码生成的可访问性：生成式 AI 编写代码时必须在正确的 ARIA 属性等 a11y 标准上训练，否则生成的代码将创建不可访问的数字体验。

自动 AI 测试：AI 驱动的 a11y 测试工具加速问题发现，但完全依赖自动化可能创建新障碍。必须以"Human in the Loop"（HITL）——人工验证和手动测试来补充。

AI 可访问性的法律框架

在开发 AI 体验时应用既定的可访问性标准：

ADA（Americans with Disabilities Act）：美国民权法，禁止基于残疾的歧视，适用于物理和数字空间
Section 508：美国联邦法律，要求联邦机构确保电子和信息技术对残疾人可访问，设定了具体技术标准
EAA（European Accessibility Act）：欧盟法律，为广泛的数字和物理产品规定 a11y 标准，适用所有欧盟成员国

这些政策奠定了 WCAG（Web Content Accessibility Guidelines） — 可访问数字内容的基础标准。当前版本 WCAG 2.2 提供了满足法律要求的实用实施指南。

03 设计可访问的 AI 产品和体验

生成式 AI 在将可访问性作为核心原则开发时，提供了服务所有人、消除现有障碍并赋能残疾人的巨大潜力。

AI 和可访问性的创新

当设计合理时：

无视力或低视力用户：生成式 AI 提供丰富的上下文场景图像描述
神经多样性用户：支持执行功能 — 将复杂任务分解为更小步骤，或辨别 Slack/邮件消息的语气
聋人或重听用户：提供实时高亮关键要点的动态会议摘要

这些工具惠及所有人，但如果不从一开始就集成 a11y 实践，就可能创建障碍。始终在设计中考虑可访问性。生成式 AI 工具提高所有用户的生产力和创造力，但关键在于从一开始就将 a11y 构建到设计中 — 既要考虑工具界面（输入）的可访问性，也要考虑其生成内容（输出）的可访问性。

可访问 AI — 文本输出

文本类工具生成代码或摘要等文本信息：

结构：输出是否使用语义 HTML（标题、列表）帮助屏幕阅读器导航和消费？
可读性：能否提示 AI 输出平实语言以改善认知可访问性？
实时状态更新：长文本生成过程中，应用是否向屏幕阅读器传达进度？
表单：控件是否包含可见、持久的标签（仅占位符文本不够）？
Switch Control 或语音输入：如何确保 AI 交互对运动残疾用户可访问？如何处理语音识别中的偏见？

可访问 AI — 图像、音频和视频输出

图像类工具（视觉艺术、照片、数据可视化）：

自动 Alt Text：工具是否为生成的图像包含准确有意义的 alt 文本描述？管理员能否编辑？
颜色对比度：AI 生成的 UI 或图表是否检查 WCAG 对比度比例（普通文本 4.5:1，大文本 3:1）？

音频类工具（语音、音乐、音频修复）：

转录：确保生成的音频包含同步、准确的文字转录
可视化：播放器是否有键盘可访问、高对比度的播放/暂停按钮？
个性化：用户能否个性化声音特征 — 音高、风格、语速、语言？

视频类工具（带同步音频的移动图像）：

音频描述（AD）：是否有描述视觉动作的辅助音轨？
癫痫安全：确保闪烁不超过每秒三次，否则对光敏性癫痫用户构成危险

设计检查清单 — 颜色、对比度与交互

颜色和对比度：

所有文本满足最低对比度 — 普通文本 4.5:1，大文本 3:1
功能性非文本 UI 元素（含焦点指示器）遵守 3:1 对比度
绝不仅仅用颜色作为传达信息的唯一手段 — 用图标、文本等补充

交互和输入：

每个交互元素可通过键盘在可预测、合乎逻辑的顺序中操作（Tab/Shift+Tab/Enter/Space）
每个交互元素有可见焦点指示器，不同状态用不同样式
表单字段有可见标签清晰描述用途 — 仅占位符文本不足
避免仅悬停时出现的内容
多区域交互时（代理面板 + Builder UI）保持焦点一致可预测

设计检查清单 — 响应式设计与屏幕阅读器

响应式设计和通用组件：

使用现有可访问设计模式和组件库（SLDS、LWC），而非自建 — 它们已经过 a11y 测试
优先响应式设计 — 布局在小视口和 200% 文本缩放时重新换行
移动端触控目标至少 44x44px，最小 24x24px

屏幕阅读器注意事项：

实现 ARIA 属性或实时区域，使屏幕阅读器正确播报动态内容（如流式聊天响应）
使用正确的 HTML 和 ARIA 角色，使辅助技术理解每个组件（按钮/标题/导航区域等）

包容性用户测试的角色

Salesforce 与 Fable 合作，让残障人士参与研究和用户测试。Fable 提供全面的 a11y 研究服务，收集来自多样化参与者的反馈：屏幕阅读器用户（JAWS、NVDA、VoiceOver）、屏幕放大用户、替代导航用户（语音控制、Switch 设备），在多种浏览器和设备组合上测试。反馈通过用户访谈、原型审查和专门研究会话收集。

Salesforce 实践"Shift Left" — 从设计最初阶段就集成 a11y 检查，使可访问性成为项目一开始就存在的核心设计决策。

关键研究发现 — 用户挑战 (1/2)

1. 模糊的 AI 响应：用户期望 AI 提高任务效率。模糊答案不实用。解决方案：如果工具无法生成好响应，提供明确指导 — 建议关键词、重述提示的技巧、相关主题链接。

2. 打字和 Switch 设备困难：Switch 设备用户打字困难且耗时。解决方案：在用户输入时提供预生成的文字或短语建议，减少多查询交互中的用户努力。文字提示是不使用语音输入的用户的替代方案。

3. 复杂 Builder 中不可预测的焦点：在带代理集成的 Builder 流程中，键盘焦点经常移到意外位置，对屏幕阅读器和仅键盘用户造成混淆。解决方案：以编程方式管理键盘焦点 — 动态加载新面板时移动焦点到标题或首个有意义控件，防止 Tab 到底层页面直到关闭面板，然后返回焦点到原始启动组件。