Accessibility — 基础，面向盲人用户的 VoiceOver 和 TalkBack

什么是移动应用中的 Accessibility (a11y)？

Accessibility（缩写为 a11y — 「a」和「y」之间的 11 个字母）—— 开发可供视力、听力、运动能力和认知特征障碍人士访问的应用的实践。在移动开发中，无障碍涵盖四种主要场景：盲人用户（屏幕朗读器）、弱视用户（缩放、对比度）、聋人和听障人士（字幕、声音的视觉替代方案）、运动能力受限用户（语音控制、Switch Control、大触摸区域）。

法律要求——在许多国家，无障碍是法律强制要求的。美国：《康复法案》第 508 条和《美国残疾人法案》。欧盟：《欧洲无障碍法案》（2025年）。英国：《平等法案 2010》。如果不支持无障碍，应用可能成为诉讼对象——2023年美国共提起了超过 4000 起关于数字产品不可访问的诉讼。Apple 和 Google 在审核应用时会检查无障碍：App Store 审核指南（4.2）和 Google Play Store 要求最低限度的无障碍支持。

商业论证——可访问性可以增加受众。根据 Return on Disability（2021年）的数据，残障人士每年控制着 13 万亿美元的可支配收入。可访问的应用在搜索中排名更靠前（语义化 HTML、替代文本），拥有更高的用户评分和更少的 UX 问题评论。在 IT Sectr，我们将无障碍纳入所有项目的「完成定义」——这是一个质量标准，而非可选改进。

iOS 中的无障碍：VoiceOver 和 UIAccessibility

VoiceOver——Apple 屏幕朗读器，内置于 iOS、iPadOS 和 macOS。用户在屏幕上滑动手指，VoiceOver 会朗读手指下方的元素名称。双击——激活元素。VoiceOver 支持超过 40 种手势：三指滑动（翻页）、两指双击（停止）、Z 形手势（返回）。开发者通过 UIAccessibility 协议以及 accessibilityLabel、accessibilityTraits、accessibilityHint 属性控制 VoiceOver 朗读的内容和方式。

class CustomButton: UIButton {

    override var isAccessibilityElement: Bool {
        get { return true }
        set {}
    }

    // override accessibilityLabel
    override var accessibilityLabel: String? {
        get { return "发送表单按钮" }
        set {}
    }

    // override accessibilityHint
    override var accessibilityHint: String? {
        get { return "双击以发送数据" }
        set {}
    }

    // override accessibilityTraits
    override var accessibilityTraits: UIAccessibilityTraits {
        get { return .button }
        set {}
    }
}

// Dynamic Type — 文本缩放
titleLabel.font = UIFontMetrics.default.scaledFont(
    for: UIFont.systemFont(ofSize: 16)
)
titleLabel.adjustsFontForContentSizeCategory = true

动态排版——iOS 中的 Dynamic Type 允许用户选择文本大小（从 XS 到 XXXL）。开发者使用 UIFontMetrics.scaledFont 进行自动缩放。文本必须在所有大小下正确显示：行不能截断，按钮必须随文本比例增大。UITableView 在文本大小更改时自动更新单元格高度。忽略 Dynamic Type 意味着使应用对弱视用户不可访问。

SwiftUI 中的无障碍

SwiftUI 提供了无障碍修饰符：.accessibilityLabel()、.accessibilityHint()、.accessibilityAddTraits()、.accessibilitySortPriority()。默认情况下，所有标准 SwiftUI 元素（Text、Button、Image）都已经是具有自动标签的无障碍元素。对于自定义视图，使用 .accessibilityElement(children: .combine) 将子元素合并为一个。SwiftUI 自动支持 Dynamic Type 和 VoiceOver。

VStack {
    Image(systemName: "trash")
        .accessibilityLabel(Text("删除元素"))
    Text("垃圾桶")
        .font(.body)
}
.accessibilityElement(children: .combine)
.accessibilityAddTraits(.isButton)
.accessibilityHint(Text("删除所选元素且无法恢复"))

Android 中的无障碍：TalkBack 和 contentDescription

TalkBack——Google 屏幕朗读器，预装在大多数 Android 设备上（在 Google Play 中可用于所有 Android 5+ 版本）。TalkBack 使用与 VoiceOver 相同的手势：滑动导航，双击激活。开发者通过 XML 中的 android:contentDescription 属性或代码中的 setContentDescription() 设置元素的描述。对于 ImageView，contentDescription 是必需的——没有它，TalkBack 会报告「未标记」或读取文件名。

// XML：ImageView 的 contentDescription
<ImageView
    android:id="@+id/iconDelete"
    android:src="@drawable/ic_delete"
    android:contentDescription="@string/delete_button_desc"
    android:focusable="true"
    android:clickable="true" />

// Kotlin：编程设置
iconDelete.contentDescription = getString(R.string.delete_button_desc)

// Accessibility Delegate（自定义）
iconDelete.accessibilityDelegate = object : View.AccessibilityDelegate() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View, info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.text = "删除按钮"
        info.contentDescription = "删除所选元素"
        info.className = Button::class.java.name
    }
}

// Live Regions 用于动态更新
textView.accessibilityLiveRegion = View.ACCESSIBILITY_LIVE_REGION_POLITE

Live Regions——Android 通知 TalkBack 内容更改而无需焦点的机制。android:accessibilityLiveRegion 属性接受三个值：none（无通知）、polite（在当前之后宣布）、assertive（立即宣布）。对加载状态更新使用 polite，对严重错误使用 assertive。滥用 assertive 会给用户造成混乱——TalkBack 会不断中断当前操作。

Accessibility Scanner

Accessibility Scanner——来自 Google 的免费应用，用于测试 Android 应用的无障碍性，无需访问源代码。扫描器检查：文本对比度、触摸区域大小（根据 Android 无障碍指南最小为 48×48dp）、ImageView 是否有 contentDescription、元素层次结构的正确性。对于自动化测试，使用 Espresso 的 AccessibilityChecks（导入：androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.5.1'）——它们集成到 CI/CD 中，并在每次构建时检查无障碍性。

WCAG 2.1：对比度、大小和触摸区域

WCAG 2.1（Web Content Accessibility Guidelines，网页内容无障碍指南）——由 W3C 制定的国际无障碍标准。2.1 版（2018年）包含 13 项针对移动应用的附加标准。符合级别：A（最低）、AA（对大多数组织是强制性的）、AAA（最高）。Apple 和 Google 推荐 AA 级别作为应用发布的最低标准。WCAG 2.2 于 2023 年发布，对焦点和输入进行了澄清。

移动开发的关键标准：文本对比度至少 4.5:1（AA）或 7:1（AAA），触摸区域大小最小 44×44pt（iOS）或 48×48dp（Android），支持横竖屏切换而功能不损失，可关闭动画（prefers-reduced-motion），多媒体存在字幕，兼容语音控制（iOS 上的 Voice Control，Android 上的 Voice Access）。

对比度检查工具——Colour Contrast Analyser (TPGI)、WebAIM Contrast Checker、Stark (Figma)、Accessibility Inspector (Xcode)。在 IT Sectr，我们在设计阶段（Figma + Stark）和开发阶段（Accessibility Inspector / Accessibility Scanner）再次检查对比度。最低要求——所有小于 18pt（14pt 粗体）的文本要求 4.5:1。对于标志和装饰性元素，不要求对比度。

无障碍测试：工具和检查清单

iOS 测试——Xcode 中的 Accessibility Inspector（Xcode → Open Developer Tool → Accessibility Inspector）检查每个元素的 label、traits、hint。VoiceOver 可以在设置中启用，或通过无障碍快捷方式（三次按下按钮）启用。对于自动化测试，使用带 XCTAssertTrue(app.staticTexts["label"].isAccessibilityElement) 的 XCUITest。Apple 建议在启用 VoiceOver 的情况下测试应用的所有屏幕。

Android 测试——Accessibility Scanner（Play Store）检查对比度、触摸区域大小、contentDescription。用于自动化：Espresso AccessibilityChecks（导入：androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.5.1'）。Google 推荐检查清单：每个 ImageView 都有 contentDescription，触摸区域不小于 48×48dp，文本可缩放到 200% 而不截断，所有元素可通过 TalkBack 滑动访问。

IT Sectr 检查清单——在发布前我们检查：（1）VoiceOver/TalkBack 正确朗读所有元素，（2）文本可缩放到最大大小而不损失功能，（3）所有 ImageView 都有 contentDescription，（4）文本对比度在所有主题中≥4.5:1，（5）触摸区域≥44pt/48dp，（6）没有仅通过长按可访问的上下文菜单，（7）在系统设置中支持 Reduce Motion / Remove Animations。此检查清单是每个冲刺完成定义的一部分。