html - VoiceOver 大写的小词被读为缩写

Question

我有以下标题

<h1>ADD MONEY</h1>

它被 VoiceOver 读取为

a-d-d money

而如果我将文本更改为小写，它将正确读取为“加钱”。你有什么建议吗？我已经尝试使用 aria-labelledby没有运气!

Answer 1

我推荐开发者 避免 试图在这种情况下控制屏幕阅读器。一些原因:

屏幕阅读器用户(通常)非常习惯于这样的怪癖，并且会理解拼写出的“添加”等常见词。对于开发人员(和 QA 测试人员)来说，这似乎是一个大问题，但对于整天使用屏幕阅读器的人来说，这实际上可能只是小问题。更长或不常见的单词可能更像是大写字母的问题，但没有阈值。

它因不同的屏幕阅读器而异，并且可能归结为所使用的语音(或文本到语音引擎)。大写的单词可能会在一个屏幕阅读器中拼写出来，并由另一个屏幕阅读器作为单词朗读。大多数开发人员担心的太多了。

一些屏幕阅读器使用不同的大写方法，例如宣布“cap”或改变音调。

一些屏幕阅读器为这些提供了用户设置。在我看来，这是开发人员避免对屏幕阅读器体验进行微观管理的主要原因——我们可能会在不经意间妨碍用户偏好。

随着语音引擎和辅助技术的发展，所有这些都可能在 future 发生变化。试图控制今天的公告可能会在几年后干扰辅助技术功能。 WCAG guideline 4.1声明:“最大化与当前 和 future 用户代理的兼容性，包括辅助技术”(强调我的)。我认为这意味着在短期内尝试微观管理这样的小怪癖是不值得的。

这里的一些答案建议使用 CSS text-transform: uppercase .这是一个很好的方法，但它在不同的屏幕阅读器之间也存在不一致。在理想的世界中，原始文本和文本转换都可以传递给辅助技术，为语音引擎提供更好的信息，并尊重用户的偏好。我们还没有到那里，但浏览器实现者正在讨论它 - 有关更多详细信息，请参阅 Chromium 错误跟踪器中的此讨论: Honouring text-transform styles in the a11y tree?

另一种建议的技术是使用小写 aria-label复制可见文本，但强制浏览器将小写版本传递给辅助技术。例如 <button aria-label="add money">ADD MONEY</button> .这在许多情况下可能非常有效，但它是开发人员如何妨碍用户偏好的一个例子。例如，希望他们的屏幕阅读器改变大写语调的用户将错过这里。屏幕阅读器的主要工作是传达屏幕上的内容，包括大写字母。小写 aria-label在我看来，技术与此不一致。

关于全大写的讨论(在 Drupal CMS 问题中)有一些来自屏幕阅读器用户的有趣贡献:
Readability problem with all-caps text in core themes .