屏幕阅读器是否关注CSS？

Question

屏幕阅读器只读取内容而不关注CSS吗？

我提出这个问题是因为我想在一些CSS中使用LESS.js（所以不是全部）。就我所知，禁用JS的用户将获得基本体验，因此他们不会错过一些我的呈现CSS。

然而，屏幕阅读器怎么样呢...它们会忽略通过Javascript提供的额外CSS吗？

P.S.请勿提供编译器建议，我不感兴趣-它们会减缓我的工作流程。

谢谢

- SparrwHawk

---

取决于CSS的类型，我猜。如果只是圆角和渐变，你可能不用担心。 - Pekka

如果你正在做类似于 div:before { content: "It was the best of times, it was the best of times yada yada yada aydaa " } 这样的事情，而读者无法解析 CSS，则它将变成“没有城市的故事”而不是“双城记”。 - Marc B

我想不出任何现有的屏幕阅读器能够理解声音样式表，甚至包括JAWS在内都不行。所以说，在CSS2.1中标准化声音样式表就是这样了。 - BoltClock

http://www.456bereastreet.com/archive/201111/screen_readers_and_css/ - Norman B. Robins0n

@BoltClock：这里的问题在于屏幕阅读器实际上不是一个用户代理/浏览器；它只是朗读底层浏览器所做的事情，而浏览器是为屏幕渲染而设计的。真正基于语音的浏览器可能会使用声音样式表，但目前没有现有的屏幕阅读器遵循这种模式。 - BrendanMcK

Answer 1

理解这里最重要的问题是，屏幕阅读器不是浏览器：它是一款应用程序，通过语音、盲文或两者的组合或其他可能的方式阅读其他应用程序的用户界面。

在阅读网页时，屏幕阅读器实际上并不加载或解析HTML或CSS：浏览器会执行这些操作，而屏幕阅读器会读出浏览器显示的内容，通常通过直接访问底层DOM（例如，在Win32上使用IE时，通过各种IHTML*接口）或通过辅助功能相关API来实现。

（请注意，这意味着支持取决于屏幕阅读器和浏览器的组合；JAWS可以针对IE或Firefox工作，但目前无法与Chrome、Opera或Safari配合使用；在某些情况下，甚至可能会根据IE与Firefox而有所不同。）

通常，这意味着屏幕阅读器忽略大多数CSS - 它们几乎忽略大多数格式和布局，并集中于内容；但是，所有现代屏幕阅读器都会考虑至少display:和visibility:，因此它们不会朗读被视觉用户看不到的内容。例如，屏幕阅读器不希望朗读“折叠”的文本-直到适当的时候为止。关键问题在于这两个CSS属性实际上具有语义含义，因此对于屏幕阅读器来传达这一点非常重要。

由于屏幕阅读器通常从DOM（直接或间接地）获取这些值，因此无论是通过内联样式、外部样式表还是通过JavaScript在运行时设置，都没有关系。

关于声音样式表的一个快速说明：现在，它们对屏幕阅读器场景根本不相关。

首先，屏幕阅读器用户可能根本不使用语音输出。

其次，大多数屏幕阅读器用户将其声音设置为非常特定的声音-通常是中性的，用户可以以高速度理解-然后他们会将速度提高到大多数人根本无法理解的非常快的速度。屏幕阅读器用户最不希望的是某些页面开始覆盖他们的语音设置。

这使得屏幕阅读器体验与基于语音的UI根本不同（其中声音样式表可能是合适的）。 UI实际上仍然是基于显示的；它只是以间接的方式被用户访问；并且该间接方式可能是通过语音、盲文或某种组合。但是，只要您的页面具有良好的语义标记，您就不必关心这一点。

- BrendanMcK

Answer 2

是的和不是。CSS需要被解析，以便屏幕阅读器知道是否读取一个项目。具有display: none的项目将不会被屏幕阅读器读取，但仍然有其他隐藏内容的方法，只能通过屏幕阅读器观察到。

我强烈建议下载JAWS或Window Eyes的开发副本，并对您的网站进行实际的可用性测试。

- zzzzBov

---

同时建议使用NVDA作为屏幕阅读器进行测试；它是免费且开源的，并且越来越受欢迎。JAWS大约需要800美元左右，虽然每个专业设计公司都应该有一份可供他们的开发人员/设计师进行测试，但NVDA是进行非正式测试的好选择。 - BrendanMcK

我还建议使用NVDA进行屏幕阅读器测试，但请注意JAWS的工作方式不同；它具有许多额外的功能和脚本，以提供NVDA可能没有的访问权限；屏幕阅读器的目的是“欺骗”，并尽可能为最终用户提供访问权限，即使在网页本身未正确编码的情况下也可以工作。这是我们的程序避免使用辅助技术进行508部分检查的原因，而是依赖于诸如Web Accessibility Toolbars（可视化检查DOM）之类的工具。如果编码正确，它应该可以工作。 - Norman B. Robins0n

Answer 3

在阅读 CSS 样式化文本时，它们应该从 语音模块 中定义的 CSS 属性中获取线索。

文档的听觉呈现结合了语音合成（也称为“TTS”，即“文本到语音”）和音频图标（在本规范中我们称之为“音频提示”）。信息的听觉呈现在盲人或视觉障碍用户社群中很常见，例如，“屏幕阅读器”使得原本无法访问的视觉用户界面能够被控制。还有其他情况需要听取文本信息而不是阅读它，典型的例子包括在汽车中使用电子书阅读器、工业和医疗文档系统、家庭娱乐、帮助用户学习阅读或支持阅读困难的用户（印刷残障者）。

当涉及到文档时，语音表达的质量取决于内容本身所撰写的结构和语义。CSS语音模块提供属性，使作者能够声明性地控制听觉维度的呈现方面（例如TTS语音、音高、速率和音量级别）。这些样式表属性可以与视觉属性（混合媒体）一起使用，也可以作为视觉演示的完整听觉替代品。

内容创建者可以有条件地包含专门用于具有文本到语音合成功能的用户代理的CSS属性，方法是通过链接元素的媒体属性指定“speech”媒体类型，或使用@media at-rule或在@import语句内部。这样做时，这些有条件语句范围内的样式将被不支持此模块的用户代理忽略。

- Mike Samuel

---

似乎普遍的看法是，在我的JS中使用一般的CSS是可以的。如果我需要特别使用CSS语音模块，我会将其放在我的主样式表中（我怀疑听觉方面的东西不会太复杂，以至于我需要使用LESS）。 - SparrwHawk

-1，因为根据当前屏幕阅读器的工作方式，CSS voice 对于屏幕阅读器今天的工作方式并不相关。 屏幕阅读器根本不是浏览器或用户代理程序； 相反，它们会朗读浏览器执行的内容，通常会访问浏览器DOM中的内容（直接或通过可访问性API），因此，它们朗读的内容是针对显示而呈现/设置的内容，而不是针对语音的。 最后，屏幕阅读器甚至可能根本不是基于语音的，而是使用盲文向用户输出。 - BrendanMcK

@BrendanMck，我不知道你从哪里得到我说屏幕阅读器是浏览器的想法。我只是引用了CSS 3，其中定义为““屏幕阅读器”使得原本无法访问的视觉用户界面可控制。”至于其他方面，是的，屏幕阅读器不一定是声音的，在所有操作系统上都有良好的开源浏览器之前，它们受限于插件框架提供的内容，这可能会限制计算样式到媒体组视觉，但这不是屏幕阅读器的固有限制，上述CSS模块明确表明了意图。 - Mike Samuel

@MikeSamuel - 我指的是“专门用于具有文本到语音合成功能的用户代理的CSS属性”。不管怎样，这只是一个小问题；真正的问题在于，目前没有任何主流屏幕阅读器使用声音样式表；因此，虽然您的答案在未来的某个时候可能会有用，但它并没有回答OP关于该技术如何在今天运作的问题。 - BrendanMcK

@BrendanMcK，明白了。感谢您的解释。作为一个数据点，Aural CSS在末尾有一张表格，列出了Opera 9支持的相当多的内容，Firevox对少数内容有部分支持，而GW Micro没有计划支持声音CSS。 - Mike Samuel