寻找 iOS VoiceOver 辅助功能指南：当我点击文本时，它应该说多少？

Posted 2023-02-24

【中文标题】寻找 iOS VoiceOver 辅助功能指南：当我点击文本时，它应该说多少？

【英文标题】：Looking for iOS VoiceOver accessibility guidelines: when I tap on text, how much should it speak?

【发布时间】：2018-06-20 15:34:26

【问题描述】：

我正在寻找任何具体指南（来自 Apple 或其他地方，而不是意见），当我在我正在开发的应用程序中点击某些文本时，我应该让 VoiceOver 阅读多少文本。

当我点击一个标题时，它应该只读取标题，还是也应该读取该标题下方的部分？当我点击一个段落时，它是否应该阅读标题，然后是包含该段落的整个部分？在什么情况下，语音文本应该提供比应用实际显示更多或不同的信息？

（我不是在问它做什么，我是在问它应该做什么，因为作为开发人员，我可以将项目的accessibilityLabel 设置为我想要多少文字都可以。）

我在https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/iPhoneAccessibility/Making_Application_Accessible/Making_Application_Accessible.html#//apple_ref/doc/uid/TP40008785-CH102-SW5 中看不到任何相关内容。

【参考方案1】：

您的链接似乎很清楚，尤其是Supply Accurate and Helpful Attribute Information 上的部分，其中包括以下详细信息：

确定标签应该传达什么的一个好方法是考虑一个有视力的用户仅通过查看它就可以推断出您的应用程序。如果你设计了一个好的用户界面，有视力的用户应该通过阅读其标题或理解其图标来了解控件或视图在当前应用程序上下文中的作用。这是您需要在标签属性中向 VoiceOver 用户提供的信息。

如果您提供自定义控件或视图，或者如果您在标准控件或视图中显示自定义图标，则需要提供一个标签：

非常简要地描述了元素。理想情况下，标签由单个单词组成，例如 Add、Play、Delete、Search、Favorites 或 Volume。 努力设计您的应用程序，以便一个单词可以识别一个元素并使其在当前上下文中的用法显而易见。但是，有时可能需要使用简短的短语来正确识别元​​素。在这种情况下，请创建一个非常简短的短语，例如“播放音乐”、“添加名称”或“添加到活动”。 不包括控件或视图的类型。类型信息包含在元素的特征属性中，不应在标签中重复。 例如，如果您在添加按钮的标签中包含控件类型，VoiceOver 用户每次访问该控件时都会听到“添加按钮按钮”。这种体验很快就会变得烦人，并可能促使用户停止使用您的应用程序。 以大写单词开头。这有助于 VoiceOver 以适当的变形方式阅读标签。 不以句点结尾。标签不是句子，因此不应以句点结尾。 已本地化。确保通过本地化所有字符串（包括可访问性属性字符串）使您的应用程序可用于尽可能广泛的受众。一般来说，VoiceOver 会使用用户在国际设置中指定的语言。

每个可点击视图都应提供自己的accessibilityLabel。如果用户可以点击标题并且用户可以点击标题下方的部分，那么点击标题应该只是阅读标题，点击标题下面的部分应该只是阅读标题下面的部分。

【讨论】：

好吧，很公平——我想那部分清楚地说，可访问性应该是逐个元素的，而不是在语义上将元素组合在一起。换句话说 - 这里没有说“你应该将多个元素组合在一起作为一个可访问性元素”。不过，我希望我能找到一些明确规定不要将多个元素组合在一起的指导方针，否则它仍然只是一种观点与另一种观点。

@BrianKendig：在我看来，除了文档中的 a11y 信息之外，使用 VoiceOver 的 a11y 的最佳指南是您。只需打开设备上的“幕布”功能：您会发现同理心和常识是要添加到您的技术知识中的基本原则。当然，所有这些都将迅速提高您的应用程序的质量。 ;o)

【参考方案2】：

当您考虑可访问性时，您应该从最终用户的角度来处理它。例如，如果您有一个标题为Hospital Name: 的标题和一个子标题为Massachusetts General Hospital，则最好将两者一起阅读，因为它们为彼此提供了上下文。另一方面，如果您有一个标题为 Hospitals: 的标题，然后您在下面有一个很长的医院列表，那么让用户按照自己的节奏滚动浏览所有医院可能会更好。

对于较大的文本块，例如 UILabel 或 UITextView 上的段落，您再次阅读的数量取决于上下文。如果它是对某些内容的描述，应该将其作为一个完整的块来阅读，以便用户可以理解内容，那么将其设置为单个 Voice Over 块是完全可以的。但是，如果应该有策略性的停顿让用户决定他或她是否想听更多（例如最终用户许可协议、文章中的段落），那么您应该将其分成几个部分以允许用户控制步调并选择位置。

对于较大的文本块，我建议您不要将accessibilityLabel 设置为内容，而是设置accessibilityValue。这将允许用户在决定他/她是否想听到更多信息之前，在可访问性焦点中听到对象标签中的简短描述。同样，这会在继续之前提供用户上下文。

【参考方案3】：

您正在开发原生应用程序而不是 html webapp？在后一种情况下，用户可以向左/向右滑动以导航到 DOM 中的下一个元素，并且只读取与该 DOM 元素关联的文本。但是，如果认为有必要帮助 VoiceOver，则可以通过将附加文本与 DOM 元素（aria-label、aria-labelledby、aria-describedby、class="sr-only" 等）关联来“增强”与 DOM 元素关联的文本用户了解上下文。例如，“立即注册”按钮或“阅读更多”链接可能需要附加信息，以便明确按钮/链接的用途。 （现在注册什么？阅读更多关于什么？）

同样的原则也可以应用于原生应用，这听起来就像您要问的那样。如果您的应用程序有一个标题（ala <h1>、<h2> 等，但它是在 Objectivec 中定义的），那么那些不应该需要与它们关联的额外文本。标题的措辞应使其上下文足够。用户向右滑动可以导航到标题后面的段落。他们会知道该段落在标题“下方”，因为这是他们滑动到的下一个元素。

如果用户点击段落，则相同。与段落相关的标题不需要阅读。用户可以向左滑动以到达它，或者他们可以使用“标题”上设置的转子向上/向下滑动以到达上一个/下一个标题。

因此，一般准则是尽可能在对象本身的文本中提供所需的所有上下文。但你也必须用简洁来平衡这一点。如果文本需要额外的上下文，那么听起来您应该使用accessibilityLabel。是否有另一个属性提供附加信息，例如可访问性描述？ （我刚刚编了这个属性名。不确定它是否存在。）

【讨论】：

是的，这是一个原生应用。你的意见是有效的，我同意你的看法，但这只是一种意见，我团队中的一些人反对它，他们认为与段落相关的标题需要阅读。我正在寻找已发布的可访问性指南，这些指南在这里提供了一些先例。

我想这是一种观点，但它基于该领域十多年来与视障用户的合作。可访问性的官方指南是 WCAG (w3.org/WAI/standards-guidelines/wcag)，但他们不会具体告诉您您的情况。这个决定是由多年的经验做出的，我希望反对你观点的人有（但我不同意他们的评价）。他们发布的评估指南是什么？应用中的每个元素都应该有自己的文本，而不是读取其邻居的文本。