Android TalkBack 无障碍优化： 为控件自定义转子导航动作

Android TalkBack 无障碍优化： 自定义转子导航动作

在优化适配 Android 应用的无障碍时，Accessibility Actions（自定义动作）是一个非常实用但很多开发者都不知道的 API。很多人误以为给控件添加了长按菜单，就可以在 TalkBack 导航菜单中找到这些操作，其实不然。

实际上，自定义Actions的设计逻辑与 TalkBack 的底层交互是深度绑定的。如果不清楚 TalkBack 是如何暴露这些Actions的，写出来的往往达不到预期的无障碍效果。

本文将结合具体场景，由浅入深地带你了解 Android 自定义无障碍操作的最佳实践，希望能帮大家避开适配误区。

一、 场景分析

我们以大家最熟悉的聊天界面为例。

在消息列表中，每条消息除了"点击查看详情"/"点击放大图片"这个主交互外，通常还包含一堆附加操作菜单，复制、转发、删除、引用回复等。对于健视用户来说，处理这些操作的方式非常直观：长按消息，弹出上下文菜单，点击目标菜单项。

但视障用户面对这个交互时，体验却大打折扣。TalkBack虽然也支持单指双击按住不放触发菜单，但这十分不便。更重要的问题是长按后的体验不佳。

长按弹出的菜单是个浮层，TalkBack 用户触发长按后，焦点需要跳进这个浮层里，再逐项遍历找到"复制"，最后双击执行。整个交互链路变成了：聚焦消息 -> 双击长按 -> 等待菜单弹出 -> 在新出现的菜单内重新浏览 -> 找到目标 -> 双击。不仅步骤繁琐，而且用户很难预判"长按之后会出来什么"。更糟糕的是，弹出的菜单浮层经常会发生失焦，导致用户根本不知道当前焦点落在了哪里。

面对这一问题，很多开发者会直接用一种简单粗暴的办法，把复制、转发、删除做成独立按钮，直接放在TalkBack线性浏览序列中，每条消息后面，对应的是这些菜单按钮。

这种做法在技术上当然可行，但在实际体验中却是一场灾难：每条消息会多出三四个焦点元素，十条消息就是四十多个焦点。TalkBack 用户每次线性遍历（单指左右滑动）都要经过这些节点。本来用户只是想快速翻到最底下看新消息，结果中间被几十个"复制"、"转发"的焦点阻碍，浏览效率直接崩溃。

Android 的 Accessibility Actions 就是为了解决这个矛盾而设计的：把次级操作挂到控件本身的 action 列表上，不增加焦点数量，不依赖视觉弹窗，让 TalkBack 用自己的原生菜单体系按需暴露这些操作。

二、 如何注入自定义操作

AndroidX Core 库提供了 ViewCompat.addAccessibilityAction 方法，能给视图的 AccessibilityNodeInfo（无障碍节点信息，TalkBack 读取控件可访问信息的底层数据结构）追加操作项。

// 增加"复制"操作
ViewCompat.addAccessibilityAction(messageView, "复制") { view, args ->
    // 在此执行复制逻辑
    true // 返回 true 表示操作已被消费
}
// 增加"转发"操作
ViewCompat.addAccessibilityAction(messageView, "转发") { view, args ->
    // 执行转发逻辑
    true
}
// 增加"删除"操作
ViewCompat.addAccessibilityAction(messageView, "删除") { view, args ->
    // 执行删除逻辑
    true
}

上述代码，把三个操作挂在了同一个消息控件上。当 TalkBack 聚焦这条消息时，朗读的依然是消息内容本身，绝对不会多出三个额外的焦点。这三个操作作为节点 action 列表里的条目，可让用户通过读屏软件提供的统一途径来访问。TalkBack聚焦后，除了能听到消息，还会听到播报，如"有操作可用"。

三、 用户如何触发这些操作？

代码把操作注入了，但TalkBack 的实际表现是怎样的，用户怎么触发呢？

实际上，TalkBack 提供了两条路径。

路径一：TalkBack 菜单（上下文环境菜单）

用户聚焦到某条消息后，通过三指点按屏幕 ，或者单指先向下再向右滑动 ，即可唤起 TalkBack 菜单。

这个菜单里包含一组全局选项（如"从聚焦项开始朗读"、"屏幕搜索"等），同时会根据当前焦点动态注入上下文选项。Google 官方文档中明确提到："执行该手势，您可能会听到与焦点对应的不同选项，例如：操作、修改选项、链接。"

这里的 "操作"，就是当前控件上挂载的自定义动作列表。用户滑动找到"操作"，双击进入子菜单，再滑动找到"复制"，双击即可执行。

路径二：Reading Controls（阅读控制项 / 导航模式）

阅读控制多指支持手势，是 TalkBack 9.1 正式引入的，类似于 Voiceover 的转子。用户可以通过三指上下滑动 ，或者单指先向上再向下/先向下再向上循环切换导航项目（如"字符"、"单词"、"标题"、"链接"等模式）。

注：国内一些 Android 读屏软件，也把 Reading Controls 称作"导航"。

当用户将导航模式切换到 "操作"（Actions） 时，单指上下滑动就可以在当前控件的自定义操作之间循环 。TalkBack 会逐个朗读"复制"、"转发"、"删除"，用户听到想要的动作后，直接双击即可激活。

这个设计思路与 iOS VoiceOver 的"转子（Rotor）"如出一辙。在 iOS 中，用户旋转转子到"操作"项目，单指上下滑动遍历自定义操作，双击激活。Android 用三指滑动切换 Reading Controls 替代了 iOS 的旋转手势，核心意图是一致的：把次级操作从视觉弹窗变成辅助技术原生的可遍历操作列表。

四、 拖动操作的无障碍替代

除了消息菜单，另一个典型的交互场景是拖动排序 （比如多个扣款方式，需要设定其默认顺序）。

视力正常的用户按住列表项拖到目标位置，松手即可完成排序。但拖拽依赖精确的位置定位和连续的手势追踪，视障用户看不见屏幕上的图标，几乎无法完成这个动作。而对于使用 Switch Access（通过外部开关访问界面的辅助技术）的用户来说，物理上就根本无法拖拽。

解决方案是将连续的拖拽手势用两个自定义动作替代："上移"和"下移"。

ViewCompat.addAccessibilityAction(listItemView, "上移") { view, args ->
    // 逻辑：将当前项与上一项交换位置
    true
}
ViewCompat.addAccessibilityAction(listItemView, "下移") { view, args ->
    // 逻辑：将当前项与下一项交换位置
    true
}

这里只是演示，若在实际的 RecyclerView 中使用，受限于 ViewHolder 的复用机制，必须改用 setAccessibilityDelegate 重写 onInitializeAccessibilityNodeInfo，并基于 bindingAdapterPosition 动态注入 Action，防止滑动时操作菜单无限堆积或位置状态错乱。

当用户聚焦到目标项后，通过前面提到的两条路径选择"上移"或"下移"，逻辑层执行位置交换并刷新列表。

操作成功，可通过 view.announceForAccessibility("已移至第x位") 给用户提供一句明确的反馈播报。

五、 覆盖点击提示（说明性信息）

另外，还有一个容易混淆的点，就是覆盖默认的点击提示，它不是自定义操作，也不是将某个自定义操作变为默认点击动作。

通过 AccessibilityDelegateCompat 可以覆盖 ACTION_CLICK 动作的默认描述：

// 重写点击描述
ViewCompat.setAccessibilityDelegate(view, object : AccessibilityDelegateCompat() {
    override fun onInitializeAccessibilityNodeInfo(host: View, info: AccessibilityNodeInfoCompat) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        val action = AccessibilityNodeInfoCompat.AccessibilityActionCompat(
            AccessibilityNodeInfoCompat.ACTION_CLICK,
            "复制"
        )
        info.addAction(action)
    }
})

它只是把 TalkBack 聚焦后读的默认提示，从"双击即可激活"改成了"双击即可复制"。也不会新增操作项，不会出现在 TalkBack 菜单的"操作"里，也不会出现在阅读控制项里，更不会改变双击后实际执行的点击逻辑。

它的适用场景很窄。只有当控件的点击行为本身就是"复制"，且默认提示太笼统时，才用这种方式补充说明。

如果控件的默认点击是"查看完整消息"，而"复制"只是个附加操作，千万不要覆盖提示。覆盖后 TalkBack 朗读"双击即可复制"，用户双击进去却是详情，这就反而误导用户了。

注意，这种方法与 contentDescription 完全不同。contentDescription 描述的是控件本身"是什么"，比如"复制"按钮；而覆盖点击标签描述的是点击这个控件"会做什么"，比如"双击即可复制"。两者可以配合使用，但作用层面完全不同。

参考资料：

• ViewCompat.addAccessibilityAction 参考
• AccessibilityNodeInfoCompat 参考
• TalkBack 菜单与阅读控制使用教程
• TalkBack 手势参考指南
• TalkBack 9.1 新增功能

---

作者

张赐荣，视障者，信息无障碍解决方案资深研发专家，长期致力于数字化产品的可及性研究与用户体验优化工作，专注于为残障人士消除数字鸿沟。

曾主持过多项大型互联网产品的无障碍改造项目及发布大量原创技术指南，系统性地推动了国内无障碍技术的标准化进程与落地部署工作，是一位在国内信息无障碍行业具有显著影响力的领军人物。