问VoiceOver大写的小单词被理解为缩写。

EN

我建议开发人员避免试图在这种情况下控制屏幕阅读器。一些原因：

• 屏幕阅读器用户(通常)非常习惯这样的怪癖，并且会理解诸如"add“之类的常用单词。对于那些整天使用屏幕阅读器的人来说，对于开发人员(和QA测试人员)来说，什么似乎是一个大问题，实际上可能只是一个小问题。较长或不常见的单词在大写中可能更有问题，但没有门槛。
• 它在不同的屏幕读取器中有所不同，并且可能是由哪个声音(或文本到语音引擎)使用的。大写的单词可以在一个屏幕读取器中拼写出来，然后由另一个屏幕读取器作为一个单词来宣布。对于大多数开发人员来说，这实在是太麻烦了。
• 一些屏幕阅读器使用大写的不同方法，例如宣布“帽”或改变音高。
• 一些屏幕阅读器提供这些用户设置。在我看来，这是开发人员避免微观管理屏幕阅读器体验的主要原因--我们可能无意中妨碍了用户的首选项。
• 随着语音引擎和辅助技术的发展，所有这些都可能随着未来的发展而改变。试图控制今天的公告可能会在几年后干扰辅助技术能力。WCAG准则4.1声明：“最大限度地兼容当前的和未来的用户代理，包括辅助技术”。我的理解是，这意味着在短期内尝试微观管理这样的小怪癖是不值得的。

这里的一些答案建议使用CSS text-transform: uppercase。这是一种很好的方法，但在不同的屏幕阅读器之间也有不一致之处。在理想的世界中，原始文本和文本转换都可以传递给辅助技术，为语音引擎提供更好的信息，同时也尊重用户的喜好。我们还没有到那里，但浏览器实现者正在讨论这个问题--请参阅Chromium跟踪器中的讨论，以获得更多的细节：尊重a11y树中的文本转换样式？

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

关于所有大写的讨论(在一个Drupal问题中)有一些有趣的贡献来自屏幕阅读器用户：核心主题中全大写文本的可读性问题。

将标记保留为小写，但使用CSS仅通过text-transform将文本更改为大写。

然后添加一个aria-label of "add money"。

​

h1 {
  text-transform: uppercase;
}

<h1 aria-label="add money">add money</h1>

​