我正在尝试让我的应用更易于访问。我很难找到有用的东西，因为没有很多文档（至少我找不到它）。
在我的应用中，Talkback不会宣布ImageViews的元素类型。我基本上想要的是Talkback为ImageView宣布我的contentDescription并用＆＃34;，Image＆＃34;进行跟进。
此链接指出＆＃34;许多辅助功能服务（如TalkBack和BrailleBack）在宣布其标签后会自动宣布元素的类型，因此您不应在标签中包含元素类型。例如，＆＃34;提交＆＃34;是Button对象的一个很好的标签，但是＆＃34; submitButton＆＃34;不是一个好的标签。＆＃34;但它没有指定它宣布哪些元素类型以及哪些元素类型没有。 https://developer.android.com/guide/topics/ui/accessibility/apps.html
非常感谢任何帮助/信息/指针。提前谢谢。
答案 0 :(得分：4)
答：不要在内容描述的末尾添加内容。这是一种可访问性违规，几乎在所有情况下都会使事情变得不那么容易（稍后会解释）。
B：许多上下文内容通过earcons（bips，beeps等）传达给TalkBack用户，你可能没有注意到。
C：是的，这是令人困惑和难以确定的，没有宣布图像，但我认为这是有充分理由的。例如，具有点击侦听器的图像可能只是一个花哨的样式按钮。在iOS中有一些特性供你改变，Android已经省略了这个非常有用的功能，所以我们坚持使用奇怪的解决方法。理想的解决方案是Accessibility API允许开发人员传达此信息。至于链接，通常会公布文本视图中的内联链接（基本上是任何安卓程序检测并自动下划线），但不是。所以，在实践中很多人都错过了链接。
现在，至于你应该/不应该自己提供这些信息的时间。如果不确定，请不要按照上述指南获得相当高的可访问性。事实上，下面的任何考虑因素都只是对抗Android操作系统的限制，而且是他们的问题！但是，Android辅助功能生态系统非常薄弱，如果您想提供更高级别的可访问性，那么难以理解！在你的尝试中，你实际上可能最终会对自己起作用。让我解释一下：
在辅助功能中，提供信息和一致性之间存在界限。通过向内容描述添加上下文信息，您将沿着这条线走。如果Google说“我们不会分享上下文信息，请自行添加！”。
你可以在音乐播放器中使用不同的音乐播放应用程序按钮，这些应用程序在TalkBack中宣布如下：
App1：“播放，按钮”
App2：“Play，Actionable”
App3：“播放，点击”
我们这里有一致性吗？现在是最后一个例子！
App4：“播放，双击点击，如果你在TalkBack上点击，如果你是键盘用户，点按输入，使用你的选择键为SwitchAccess用户.....”
注意App4的播放按钮有多复杂，这表明TalkBack正在使用的信息不仅仅是用于TALKBACK。来自您应用的辅助功能信息由大量辅助功能服务使用。当您将上下文信息“哈希”到内容描述时，确定对于TalkBack用户来说听起来可能更好，但您对盲文后退用户做了什么？给SwitchAccess用户？通常，元素的内容描述应描述元素，并为TalkBack留下上下文信息以计算/用户以确定与其他控件的接近程度。
回答您的两个特殊问题（图片和链接）：
我建议的图像在内容描述中明确表示您描述的是图像。
假设你有一只小猫的照片。
坏：小猫，图片
好：一只小猫的照片。
看到这里，如果TalkBack未能宣布这是一个图像（它会），用户仍然认为它是一张图片。您已经以一种实际上更好地描述控件的方式将内容信息添加到内容描述中。这实际上是最容易获得的解决方案！去图。
链接：
对于链接，这有点棘手。关于构成链接与按钮的构成，可访问性方面存在很大争议。在网络浏览器世界中，这是一个很好的辩论。但是，在原生手机中，我认为我们有一个非常明确的定义：
任何激活的按钮都会让您远离当前的Application Context，这是一个链接。
当用户与控件交互时，Context（Capital C Context !!!）将发生显着变化这一事实是非常重要的信息。
TalkBack无法识别链接很多，因此，对于这一非常重要的信息，如果您发现TalkBack没有共享此信息，请继续将“，链接”附加到此元素的内容描述中。这是我发现的这个规则的唯一例外，但相信这是一个很好的例外。原因是，是的它确实为其他辅助技术添加了一两个违规行为，但它传达了足够重要的信息来证明这样做。您无法使用Android Accessibility API创建合理复杂用户界面的WCAG 2.0兼容应用程序。他们有太多的限制，如果没有“黑客攻击”，你根本无法完成所有你需要做的事情。所以，我们有时必须做出判断。