开发者常问:CSS在读屏器上会变成什么样?一些与视觉效果强相关的属性,比如colorborderfontmarginpadding,对于读屏器来说是完全透明不可见的。但与内容相关的属性呢,比如::before::after?那些传达了一定含义的属性呢,比如list-styleline-through?再然后影响内容定位以及内容可见性的属性呢,比如clippositiondisplayoverflowheightwidthvisibility等等?现在大家都知道用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属性是针对于容器的尺寸的,比如heightwidthmax-heightmax-widthclip。而overflowtext-overflow则是用来控制容器中文本超出容器边界时的行为。在我们测试的设备组合中,这些全都对设备没有影响。无论内容如何在视觉上被切割,或是因为overflow:hidden而被盖住,读屏器都会完整地将容器中的内容读出。哪怕使用opacity: 0,读屏器依然会毫无保留地将内容读出。

给我们的启发

这一切说明了重视可访问性在开发和测试中是多么重要:无论浏览器以及读屏器如何组合,都要让用户享受一致的体验。

更多内容

以上只是我们研究成果中的一个简介。如果想要了解更多细节,请关注我们2017年11月17日在Accessing Higher Ground的演讲,或是通过john@webaim.org来联系。

About liuyanghejerry

富有激情的前端工程师,专注GUI开发。

Comments are closed.

Post Navigation