OpenHarmony UI组件的可访问性如何保障

OpenHarmony UI 组件可访问性保障方案

一 标准与原则

• 以 WCAG 2.1 AA 为基线：普通文本对比度至少 4.5:1、大文本 3:1；所有信息与交互必须可被屏幕阅读器、键盘、语音等方式感知与操作。
• 遵循四大原则：可感知、可操作、可理解、健壮性；在 ArkUI 中通过语义化属性、焦点管理、动态通知与辅助技术兼容来实现。
• 将无障碍纳入研发全流程：设计阶段定义语义与交互约束，开发阶段落实属性与焦点，测试阶段用工具与用例持续验证。

二 ArkUI 原生组件的关键做法

• 语义化与标签：为图片、图标按钮、自定义控件提供 accessibilityLabel/accessibilityHint/accessibilityDescription，必要时用 accessibilityGroup(true) 将复合组件合并为一个可理解的单元，并为容器设置 semanticContainer(true)。
• 焦点与顺序：为可交互元素开启 focusable(true)，使用 focusOrder(n) 明确 Tab 顺序；复杂列表与表单按逻辑分组并减少焦点跳跃。
• 动态内容通知：数据加载、状态变更、操作结果等通过 accessibility.notifyEvent 发送事件（如 ACCESSIBILITY_EVENT_TYPE_NOTIFICATION_STATE_CHANGED）提示读屏。
• 键盘与遥控器：为自定义组件实现 onKeyEvent，正确处理 Enter/Space/方向键；TV/车机需支持方向键导航与焦点高亮。
• 列表与表单：列表项使用组合语义描述（标题、摘要、状态、操作），表单控件绑定清晰的标签与错误提示，确保可单独获焦与说明。

三 跨端与混合栈的桥接策略

• Flutter-on-OpenHarmony 现状：社区版 flutter_ohos 引擎目前存在无障碍桥接缺口，Semantics 节点无法自动对接 OpenHarmony 无障碍服务，读屏与焦点可能不生效。
• 双通道融合架构：
  • Flutter 侧用 Semantics 声明语义；
  • ArkTS 侧通过 AccessibilityAbility/事件通道 注册节点与转发事件；
  • 关键操作由 ArkTS 调用 TextToSpeech 提供语音反馈；
  • 系统设置（如字体大小、对比度）由 ArkTS SettingsObserver 监听并回传 Flutter 动态重绘。
• 适用场景：跨端复用 UI 的同时，保证在 OpenHarmony 设备上具备完整的读屏、焦点与语音反馈体验。

四 主题与系统设置适配

• 动态响应系统设置：监听 fontSize/highContrastText 等系统配置变化，按用户偏好调整 字号、行高、对比度与颜色，避免信息丢失与低对比阅读困难。
• 设计 Tokens 驱动：以 Design Tokens（色彩、字号、间距、圆角、动效）统一无障碍约束，如正文与交互元素对比度 ≥ 4.5:1、大按钮触控区与字号适配不同设备形态（如 Watch ≥ 18sp、Car ≥ 20sp）。
• 主题与组件库：采用支持主题与无障碍约束的组件体系（如 OmniUI），在统一 API 下保证对比度、焦点状态与交互一致性，降低维护成本。

五 测试与上线清单

• 工具与流程：
  • 使用 DevEco Studio 无障碍检查/诊断 扫描问题；
  • 在真机开启 屏幕阅读器 走查关键路径（登录、表单、列表、弹窗、导航）；
  • 将无障碍检查纳入 CI/CD，并建立可回归的自动化/手工用例集。
• 上线前自检要点：
  • 所有交互元素具备可聚焦与可描述标签；
  • 对比度与字号满足 WCAG AA；
  • 动态内容变更有语音/提示反馈；
  • 键盘/遥控器导航连续、无陷阱；
  • 列表与表单语义完整、分组合理。