Android对讲元素类型公告
Android talkback element type announcement
我正在努力使我的应用程序更易于访问。我很难找到有用的东西，因为没有很多文档（至少我找不到）。
在我的应用中，Talkback 不会宣布 ImageView 的元素类型。我基本上想要的是让 Talkback 宣布我的 ImageView 的 contentDescription 并跟进“，Image”。
此 link 声明“许多无障碍服务，例如 TalkBack 和 BrailleBack，会在宣布其标签后自动宣布元素的类型，因此您不应在标签中包含元素类型。例如，"submit" 是一个很好的 Button 对象标签，但 "submitButton" 不是一个好的标签。”但它没有指定宣布哪些元素类型，哪些不宣布。
https://developer.android.com/guide/topics/ui/accessibility/apps.html
- 有人知道 Talkback 是否在 ImageView 的 contentDescription 之后宣布 "Image" 吗？
- Talkback 何时将 link 宣布为 "Link"？还是开发者有责任将其添加到 contentDescription 的末尾？我可以将对讲作为 "Link" 宣布可点击的文本吗？
任何 help/information/pointers 非常感谢。提前致谢。
A：不要在内容描述的末尾添加东西。这是一种可访问性违规，几乎在所有情况下都会让事情变得更难访问（稍后会解释更多）。
B：很多上下文信息是通过耳标（哔哔声、哔哔声等）传达给 TalkBack 用户的，您可能只是没有注意到。
C: 是的，这令人困惑且难以确定，没有图像未公布，但我认为这是有充分理由的。例如，带有点击监听器的图像可能只是一个花哨的按钮。在 iOS 中，您可以为此更改一些特征，Android 省略了这个非常有用的功能，因此我们陷入了奇怪的解决方法。理想的解决方案是让可访问性 API 允许开发人员传达此信息。
至于 links，通常会在文本视图中宣布内联 links（基本上任何 android 都会自动检测和下划线），但除此之外不会。所以，在实践中，很多 link 都被遗漏了。
现在，至于什么时候您 should/should 不自己提供此信息。如果不确定，就不要这样做，您将通过遵循上述准则获得相当高的可访问性。事实上，下面的任何考虑实际上只是在对抗 Android OS 限制，并且是他们的问题！但是，Android Accessibility Ecosystem 非常薄弱，想要提供更高级别的Accessibility，无可厚非，但是，很难！在您的尝试中，您实际上最终可能会与自己作对。让我解释一下：
在可访问性中，提供信息和一致性之间存在界限。通过将上下文信息添加到内容描述中，您正在沿着这条线前进。如果 Google 说 "We're not going to share contextual information, add it yourself!".
怎么办
你会在不同的音乐播放应用程序的音乐播放器中有这样的按钮，这些按钮在 TalkBack 中宣布：
App1："Play, Button"
应用程序 2："Play, Actionable"
App3："Play, Clickable"
我们在这里有一致性吗？现在是最后一个例子！
App4："Play, Double Tap to click if you're on TalkBack, Hit enter if you're a keyboard user, use your select key for SwitchAccess users....."
请注意 App4 的播放按钮有多复杂，这说明 TalkBack 使用的信息不仅仅是用于 TALKBACK。来自您应用程序的辅助功能信息被大量辅助功能服务使用。当您 "Hack" 将上下文信息添加到内容描述中时，对于 TalkBack 用户来说肯定听起来更好，但是您对 Braille Back 用户做了什么？给 SwitchAccess 用户？通常，元素的内容描述应该描述该元素，并为 TalkBack 留下上下文信息 calculate/users 以确定与其他控件的给定接近度。
回答您的两个特定问题（图片和链接）：
我对图片的推荐是在内容描述中，让你清楚地知道你描述的是图片。
假设您有一张小猫的照片。
差：一只小猫，图片
好：一张小猫的照片。
看这里，如果 TalkBack 未能将其宣布为图像（它会这样做），用户仍然会认为这是一张图片。您已经以一种实际上更好地描述了控件的方式将上下文信息添加到内容描述中。这实际上是最容易获得的解决方案！去图吧。
链接：
对于 links 这有点棘手。关于什么构成 link 与按钮，Accessibility 中有一场激烈的辩论。在网络浏览器的世界里，这是一场很好的辩论。然而，在原生移动端我认为我们有一个非常明确的定义：
任何激活后会带您离开当前 Application Context 的按钮都是 link。
当用户与控件交互时上下文（大写 C 上下文！！！）将发生显着变化这一事实是非常重要的信息。
TalkBack 无法识别 links 很多，因此，对于这条非常重要的信息，如果您发现 TalkBack 不共享此信息，请继续并附加 ", link" 添加到您对该元素的内容描述中。这是我发现的这条规则的唯一例外，但相信这是一个很好的例外。原因是，是的，它确实为其他辅助技术增加了一两个违规行为，但它传达了足够重要的信息来证明这样做是合理的。您不能使用 Android 辅助功能 API 创建合理复杂用户界面的符合 WCAG 2.0 的应用程序。它们有太多限制，如果没有 "hacks"，您根本无法完成所需的一切。因此，有时我们必须做出判断。
我正在努力使我的应用程序更易于访问。我很难找到有用的东西，因为没有很多文档（至少我找不到）。
在我的应用中，Talkback 不会宣布 ImageView 的元素类型。我基本上想要的是让 Talkback 宣布我的 ImageView 的 contentDescription 并跟进“，Image”。
此 link 声明“许多无障碍服务，例如 TalkBack 和 BrailleBack，会在宣布其标签后自动宣布元素的类型，因此您不应在标签中包含元素类型。例如，"submit" 是一个很好的 Button 对象标签，但 "submitButton" 不是一个好的标签。”但它没有指定宣布哪些元素类型，哪些不宣布。 https://developer.android.com/guide/topics/ui/accessibility/apps.html
- 有人知道 Talkback 是否在 ImageView 的 contentDescription 之后宣布 "Image" 吗？
- Talkback 何时将 link 宣布为 "Link"？还是开发者有责任将其添加到 contentDescription 的末尾？我可以将对讲作为 "Link" 宣布可点击的文本吗？
任何 help/information/pointers 非常感谢。提前致谢。
A：不要在内容描述的末尾添加东西。这是一种可访问性违规，几乎在所有情况下都会让事情变得更难访问（稍后会解释更多）。
B：很多上下文信息是通过耳标（哔哔声、哔哔声等）传达给 TalkBack 用户的，您可能只是没有注意到。
C: 是的，这令人困惑且难以确定，没有图像未公布，但我认为这是有充分理由的。例如，带有点击监听器的图像可能只是一个花哨的按钮。在 iOS 中，您可以为此更改一些特征，Android 省略了这个非常有用的功能，因此我们陷入了奇怪的解决方法。理想的解决方案是让可访问性 API 允许开发人员传达此信息。
至于 links，通常会在文本视图中宣布内联 links（基本上任何 android 都会自动检测和下划线），但除此之外不会。所以，在实践中，很多 link 都被遗漏了。
现在，至于什么时候您 should/should 不自己提供此信息。如果不确定，就不要这样做，您将通过遵循上述准则获得相当高的可访问性。事实上，下面的任何考虑实际上只是在对抗 Android OS 限制，并且是他们的问题！但是，Android Accessibility Ecosystem 非常薄弱，想要提供更高级别的Accessibility，无可厚非，但是，很难！在您的尝试中，您实际上最终可能会与自己作对。让我解释一下：
在可访问性中，提供信息和一致性之间存在界限。通过将上下文信息添加到内容描述中，您正在沿着这条线前进。如果 Google 说 "We're not going to share contextual information, add it yourself!".
怎么办你会在不同的音乐播放应用程序的音乐播放器中有这样的按钮，这些按钮在 TalkBack 中宣布：
App1："Play, Button"
应用程序 2："Play, Actionable"
App3："Play, Clickable"
我们在这里有一致性吗？现在是最后一个例子！
App4："Play, Double Tap to click if you're on TalkBack, Hit enter if you're a keyboard user, use your select key for SwitchAccess users....."
请注意 App4 的播放按钮有多复杂，这说明 TalkBack 使用的信息不仅仅是用于 TALKBACK。来自您应用程序的辅助功能信息被大量辅助功能服务使用。当您 "Hack" 将上下文信息添加到内容描述中时，对于 TalkBack 用户来说肯定听起来更好，但是您对 Braille Back 用户做了什么？给 SwitchAccess 用户？通常，元素的内容描述应该描述该元素，并为 TalkBack 留下上下文信息 calculate/users 以确定与其他控件的给定接近度。
回答您的两个特定问题（图片和链接）：
我对图片的推荐是在内容描述中，让你清楚地知道你描述的是图片。
假设您有一张小猫的照片。
差：一只小猫，图片
好：一张小猫的照片。
看这里，如果 TalkBack 未能将其宣布为图像（它会这样做），用户仍然会认为这是一张图片。您已经以一种实际上更好地描述了控件的方式将上下文信息添加到内容描述中。这实际上是最容易获得的解决方案！去图吧。
链接：
对于 links 这有点棘手。关于什么构成 link 与按钮，Accessibility 中有一场激烈的辩论。在网络浏览器的世界里，这是一场很好的辩论。然而，在原生移动端我认为我们有一个非常明确的定义：
任何激活后会带您离开当前 Application Context 的按钮都是 link。
当用户与控件交互时上下文（大写 C 上下文！！！）将发生显着变化这一事实是非常重要的信息。
TalkBack 无法识别 links 很多，因此，对于这条非常重要的信息，如果您发现 TalkBack 不共享此信息，请继续并附加 ", link" 添加到您对该元素的内容描述中。这是我发现的这条规则的唯一例外，但相信这是一个很好的例外。原因是，是的，它确实为其他辅助技术增加了一两个违规行为，但它传达了足够重要的信息来证明这样做是合理的。您不能使用 Android 辅助功能 API 创建合理复杂用户界面的符合 WCAG 2.0 的应用程序。它们有太多限制，如果没有 "hacks"，您根本无法完成所需的一切。因此，有时我们必须做出判断。