The process of inclusive design
Design 入门 12m

包容性设计的流程

The process of inclusive design

2021年6月8日

在 Apple 官方观看视频

一句话判断

这个 Session 把包容性设计从「理念」拉到了「流程」——告诉你苹果团队具体是怎么在日常开发中一步步落实包容性的，可以直接抄。

这场 Session 讲了什么

和「The practice of inclusive design」（Session 10275）聚焦在具体设计案例不同，这个 Session 聚焦在流程层面——一个团队应该怎样组织工作才能确保产品对所有人可用。

Session 提出了一个四步循环流程：识别（Identify）→ 共情（Empathize）→ 设计（Design）→ 验证（Validate）。识别阶段通过数据和用户反馈发现谁被排除在你的产品之外。共情阶段通过直接接触有不同能力的用户来理解他们的真实需求。设计阶段用「persona spectrum」（用户画像谱系）来确保设计方案覆盖不同场景。验证阶段用辅助功能测试工具和真实用户测试来确认效果。

Session 用一个具体的 Apple 内部项目为例，展示了这个流程在实践中的运作方式。比如在识别阶段，团队发现很多用户在户外阳光下使用手机时，App 的高对比度模式不够好——这些用户并不是永久性的视觉障碍者，但他们在特定环境下遇到了同样的困难。通过共情阶段的用户访谈，团队理解到问题的根源不是颜色选择，而是对比度不足。设计阶段他们创建了多个「情境化 persona」（烈日下的用户、单手抱着婴儿的用户、戴着手套的用户），确保解决方案对这些场景都有效。

值得深挖的点

Persona Spectrum 方法。 传统的 persona 是一个虚构的用户（「张三，30 岁，上班族」），Persona Spectrum 把它扩展成了一个能力谱系——从「永久性限制」（盲人用户）到「暂时性限制」（眼睛进了沙子）到「情境性限制」（在阳光下看手机）。这个扩展迫使设计师考虑更广泛的场景，而不是把「辅助功能」当成一个独立的需求类别。Session 展示了如何在设计评审中用 Persona Spectrum 做自查：对于每个核心用户流程，分别用三个谱系上的 persona 走一遍，看哪里会卡住。

自动化辅助功能测试的局限性。 Session 明确指出：Accessibility Inspector 和自动化测试只能发现 30% 的辅助功能问题。剩下的 70%（信息架构是否合理、操作流程是否直觉、文字描述是否有意义）需要真人测试。苹果建议每个季度至少安排一次「辅助功能用户测试」——邀请有不同辅助功能需求的用户使用你的产品，观察他们的操作过程。这不是奢侈，而是必要的质量保证步骤。

代码片段

// 辅助功能自查清单（可以在 CI 中自动化检查的部分）

// 1. 检查所有图片是否有 accessibility label
// 在 XCTestCase 中遍历视图层级
func testAccessibilityLabels() {
    let rootView = viewController.view!
    let unlabeled = findUnlabeledImages(in: rootView)
    XCTAssertTrue(unlabeled.isEmpty,
                  "以下图片缺少 accessibility label: \(unlabeled)")
}

// 2. 检查点击目标大小（至少 44x44 pt）
func testTapTargetSizes() {
    let smallTargets = findSmallTapTargets(in: viewController.view!)
    XCTAssertTrue(smallTargets.isEmpty,
                  "以下控件小于 44pt: \(smallTargets)")
}
// 使用 Accessibility Inspector 的命令行版本做自动化检查
// 在 CI 脚本中添加：
// xcrun accessibilityinspector audit --app "MyApp"

// SwiftUI 中的辅助功能组合修饰符
struct AccessibleButton: View {
    let action: () -> Void

    var body: some View {
        Button(action: action) {
            Image(systemName: "star.fill")
        }
        .frame(minWidth: 44, minHeight: 44)  // 确保点击区域
        .accessibilityLabel("收藏")           // 提供语义描述
        .accessibilityAddTraits(.isButton)    // 标记为按钮
    }
}
// 在不同辅助功能模式下预览
struct PreviewWithAccessibility: View {
    var body: some View {
        ContentView()
            // 动态字体预览
            .environment(\.sizeCategory, .accessibilityExtraExtraExtraLarge)
    }
}

#Preview {
    Group {
        ContentView()
            .previewDisplayName("默认")
        ContentView()
            .environment(\.sizeCategory, .accessibilityLarge)
            .previewDisplayName("大字体")
        ContentView()
            .environment(\.colorSchemeContrast, .increased)
            .previewDisplayName("高对比度")
    }
}

最佳实践

  • 在产品路线图中为每个功能预留 15-20% 的时间做辅助功能适配，不要留到版本末尾再补
  • 建立一个「辅助功能 champions」角色——团队中指定 1-2 个人负责在每个 PR 中做辅助功能审查
  • 用 Xcode Preview 的不同 sizeCategory 和 colorSchemeContrast 组合来做视觉回归测试
  • 每次设计评审时，在 Persona Spectrum 上选 3 个不同能力的 persona，用他们的视角走一遍核心流程

还有什么值得关注

  • 苹果的 Accessibility Examples 项目在 GitHub 上开源，包含了多种辅助功能的实现范例
  • UIAccessibility.isAssistiveTouchRunning 等属性可以帮你检测用户是否在使用特定的辅助功能
  • App Store 的辅助功能标签功能让有需求的用户在下载前就能判断你的 App 是否适合他们
WWDC 2021