是否有可能为iPhone构建与VoiceOver相同的工作方式的辅助应用程序?(使用UIAccessibility API) -澄清一下，我们想建立一个屏幕阅读器在相同的静脉VoiceOver。或者，VoiceOver是唯一允许在iOS设备上工作的辅助技术吗?
是的，你可以在自己的应用程序中构建自己的屏幕阅读器技术。
你应该包括你自己的语音合成库，比如CMU FLite，它可能听起来不如VoiceOver，并子类化或添加类别到你想要支持你的私人辅助行为的所有应用程序的UI和文本对象。
在iOS App store中，有少数会说话的应用程序在某些应用程序的视图中做一些有限的自定义语音辅助，而不需要打开VoiceOver。(广告:my Talking Tuner就是一个例子。)
你的辅助技术只能在你自己的应用程序中工作，并且不能像Siri和VoiceOver那样与物理按钮或任何其他应用程序进行交互。
VoiceOver是目前iOS上唯一的辅助技术应用，我怀疑苹果会保持这种状态。让屏幕阅读器成为整个包的一部分，而不是允许第三方应用程序，有很多好处，包括:
-
根据定义，屏幕阅读器需要能够访问其他应用程序的UI和内容。这里有一大堆安全和隐私问题。虽然有一些方法可以减轻这种情况-例如。Android需要在控制面板上明确地给予辅助技术许可——如果不需要，为什么还要去那里呢?
-
VoiceOver所做的一些事情——比如拦截触摸——可能需要特殊的系统支持;这不是你通常希望允许任何应用做的事情。从某种意义上说，屏幕阅读器是一种特殊的应用程序，如果屏幕阅读器需要来自操作系统的特殊支持，那么管理这些情况要容易得多，如果这些支持都是内部的，而不是需要通过某些API扩展到第三方，并且API需要以某种方式防止滥用(见上文)，并且API必须在未来的操作系统版本中记录和支持。
-
拥有一个屏幕阅读器意味着只有一个应用程序可以测试可访问性。这个极大地简化了开发人员的工作。在iOS上，用VoiceOver测试，你就完成了。相比之下，在Windows上，你可能还得针对JAWS、NVDA和windoweyes进行测试。其中一些应用程序做了其他应用程序不做的事情，所以你的应用程序可能需要解决其中一个或另一个。
-
将屏幕阅读器作为软件包的一部分也意味着它可以使用OS发布的新功能。苹果可以保证从第一天起就可以使用新的iOS功能。要通过第三方辅助软件做到这一点，他们必须让第三方参与新的操作系统功能，这对于像苹果这样行事隐秘的公司来说是不太可能的。
不幸的是，VoiceOver是目前唯一允许的辅助技术。如果你需要使用VoiceOver，这很容易;您所要做的就是为您希望用户识别的每个项目添加这行代码:
[myView setIsAccessibilityElement:YES];
[myView setAccessibilityTraits:UIAccessibilityTraitImage];
[myView setAccessibilityLabel:NSLocalizedString(@"Image of dog", nil)];