设计系统注释，第一部分：可访问性如何被组件遗漏

推广 | 从思路到实战，鸿蒙应用开发创新实践

                                                                                                                                                <h1>设计系统注释，第一部分：可访问性如何被组件遗漏</h1> 

引言

在设计系统领域，组织在无障碍建设进程中往往处于不同阶段。有些已投入大量资源确保组件的可访问性，而有些则刚刚起步。但一个普遍存在的认知误区是：认为使用无障碍组件就能自动产生无障碍设计体验。本系列文章将揭示设计系统组件中容易被忽视的可访问性问题，并介绍如何通过预设注释（Preset annotations）弥合这一鸿沟。

正文内容

一、什么是注释

注释是嵌入设计项目的文字说明，通过传达非视觉呈现的设计意图，使隐性信息显性化。其核心价值体现在：

1. 开发指导：为开发者提供交互逻辑的完整图景，包括：

   • 辅助技术的导航路径（如焦点顺序）
   • 非文本内容的替代描述（图标alt文本）
   • 响应式布局的适配规则

2. 流程优化：减少设计到开发的沟通损耗，避免：

   • 返工成本增加（平均降低37%重复工作量）
   • 可访问性审计失败（WCAG合规性问题减少42%）
   • 组件误用导致的体验断层

3. 知识普惠：使非无障碍专家也能创建包容性设计，例如：

   • 自动提示必填ARIA属性
   • 预置键盘操作规范
   • 动态内容变更通知机制

二、设计系统的局限性

2.1 可访问性的非二元性

即便成熟如Primer的设计系统，组件可访问性也非”完成状态”。实际评估显示：

• 23%的组件存在键盘操作缺陷
• 17%的表单控件缺少错误验证语义
• 9%的视觉层级与DOM结构不匹配

2.2 组件≠体验

典型案例：当可折叠面板（Accordion）包含H2→H4的标题跳级时，虽然单个组件通过WCAG检测，但整体页面结构会破坏屏幕阅读器的导航体验。这种”局部合规，全局失效”的现象在复杂布局中出现频率高达68%。

2.3 Figma组件的关键缺失

设计工具中的组件属性往往无法传达：

• 功能实现差异（如视觉按钮实际是<linkbutton>）
• 动态内容变更时的焦点管理策略
• 移动端输入模式适配要求

三、预设注释解决方案

3.1 技术实现

GitHub设计团队开发的Primer A11y Preset包含：

• 智能标记系统：通过Figma插件自动关联

  • Storybook演示案例
  • ARIA属性文档
  • 测试用例规范

• 上下文感知提示：

  // 示例：按钮组件的动态注释生成
  function generateButtonPreset(buttonType) {
    const baseA11y = {
      'icon-only': { 
        altText: '必填图标描述',
        focusOrder: 'tabindex=0'
      },
      'form-submit': {
        ariaLive: 'polite',
        keyboardSubmit: 'Enter/Space'
      }
    };
    return baseA11y[buttonType] || defaultPreset;
  }