开发者常问：CSS在读屏器上会变成什么样？一些与视觉效果强相关的属性，比如color、border、font、margin、padding，对于读屏器来说是完全透明不可见的。但与内容相关的属性呢，比如::before和::after？那些传达了一定含义的属性呢，比如list-style、line-through？再然后影响内容定位以及内容可见性的属性呢，比如clip、position、display、overflow、height、width、visibility等等？现在大家都知道用CSS来生成内容是一种不好的做法，但就跟不应该在高速路上超速一样，有时还是明知故犯。
本文来自John Northup的Screen Readers and CSS: Are We Going Out of Style (and into Content)?，其中的术语、代码请以原文为准。
今年早些时候，我跟三个同事测试并记录了一些广泛使用的CSS属性在读屏器默认配置下的情况。我们把最终结果呈现给了AccessU 2017，接下来我们还会再增加一些新内容然后分享到Accessing Higher Ground。
除了我自己，参与这次测试的还有来自Deque的CB Averitt、Steve Sawczyn以及Birkir Gunnarsson。我们测试了以下这些读屏器和浏览器的组合：
- JAWS/IE 11
- JAWS/Chrome
- JAWS/Firefox
- NVDA/Firefox
- NVDA/Chrome
- VoiceOver/Safari
- VoiceOver/Mobile Safari
- Talkback/Mobile Chrome
重点
不同读屏器和浏览器的组合，产生的行为不同
如果你做了X，读屏器都一样会产生Y——这样的断言令人反感。有时候事情就是这样简单，但在非常多的情况下，不一定是这样，例如：
- 在我们测试的众多组合里，
counter属性出现了三种不同的行为（CSS中的counter属性是一个由CSS控制的“变量”，它可以被CSS的规则递增，用来跟踪这些规则生效的次数） - 使用
vertical-align: super来表示美元和美分时，有一半的组合是没毛病的，但有另一半会把$12<sup>99</sup>（“99”应该是在右上角而不是和“12”一个高度）显示成$1,299 - 对一个HTML段落使用
transation来渐变到opacity:0; visibility:hidden，在8组设备中我们记录到了5种不太一样的行为
DOM顺序最重要
我们发现的其中一个共同点是，无论CSS当中如何进行定位，读屏器中内容的顺序只和DOM的顺序有关。比如说，在<body>结束之前增加一个<div>，然后将这个div的CSS设置为position: absolute，让它跑到整个文档的最顶端。但是这样并不会影响读屏器中内容的顺序——这个div的内容仍然会是在最后。（在这种情况下我们确实可以说读屏器都一样）
这个情况在float身上也是一样的。给一个元素使用float:right通常会把这个元素弄到其他元素的“后面”（其实是右边），这就让元素在视觉上的位置和文档中的实际位置相反。但由于DOM顺序才是决定读屏器中内容顺序的唯一根据，读屏器的效果就和视觉效果相反。（这个和tab键的行为一致，tab键的切换顺序同样以DOM顺序为准）
容器只影响视觉效果
很多CSS属性是针对于容器的尺寸的，比如height、width、max-height、max-width、clip。而overflow、text-overflow则是用来控制容器中文本超出容器边界时的行为。在我们测试的设备组合中，这些全都对设备没有影响。无论内容如何在视觉上被切割，或是因为overflow:hidden而被盖住，读屏器都会完整地将容器中的内容读出。哪怕使用opacity: 0，读屏器依然会毫无保留地将内容读出。
给我们的启发
这一切说明了重视可访问性在开发和测试中是多么重要：无论浏览器以及读屏器如何组合，都要让用户享受一致的体验。
更多内容
以上只是我们研究成果中的一个简介。如果想要了解更多细节，请关注我们2017年11月17日在Accessing Higher Ground的演讲，或是通过john@webaim.org来联系。
