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

引言

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

3.2 效率提升模型

对比传统注释方式：

3.3 风险控制机制

预设注释通过以下方式降低实施风险：

1. 版本同步：与设计系统版本号自动绑定
2. 必要覆盖：强制标注易忽略项（如手风琴的标题层级）
3. 渐进披露：按需展开技术细节，避免信息过载

结论

设计系统组件的可访问性实现是个持续演进的过程。通过Primer A11y Preset这类智能注释系统，组织可以：

1. 建立组件级与页面级的双重合规保障
2. 将专家知识转化为可扩展的系统能力
3. 在标准化与灵活性间取得平衡

正如案例所示，当手风琴组件采用预设注释后，标题层级错误率从31%降至4%，同时设计开发协作效率提升近3倍。这种方案的成功实施，为构建真正包容性的数字产品提供了可复制的技术路径。

文章参考内容

Github Copilot官网