屏幕阅读器是否关注CSS？

Question

屏幕阅读器是否只是在不关注CSS的情况下阅读内容？

我的理由是我想将LESS.js用于我的一些CSS（所以不是全部）。对于我而言，禁用JS的用户无论如何都将获得基本体验，因此他们不会错过我的一些演示CSS。

然而，屏幕阅读器......他们会错过我通过Javascript提供的额外CSS吗？

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

由于

Answer 1

这里要理解的最重要的问题是屏幕阅读器不是浏览器：它是一个应用程序，可以通过语音，盲文，某种组合或两者来读取其他应用程序的用户界面 - 或者甚至可能是其他方式

在阅读网页时，屏幕阅读器实际上并没有加载或解析HTML或CSS：浏览器会这样做，并且屏幕阅读器会读取浏览器显示的内容，通常是直接访问底层DOM（例如， Win32与IE，通过各种IHTML *接口）或通过与可访问性相关的API。

（请注意，这意味着支持可能因屏幕阅读器和浏览器组合而异; JAWS可以针对IE或Firefox，但目前不适用于Chrome，Opera或Safari;在某些情况下，实际上可能会针对IE vs以不同的方式读取内容Firefox。）

通常这意味着屏幕阅读器会忽略大多数CSS - 它们几乎忽略了大多数格式和布局并专注于内容;但是所有的现代屏幕阅读器都至少要考虑显示：和可见性：因此他们不会读出有视力的用户看不到的内容。例如，屏幕阅读器不希望读出“折叠”文本 - 直到它适合这样做。这里的关键问题是这两个CSS属性实际上具有语义含义，因此屏幕阅读器传达这一点非常重要。

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

-

关于听觉样式表的快速说明：现在，它们与屏幕阅读器场景完全无关。

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

其次，大多数屏幕阅读器用户将其语音设置为非常特定的语音 - 通常是用户可以高速理解的中性语音 - 然后他们将速度提高到大多数人赢得的非常快的速度根本不能理解。屏幕阅读器用户想要的最后一件事是让某些页面开始覆盖他们的语音设置。

这使得屏幕阅读器体验与基于语音的UI（听觉表​​可能适合）有根本的不同。 UI实际上仍然是基于显示的;它恰好被用户以间接方式访问;间接可能是通过言语，盲文或某种组合。但是，只要您首先在页面中有良好的语义标记，就不必关心它。

Answer 2

是和否。需要为屏幕阅读器解析CSS以了解是否阅读项目。 display: none的项目不会被屏幕阅读器读取，但是还有其他隐藏内容的方法只能通过屏幕阅读器观察到。

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

Answer 3

当弄清楚如何读取CSS样式文本时，他们应该从voice module中定义的CSS属性中获取提示。

  

文档的听觉呈现结合了语音合成（也称为“TTS”，“文本到语音”的首字母缩写）和听觉图标（在本说明书中我们称为“音频线索”）。在盲人或视力受损的用户群体中，信息的听觉呈现是常见的。例如，“屏幕阅读器”能够控制可能无法访问的可视用户界面。在其他情况下，听取文本信息（而不是阅读文本信息）是必要的。典型的例子包括电子书阅读器的车载使用，工业和医疗文件系统，家庭娱乐，帮助用户学习阅读，或支持有阅读困难（阅读障碍）的用户。

     

说到文档，语音再现的质量取决于内容本身内部的结构和语义。 CSS语音模块提供的属性使作者能够以声明方式控制听觉维度的表示方面（例如TTS语音，音调，速率和音量水平）。这些样式表属性可以与视觉属性（混合媒体）一起使用，或者作为视觉演示的完整听觉替代。

     

内容创建者可以有条件地包含专用于具有文本到语音合成功能的用户代理的CSS属性，通过链接元素的媒体属性或@media at-rule指定“语音”媒体类型，或者一个@import语句。执行此操作时，不支持此模块的用户代理会忽略在此类条件语句范围内创作的样式。