读屏器与CSS

来源:转载


原文链接:http://webaim.org/blog/screen-readers-and-css/



开发者常问: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
的演讲,或是通过[email protected]
来联系。


分享给朋友:
您可能感兴趣的文章:
随机阅读: