Android对讲元素类型公告

我正在努力使我的应用程序更容易访问。我很难找到有用的东西，因为没有太多的文档（至少我找不到）

在我的应用程序中，Talkback不会宣布ImageView的元素类型。我基本上想要的是Talkback宣布我对ImageView的内容描述，并在后面加上“Image”

此链接指出“许多辅助功能服务，如TalkBack和BrailleBack，在宣布元素的标签后自动宣布其类型，因此您不应在标签中包含元素类型。例如，“submit”是按钮对象的良好标签，但“submitButton”不是良好标签。”但它并没有指定它宣布和不宣布的元素类型。

有人知道Talkback在ImageView的contentDescription之后是否会宣布“Image”吗

对讲何时宣布链接为“链接”？还是开发者有责任在contentDescription的末尾添加它？我可以将对讲公告可点击文本作为“链接”吗

---

非常感谢您的帮助/信息/指点。提前谢谢。

A：不要在内容描述的末尾添加内容。这是一种易访问性冲突，在几乎所有情况下都会使事情变得不易访问（稍后将详细解释）

B：很多上下文信息都是通过耳机（BIP、嘟嘟声等）传达给对讲用户的，你可能根本没有注意到

C:是的，这很令人困惑，也很难确定，没有图像没有公布，尽管我认为这是有充分理由的。例如，带有单击侦听器的图像可能只是一个花哨样式的按钮。在iOS中，有一些特性需要你改变，Android已经忽略了这个非常有用的特性，所以我们不得不采取一些奇怪的解决办法。理想的解决方案是让可访问性API允许开发人员交流这些信息

至于链接，通常文本视图中的内联链接会被公布（基本上是android自动检测到并加下划线的内容），但在其他方面则不会。因此，在实践中，很多环节都被遗漏了

现在，至于你什么时候应该/不应该自己提供这些信息。如果不确定，就不要这样做，通过遵循上述指南，您将获得相当高的可访问性级别。事实上，下面的任何一个考虑因素都只是在与Android操作系统的局限性作斗争，这是他们的问题！然而，Android易访问性生态系统非常薄弱，如果你想提供更高级别的易访问性，这是可以理解的，但是，很难！在你的尝试中，你最终可能与自己作对。让我解释一下：

在可访问性方面，在提供信息和一致性之间存在一条界线。通过向内容描述中添加上下文信息，您正在沿着这条线前进。如果谷歌说“我们不会共享上下文信息，你自己添加吧！”

您可以在音乐播放器中的不同音乐播放应用程序中使用按钮，这些应用程序在对讲中宣布如下内容：

附件1：“播放，按钮”

附录2：“游戏，可操作”

附件3：“播放，可点击”

我们这里有一致性吗？现在是最后一个例子

App4：“播放，如果您正在对讲，请双击以单击，如果您是键盘用户，请按enter，对于SwitchAccess用户，请使用选择键…”

注意App4的播放按钮是多么复杂，这说明了对讲使用的信息不仅仅是对讲。您应用程序中的辅助功能信息由多个辅助功能服务使用。当你将上下文信息“黑客”到内容描述上时，当然对于对讲用户来说可能听起来更好，但是你对盲文回复用户做了什么呢？访问用户？一般来说，元素的内容描述应该描述该元素，并为对讲留下上下文信息，以便计算/用户确定给定的与其他控件的接近程度

要回答您的两个特定问题（图像和链接）：

我对图像的建议是在内容描述中，使您描述的内容明显是图像

假设你有一张小猫的照片

坏：小猫，形象

好：一张小猫的照片

请看这里，如果TalkBack未能将其作为图像发布（它将这样做），用户仍然会认为这是一张图片。您已将上下文信息添加到内容描述中，这种方式实际上更好地描述了控件。这实际上是最容易获得的解决方案！算了吧

链接：

对于链接，这有点棘手。在可访问性方面，关于链接和按钮的构成有很大的争论。在网络浏览器领域，这是一场很好的辩论。然而，在native mobile中，我认为我们有一个非常明确的定义：

当激活时，将您从当前的

应用程序上下文中移除的任何按钮都是一个链接

当用户与控件交互时，上下文（大写C Context！！！）将发生显著变化这一事实是非常重要的信息

TalkBack无法识别很多链接，因此，对于这条非常重要的信息，如果您发现TalkBack没有共享此信息，请继续并在您的内容描述中为该元素添加“link”。这是我发现的唯一例外，但我相信这是一个很好的例外。原因是，是的，它确实增加了一个或两个违反其他辅助技术，但它传达了足够重要的信息，证明这样做是正当的。您无法使用Android可访问性API创建具有合理复杂用户界面的WCAG 2.0兼容应用程序。它们有太多的局限性，如果没有“黑客”的帮助，你不可能做所有你需要做的事情。因此，我们有时不得不作出判断