可访问性和包容性设计 - 模式


了解更多关于架构良好的公平性的信息 → 通过 Lightning 和 Experience Cloud 实现无障碍

模式

何处查看好样的
平台 | 设计标准✅ WCAG 2.2 AA 级是自定义构建工作（Experience Cloud、LWC、自定义主题）的最低可访问性栏，由构建团队验证
平台 | 设计标准✅可感知原则：图像和图标存在文本替代项；视频附带说明
平台 | 设计标准✅操作原则:所有功能均可通过键盘单独操作，无需鼠标或触摸 — 语音控制和开关访问辅助技术依赖于相同的键盘/焦点模型
平台 | LWC✅ 标准 Lightning Web 组件按设计使用，自动提供基准可访问性
平台 | LWC✅ 自定义组件实施显式可访问性，并使用屏幕阅读器进行测试验证
平台 | 测试计划✅ 可访问性测试包含在所有测试阶段（非临时或可选）

反模式

何处查看什么不好的样子
平台 | 设计标准WCAG 2.2 AA 级被视为可选或“很高兴拥有”，而不是最低要求
平台 | 设计标准图像和图标缺少文本替代；视频缺少说明
平台 | 设计标准⚏ 功能需要鼠标或触摸交互，没有键盘选项
平台 | LWC自定义组件是在没有无障碍实施或验证的情况下构建的
平台 | LWC自定义输入组件使用 div 元素和 CSS 样式，没有语义意义或键盘可访问性
平台 | 测试计划可访问性测试是临时的、可选的，或仅在启动前执行（并非在整个开发过程中）

模式

何处查看好样的
平台 | LWC✅ 语义 HTML 元素（页眉、导航、主、侧、页脚、文章、部分）用于自定义 Lightning Web 组件
平台 | LWC✅ ARIA 重大事件、角色和属性仅在语义 HTML 无法传达界面行为的地方应用
平台 | LWC✅ 动态内容更新使用 aria-live 区域向屏幕阅读器用户宣布更改
平台 | LWC✅ 自定义交互式组件具有与其行为相匹配的明确角色定义
平台 | LWC✅ 表单标签使用适当的标签元素或 aria-labeledby 属性与所有表单输入明确关联
平台 | LWC✅ Lightning 输入组件配置了所需的标签属性，提供了内置的标签关联
平台 | 测试计划✅ 使用实际屏幕阅读器进行测试：Windows 上的 JAWS 和 NVDA、macOS 和 iOS 上的 VoiceOver、Android 上的 TalkBack
平台 | 测试计划✅ 使用真正的辅助技术进行手动测试的人员了解屏幕阅读器用户如何导航
平台 | 设计标准✅ 占位符文本永远不会用作唯一标签，因为占位符会在焦点上消失，并且为屏幕阅读器提供的上下文不足

反模式

何处查看什么不好的样子
平台 | LWC⚏ 内容层次结构中大量标记条的含义迫使屏幕阅读器用户线性导航
平台 | LWC仅在语义 HTML 无法传达界面行为时，不使用 ARIA
平台 | LWC动态内容更新不使用 aria-live 区域；屏幕阅读器用户错过重要更改
平台 | LWC自定义交互式组件缺乏明确的角色定义；屏幕阅读器错误地宣布它们
平台 | LWC表单输入缺少明确的标签关联；占位符文本用作唯一标签
平台 | 测试计划自动可访问性工具仅供使用；不执行手动屏幕阅读器测试
平台 | 测试计划测试由不熟悉屏幕阅读器用户实际导航方式的视力用户执行

模式

何处查看好样的
平台 | 设计标准✅ 可通过键盘访问完整功能，无需在用户旅程中的任何时间点进行鼠标或触摸交互
平台 | LWC✅ 逻辑聚焦顺序遵循可视布局和交互流
平台 | LWC✅ 当动态内容加载或模态打开时，焦点以编程方式管理，以指导键盘用户了解新内容
平台 | LWC✅ 模态和弹出组件在打开时将焦点移到模态标题或第一个交互式元素；在关闭时将焦点返回到触发器按钮
平台 | 设计标准✅ 可见的焦点指示器清楚显示哪个元素始终具有键盘焦点
平台 | 设计标准✅ 焦点指示器满足周围内容的 3:1 对比度要求
平台 | LWC✅ 用户可以单独使用键盘导航进出所有组件，而不会陷入困境
平台 | LWC✅ 模态对话框在打开时将焦点困在模态中（防止访问隐藏的内容），但在关闭时释放焦点
平台 | 设计标准✅ 频繁操作的键盘快捷方式避免与屏幕阅读器快捷方式和浏览器快捷方式冲突
平台 | 设计标准✅ 单字母快捷方式仅在特定组件有焦点时激活（非全局），以避免与屏幕阅读器导航命令冲突
平台 | 文档✅ 所有自定义键盘快捷方式都记录在可访问的帮助内容中
平台 | 测试计划✅ 测试步骤包括仅使用键盘导航所有用户旅程，无需使用鼠标或触摸

反模式

何处查看什么不好的样子
平台 | 设计标准⚏ 功能需要鼠标或触摸交互；仅限键盘的用户无法完成关键任务
平台 | LWC焦点顺序不遵循逻辑可视布局；用户会以意想不到的顺序使用 Tab 键浏览元素
平台 | LWC打开的模态没有焦点管理；键盘用户困在现在隐藏的触发按钮上
平台 | LWC模态关闭不会将焦点返回到触发器按钮；用户必须搜索他们在页面中的位置
平台 | 设计标准⚠ 焦点指示器出于美观原因被禁用；用户看不到哪个元素有焦点
平台 | 设计标准焦点指示器对比度不足 (<3:1)
平台 | LWC用户被困在没有逃逸机制的界面区域（键盘陷阱）
平台 | LWC嵌入内容（iframes、第三方小部件）永久捕获键盘焦点
平台 | 设计标准单字母快捷方式激活与屏幕阅读器单字母导航命令冲突的全局
平台 | 文档自定义键盘快捷方式未记录；用户无法发现

模式

何处查看好样的
平台 | 设计标准✅ 对于 18pt 或 14pt 以下粗体的正常文本，对比度最低为 4.5:1
平台 | 设计标准✅ 大文本和有意义的 UI 组件和图形（表格边框、信息图标）的最低 3:1 对比度；纯装饰和禁用元素除外
平台 | Experience Cloud✅ 自定义主题和品牌化 Experience Cloud 站点包含使用浏览器开发工具或自动检查器的显式对比验证
平台 | 设计标准✅ 支持将文本大小调整为 200%，而不会丢失内容或功能（WCAG 要求）

反模式

何处查看什么不好的样子
平台 | 设计标准文本对比度低于 4.5:1（正常文本）或 3:1（大文本和 UI 组件）
平台 | Experience Cloud部署自定义主题时没有对比验证；弱视用户无法阅读内容
平台 | 设计标准文本调整大小超过 200% 会中断丢失内容或功能的布局

模式

何处查看好样的
平台 | CI/CD✅ Axe-core 或 Lighthouse 可访问性扫描集成到 CI/CD 漏斗中，捕捉每个部署的结构问题
平台 | CI/CD✅ 当检测到关键的可访问性问题时，构建失败
平台 | 测试计划✅ 在整个开发过程中定期进行手动测试，包括屏幕阅读器、仅键盘导航和浏览器缩放到 200%
平台 | 测试计划✅ 测试显示交互问题，包括混淆公告顺序、焦点管理失败和键盘陷阱
平台 | 业务✅ 在整个设计过程中，将残疾用户纳入可用性测试
平台 | 业务✅ 可用性测试揭示了自动化和手动专家测试错过的实际障碍
平台 | 测试计划✅ 自动测试（按数量计算约占问题的57%）、手动测试（交互问题）和用户测试（真实障碍）全部执行

反模式

何处查看什么不好的样子
平台 | CI/CD⚏ 可访问性扫描未集成到 CI/CD 漏斗中
平台 | CI/CD尽管存在严重的可访问性问题，但构建仍会继续
平台 | 测试计划不使用辅助技术进行手动测试；仅使用自动扫描
平台 | 业务⚠ 残疾用户不包括在可用性测试中
平台 | 测试计划⚠ 自动可访问性扫描仪在启动前运行一次，并考虑完成可访问性测试