辅助功能新特性 — WWDC 中文总结

一句话判断

Accessibility Nutrition Labels 让辅助功能从”良心活”变成了”竞争力指标”——用户下载前就能看到你做了没有，这比任何技术 API 都更有杀伤力。

这场 Session 讲了什么

苹果终于对辅助功能动了真格。过去十年，辅助功能更新的套路基本不变：加几个新 API，发一段感人视频，呼吁开发者重视。这次不一样。Accessibility Nutrition Labels 把你的辅助功能支持情况直接挂在 App Store 产品页上，用户不需要下载就能看到你的应用是否支持 VoiceOver、Dynamic Type、高对比度模式。食品营养标签的比喻很精准——一旦信息透明化，市场机制会比任何 WWDC 演讲都更有效地推动改变。

技术层面，今年的更新围绕两条线展开。一条是评估和度量：新的 Accessibility Evaluation API 给了开发者一套系统化的检查工具，能量化你的应用在各辅助功能维度的表现，然后把这些数据提交到 App Store Connect。另一条是适配：Assistive Access 模式的 API 更成熟了，Liquid Glass 的辅助功能兼容机制也补上了——Reduced Transparency、Increased Contrast、Reduced Motion 三个环境值让自定义视图能正确响应系统级辅助功能设置。

值得深挖的点

Accessibility Nutrition Labels 的博弈

这个特性的设计逻辑很有趣。评估是自动化的，但提交是手动的——你需要主动跑评估、主动提交结果。这意味着什么？意味着你不能”忘了”提交，因为不提交本身就是一种信号。当竞品都展示了完整的辅助功能标签，而你的产品页上这块是空白的，用户会怎么想？

苹果显然考虑过”标签造假”的风险。如果开发者只是为了让标签好看而做表面功夫，比如给所有按钮都加一个通用的 accessibilityLabel，标签上勾了”支持 VoiceOver”，但实际体验一塌糊涂——这反而会伤害用户信任。我猜测后续苹果会引入某种质量验证机制，或者通过用户反馈数据来校准标签的可信度。短期内，先发优势属于那些本来就认真做辅助功能的团队。

Assistive Access 的架构挑战

Assistive Access 不是一个简单的”大字体模式”。它要求你重新设计信息架构：每个屏幕只有一个核心任务，界面元素大幅精简，按钮尺寸从 44pt 建议提升到 60pt 以上。问题在于，很多应用的界面本身就是高度耦合的——一个列表页面可能同时承载了浏览、搜索、筛选、收藏多个功能。在这种界面上做”减法”，不是隐藏几个按钮那么简单，而是需要拆解和重组 UI 层级。

@Environment(\.assistiveAccess) 环境值让你能检测当前是否处于 Assistive Access 模式，然后切换到专用界面。这本质上是在维护两套 UI。对于独立开发者或小团队，这个成本不低。更现实的做法可能是用 Assistive Access 作为审视信息架构的镜子——如果一个界面在 Assistive Access 模式下很难简化，那它在正常模式下可能也太复杂了。

代码片段

检测 Assistive Access 模式并切换界面。坑：别只隐藏元素，要考虑简化后的导航路径是否还能让用户回到上一步。

struct ContentView: View {
    @Environment(\.assistiveAccess) var assistiveAccess

    var body: some View {
        if assistiveAccess.isActive {
            SimplifiedView()
        } else {
            FullView()
        }
    }
}

响应 Liquid Glass 的辅助功能降级。坑：系统只自动处理标准控件，自定义背景必须手动判断。

struct AdaptiveGlassCard: View {
    @Environment(\.accessibilityReduceTransparency) var reduceTransparency

    var body: some View {
        Text("内容")
            .padding()
            .background {
                reduceTransparency
                    ? Color(.systemBackground)
                    : Rectangle().glassEffect()
            }
    }
}

用 Accessibility Evaluation API 建立基线。坑：评估结果只能反映当前状态，每次 UI 变更后都需要重新跑。

// 在 CI 流程中集成辅助功能评估
func runAccessibilityAudit() {
    let evaluator = AccessibilityEvaluator()
    let report = evaluator.evaluate()
    // report.voiceOverCoverage: Float
    // report.dynamicTypeSupport: Bool
    // report.contrastCompliance: Bool
    submitToAppStoreConnect(report)
}

最佳实践

建议按以下优先级推进：

第一，立即跑一次 Accessibility Evaluation API，拿到基线数据。不用急着修所有问题，先了解应用在什么水平。很多团队对自家应用的辅助功能状态有不切实际的乐观。

第二，VoiceOver 支持是投入产出比最高的方向。Dynamic Type 大多数应用已经用语义字体了，高对比度系统会自动处理标准控件——但 VoiceOver 要求逐个检查交互元素，工作量最大，也是用户感知最强的。

第三，Assistive Access 的适配优先级较低。除非应用目标用户群体中认知障碍用户占比很高，否则优先级低于前两项。等 Accessibility Nutrition Labels 正式上线后，根据用户反馈再决定投入力度。

还有什么值得关注

包容性债务（Inclusion Debt）：苹果正式把这个概念提出来了，意思是累积未解决的辅助功能缺陷应该像技术债务一样被追踪和偿还。
Liquid Glass 的 Reduced Motion 适配：新的玻璃动效在”减少动效”模式下需要降级为静态效果，自定义动画需要额外处理。
Assistive Access 自定义场景定义：开发者现在可以为特定使用场景定义专用的简化界面，而不仅仅是全局开关。