无障碍与大小写：为什么全大写（ALL CAPS）更难读
只有两个单词的标签用全大写没问题，再长一点就不是好选择了。大段大写字母读起来更慢，还会丢掉正常大小写所携带的信息（“US”指的是美国还是“us”？）；而且屏幕阅读器大多会忽略大小写，于是你想表达的强调消失了，偶尔某个短词反而被逐个字母念出来。无障碍的做法是用正常大小写书写文本，设计上确实需要大写的地方，再用 CSS 来实现，不过即便这样也并非万无一失。
为什么大段全大写更难读
近一个世纪以来，研究人员一直在比较全大写和小写文本的阅读效果。Kevin Larson 为 Microsoft 撰写的文章 “The Science of Word Recognition”（《单词识别的科学》）汇总了最早可追溯到 1938 年 Woodworth 的研究：读者读完小写段落的速度，比读同一段落的大写版本快 5% 到 10%。
流行的解释是“词形”：小写单词因为有上伸部和下伸部而轮廓各异，大写字母却把每个单词都变成一个长方形。Larson 认为证据并不支持这种说法。我们是通过字母来认出单词的，小写之所以胜出，主要是因为我们平时读得多。被要求大量阅读大写文本的人，读大写的速度也会变快。
这个纠正很有价值，但救不了你网站上那一整段大写。你的读者并没有经过那样的练习，而代价最重地落在本来就觉得阅读吃力的人身上。MDN 关于 text-transform 的页面提醒，大段的大写文本 “may be difficult for people with cognitive concerns such as Dyslexia to read”（对有阅读障碍等认知困难的人来说可能难以阅读）。GOV.UK 风格指南则直接用例子说明这一点：“DO NOT USE BLOCK CAPITALS FOR LARGE AMOUNTS OF TEXT AS IT'S QUITE HARD TO READ.”（不要用大写字母书写大量文本，因为相当难读。）
大写会丢掉信息
大小写混排不只是装饰。一个大写字母会告诉你，这个词是名字、缩写，还是句子的开头。读一读下面这句英文，留意你得猜多少东西：
PLEASE CONTACT US ABOUT POLISH ORDERS IN MARCH. NASA SAYS HI.US 是美国，还是“我们”？POLISH 是波兰的客户，还是家具上光剂？MARCH 是三月，还是游行？文本一旦被输入成大写，软件也找不回答案。把这一行放进我们的大小写转换器，选择句首大写（Sentence case），得到的是 “Please contact us about polish orders in march. Nasa says hi.” 它把所有字母变成小写，再把每个句子的开头大写，这已经是它能知道的全部。名字只能手动改回来。
屏幕阅读器如何处理全大写文本
大多数时候，什么也不做。屏幕阅读器只念出单词，不会提到大小写。2022 年，无障碍顾问 Adrian Roselli 在默认设置下，用 JAWS、NVDA、Narrator、Orca、VoiceOver 和 TalkBack 测试了全大写的法律文本，没有一个会告诉听者这段文字是大写的。NVDA 的音调变化或 “say cap” 之类的选项，是为逐个字符浏览文本设计的，而不是为朗读整句话设计的。
这会带来两个后果：
- 用大写表达的含义会丢失。如果你靠大写来表示“这很重要”（一条警告、一项合同条款、一个喊出来的词），听者听到的只是普通文字。盲文读者是例外，因为盲文有大写符号。
- 有些短词会被逐个字母念出来。语音引擎会猜测一串大写字母是不是缩写。Roselli 指出，“AM”“ADD”和“IT”这几个词在大写时经常被屏幕阅读器逐字母拼读；也有从业者反映，“CONTACT US”被念成了“contact U.S.”。
哪些词会被拼读，取决于屏幕阅读器、语音、用户的设置，有时还取决于浏览器，而且会随版本变化。你没法可靠地预测，这正是一开始就别把重要的词写成大写的最好理由。
不要用空格假装字母间距
字母间距很宽的大写字母是一种很受欢迎的设计手法，而把它们输入成 S A L E 是实现这种效果最糟糕的办法。屏幕阅读器会把每个字母单独念出来，WCAG 也把 “using white space characters to control spacing within a word”（用空白字符控制单词内部的间距）列为失败做法（技术 F32）。请像下面的例子那样使用 CSS 的 letter-spacing。
用 CSS 的 text-transform: uppercase，而不是直接输入大写
如果按钮、标签页或小标题需要显示为大写，就用正常大小写书写，让 CSS 改变它的外观：
<button class="caps">Add to basket</button>
.caps {
text-transform: uppercase;
letter-spacing: 0.06em; /* capitals need a little extra room */
}HTML 里的文本仍然是 “Add to basket”，这能带来几个好处：
- 改版成本低。以后想去掉大写，只需改一行 CSS，不用翻遍每个标签和翻译文件。
- 文本到哪儿都不走样。在订阅源、导出文件以及样式表管不到的其他地方，单词都保持正确的大小写。
- 各语言的规则由浏览器处理。浏览器会根据
lang属性应用语言规则。MDN 的 text-transform 参考文档列出了这些规则：例如，希腊语元音在全大写时会去掉重音符号，土耳其语则把i和İ配成一对。用 CSS 时，存储的希腊语文本仍保留重音；直接输入大写则会永久丢掉重音。
不过也别把它说得太完美。浏览器可能会把转换后的文本交给辅助技术。一份2016 年提交的 WebKit 缺陷报告至今仍未关闭，其中描述了 VoiceOver 把通过样式显示为大写的 “Add to Cart” 按钮念成 “A D D to cart”，也有开发者反映在 Chrome 中使用 VoiceOver 时遇到同样的情况。而且对视力正常的读者来说，CSS 生成的大写依然是大写，大段大写的阅读代价并不会因此改变。把 text-transform 当作给少数几个词加上大写的正确方式，而不是把整段文字设成大写的许可。
什么时候可以用大写，其他情况用什么代替
大写并没有被禁止。WCAG 没有任何反对大写的成功标准，简短的大写也几乎不会造成麻烦。我们会把大写留给以下情况：
- 真正的缩写词和首字母缩略词，例如 NASA、HTML 和 BBC。
- 简短的标签、标签页，以及标题上方那一行小小的“眉题”（eyebrow）。我们的经验法则是不超过三个词，并且用 CSS 实现。
- 像 “New” 这样单独一个词的徽标，前提是不需要让听者把它当成特别的词听出来。
其他情况，就选择那些换了样式或被朗读出来也不会失效的做法：
- 强调：使用
<strong>，再用字重或字号来设置样式。大多数屏幕阅读器默认也不会播报粗体，所以要把重点放进文字本身：“此操作无法撤销”比任何格式都更能说明问题。 - 警告：一个简短直白的标题（“删除账户将移除你的所有文件”）就能完成那一大段大写想做的事，而且会被念出来。
- 法律文本：美国的合同常把担保免责声明设为大写，因为《统一商法典》（Uniform Commercial Code）要求这类条款必须 “conspicuous”（醒目）。但它的定义并不要求在文件正文中使用大写：更大的字号，与周围形成对比的字体、字形或颜色，或者能把这段文字区分出来的标记，同样符合要求。修改条款之前，请先和负责起草的人确认，但大写并不是唯一的办法。
Unicode 花式“小型大写字母”根本不是大写
我们的Unicode 花式文本生成器有一种“小型大写字母”（small caps）样式，有必要坦白说明它生成的到底是什么。输入 “Sale on now”，得到的是 “sᴀʟᴇ ᴏɴ ɴᴏᴡ”。这些并不是缩小绘制的字母，而是另外一些字符，大多借自音标字母表。有些字母没有小型大写版本，所以 “s” 仍是普通的小写 s，而 “q” 会变成 “ǫ”，也就是带反尾形符（ogonek）的 o。
对软件来说，这些都是毫不相干的符号，所以拼写检查器往往会把它们标出来，搜索普通单词时也可能找不到它们。屏幕阅读器对这类形似字符的处理很不一致；在对类似的“假粗体”字母做测试时，有些屏幕阅读器把这些单词完全跳过了。我们的为屏幕阅读器写作指南详细介绍了那次测试。这些样式只适合放在普通文本旁边做点缀，绝不要用在别人需要听到的文字上。
大写字母速查清单
- 用正常大小写输入文本，再用
text-transform应用大写。 - 大写只用于少数几个词，绝不用于整段。
- 给大写字母加一点
letter-spacing，绝不要用空格代替。 - 把含义放进文字里，而不是放进格式里。
- 上线前，用 VoiceOver 和 NVDA 听一听关键按钮和标签。
- 凡是重要的内容，都不要使用 Unicode 形似字母。
关于写作中真正适合使用大写的地方，从缩写到法律文件的标题，请参阅我们的何时使用大写指南。
