Javascript 屏幕阅读器注意CSS吗？

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

我问这个问题的原因是我想对我的一些CSS使用更少的.js（所以不是全部）。就我而言，禁用JS的用户将获得基本的体验，这样他们就不会错过我的一些演示CSS

但是，屏幕阅读器呢。。。他们会错过我通过Javascript提供的额外CSS吗

另外，请不要对编译器提出建议，我不感兴趣-它们会减慢我的工作流程

---

谢谢

是和否。需要对CSS进行解析，屏幕阅读器才能知道是否要读取某个项目。显示有

的项目：无

不会被屏幕阅读器读取，但是还有其他隐藏内容的方法，只有屏幕阅读器才能看到

---

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

在了解如何读取CSS样式的文本时，他们应该从中定义的CSS属性中获取线索

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

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

内容创建者可以通过link元素的media属性指定“speech”媒体类型，或使用@media at规则，或在@import语句中，有条件地包括专用于具有文本到语音合成功能的用户代理的CSS属性。执行此操作时，不支持此模块的用户代理将忽略在此类条件语句范围内编写的样式

---

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

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

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

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

因为屏幕阅读器通常从DOM（直接或间接）获取这些值，所以不管它们是通过内联样式、外部样式表还是在运行时通过javascript设置的

--

关于听觉样式表的简要说明：目前，它们与屏幕阅读器场景根本不相关

首先，有一个问题，屏幕阅读器用户可能不会首先使用语音输出

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

---

这使得屏幕阅读器的体验与基于语音的用户界面（可能适合使用听力表）有着根本的不同。用户界面仍然是基于显示的；它只是碰巧被用户以间接的方式访问；这种间接的方式可能是通过言语，盲文，或者某种组合。但是你不必在意这些，只要你的页面首先有好的语义标记。

我想这取决于什么样的CSS。如果只是圆边和渐变，你可能不必担心，如果你正在做类似于{code>div:before{content:“这是最好的时代，这是最好的时代，yada yada aydaa”}而读者不解析css，那么这将是“一个没有城市的故事”相反，我想不出任何现有的屏幕阅读器能够理解甚至是听觉样式表。。。即使是JAWS也不行。关于标准化BoltClock中的听觉风格，这里的问题是screenreader实际上不是一个用户代理/浏览器；它只是在读什么