答：不要在内容描述的末尾添加内容。这是一种可访问性违规，几乎在所有情况下都会使事情变得不那么可访问（稍后将详细解释）。
B：很多上下文信息是通过耳标（bip、哔声等）传达给 TalkBack 用户的，您可能没有注意到。
C：是的，这是令人困惑且难以确定的，没有图像不公布，尽管我认为这是有充分理由的。例如，带有点击监听器的图像可能只是一个花哨的按钮。在 iOS 中，您可以为此更改一些特性，而 Android 省略了这个非常有用的功能，因此我们遇到了一些奇怪的解决方法。理想的解决方案是让可访问性 API 允许开发人员传达此信息。
对于链接，通常会宣布文本视图中的内联链接（基本上任何 android 会自动检测到并加下划线），否则不会。所以，实际上很多链接都被遗漏了。
现在，至于您何时应该/不应该自己提供这些信息。如果不确定，请不要这样做，您将通过遵循上述指南获得相当高的可访问性。事实上，下面的任何考虑都只是与 Android 操作系统的限制作斗争，并且是他们的问题！但是，Android 无障碍生态系统非常薄弱，如果要提供更高级别的无障碍，可以理解，但是，很难！在您的尝试中，您实际上可能最终会与自己作对。让我解释一下：
在可访问性中，提供信息和一致性之间存在界限。通过将上下文信息添加到内容描述中，您将沿着这条路线前进。如果 Google 说“我们不会共享上下文信息，请自行添加！”会怎样。
您将在不同音乐播放应用的音乐播放器中拥有按钮，这些按钮在 TalkBack 中宣布如下：
App1：“播放，按钮”
App2：“播放，可操作”
App3：“播放，可点击”
我们在这里有一致性吗？现在是最后一个例子！
App4：“播放，如果您使用 TalkBack，请双击以单击，如果您是键盘用户，请按 Enter，对于 SwitchAccess 用户，请使用您的选择键.....”
注意 App4 的播放按钮有多么复杂，这说明 TalkBack 使用的信息不仅仅是用于 TALKBACK。来自您应用的无障碍信息被众多无障碍服务所使用。当您将上下文信息“破解”到内容描述中时，肯定对 TalkBack 用户来说听起来更好，但是您对盲文返回用户做了什么？ SwitchAccess 用户？一般来说，元素的内容描述应该描述元素，并留下上下文信息以供 TalkBack 计算/用户确定与其他控件的给定接近度。
回答您的两个特殊问题（图片和链接）：
我对图片的建议是在内容描述中让您清楚地表明您描述的内容是图片。
假设您有一张小猫的照片。
坏：一只小猫，图片
好：一张小猫的照片。
请参阅此处，如果 TalkBack 未能将其宣布为图像（它会），用户仍然会认为这是一张图片。您以一种实际上更好地描述了控件的方式将上下文信息添加到内容描述中。这实际上是最容易获得的解决方案！去图吧。
链接：
对于链接，这有点棘手。关于什么是链接与按钮的构成，可访问性存在很大的争论。在网络浏览器世界中，这是一个很好的辩论。但是，在原生移动端我想我们有一个非常明确的定义：
任何在激活时将您带离当前Application Context 的按钮都是一个链接。
当用户与控件交互时，上下文（大写 C 上下文！！！）将发生显着变化这一事实是非常重要的信息。
TalkBack 无法识别很多链接，因此，对于这条非常重要的信息，如果您发现 TalkBack 未共享此信息，请继续在您的内容描述中附加“, link”这个元素。这是我发现的这条规则的唯一例外，但相信这是一个很好的例外。原因是，是的，它确实为其他辅助技术增加了一两个违规行为，但它传达了足够重要的信息来证明这样做是合理的。您不能使用 Android Accessibility API 创建一个合理复杂的用户界面的 WCAG 2.0 兼容应用程序。它们有太多的限制，如果没有“hacks”，你根本无法做所有你需要做的事情来实现这一点。所以，我们有时必须做出判断。