Android TalkBack：是否有一个侦听器来捕获所有可访问事件？

Question

背景:问题是什么

我的应用程序有一个单词的首字母缩略词让我们假设它是

字母表

当我使用谷歌的语音服务时，它会读出字母，这很棒。

然而，当我使用三星语音(S Voice)时，它读出的是一个词，这不是很好！

那么为什么不只是设置内容描述呢？

ABC出现在许多地方，设置替代内容描述是不可行的。此外，它还可以破解其他语音服务的内容描述，如谷歌的内容描述

我的计划

所以我不久前遇到了一个问题，我发现了这个扩展ViewGroup的类的好方法，它是onRequest estSendAccessibilityEvent。总而言之，此方法允许您捕获AccessibilityEvent以在处理之前以某种方式对其进行修改。除其他外，您可以获取要读出的内容描述并对其进行修改。

我的想法是获取当前TTS或TalkBack服务引擎正在使用的内容，并使用正则表达式编辑字母ABC的内容描述，如果它是三星语音（S Voice），则使其成为A B C。希望！

我的问题

任何人都知道一个侦听器或回调来获取要在全局或通用情况下处理的AccessibilityEvent？onRequest estSendAccessibilityEvent仅适用于ViewGroup。我找不到Active的替代方案。

任何人都知道如何捕获所有传入的＜code＞AccessibilityEvent

感谢阅读！

Answer 1

您也可以使用ViewCompat委托。事实上，上面的解决方案对我不起作用。

ViewCompat.setAccessibilityDelegate(contentView, object : AccessibilityDelegateCompat() {
     override fun onInitializeAccessibilityNodeInfo(v: View, info: AccessibilityNodeInfoCompat) {
             super.onInitializeAccessibilityNodeInfo(v, info)
             Log.d("zcz", "sdfsdf")
      }
})

Answer 2

“无辅助功能”事件/委托不适用于“活动”，也不需要。每个活动都应该有一个根/内容视图，该视图是 ViewGroup 的一个实例。这对我来说很好，可以过滤活动中的所有可访问性事件：

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    View contentView = findViewById(android.R.id.content);

    contentView.setAccessibilityDelegate(new View.AccessibilityDelegate(){
        @Override
        public boolean onRequestSendAccessibilityEvent(ViewGroup host, View child, AccessibilityEvent event) {
            Log.wtf("Event: " + event.toString());
            return super.onRequestSendAccessibilityEvent(host, child, event);
        }

    });

}

我还要指出的是，TalkBack支持通过字符导航的能力，这种解决方案可能解决了TalkBack用户不认为是问题的问题。事实上，在某些情况下，这可能被视为更糟。与实际内容相比，任何时候您更改残疾人看到的内容时，都必须非常小心。尽管公告更清晰:

"ABC" != "A B C"

例如，在不同的情况下，人们可能会将此行为视为“功能”，例如：

"NASA" 

一个幼稚的实现可能只是“toLowerCase”你所有的内容描述，或者在全大写字母之间添加一个空格。显然，这些解决方案中的每一个都会产生不同类型的问题。

我的观点是，如果屏幕上的内容让用户感到困惑，TalkBack可以让用户通过角色导航。各种平台上的AT用户将习惯于其平台的“夸克”。通过使用上面的一个解决方案，你已经在他们身上强加了一个不同的夸克。有时，最容易获得的解决方案是让“ABC”＝“ABC”，并允许AT用户自己解决问题。

如果您不打算特意以“理想”的方式修复所有字符串，那么最好不要管它。尽管如此，最好的情况是正确考虑这两个问题以及给定场景下哪种解决方案最适用。

有些时候，我喜欢用内容描述覆盖，这可能会被正则表达式或字符串匹配捕捉到。一个很好的实现是发现这些特定的场景并通过正则表达式修复它们

"OFF" -> "off" //This one is super dumb on Google's part. "OFF" shows up on every switch in the OS!
"ON" -> "on" //See above comment.
"NASA" -> "nasa"
etc.

请注意，在我的字典中，我总是朝向单词而不是单个字符公告：）。原因是，我没有改变字符串的性质。或者更确切地说，在每个inance中，以下都是正确的：

oldString.equalsIgnoreCase(newString);

现在将字符串本地化添加到等式中，嗯......这确实是一个非常复杂的问题。也许不去管事情是最好的选择。