屏幕阅读器会关注 CSS 吗？
屏幕阅读器是否只阅读内容而不关注 CSS？
我问这个问题的原因是我想将 LESS.js 用于我的一些 CSS（所以不是全部）。就我而言，禁用 JS 的用户无论如何都会获得基本的体验，因此他们不会错过我的一些演示 CSS。
然而，屏幕阅读器呢……他们会错过我通过 Javascript 提供的额外 CSS 吗？
PS 请不要提供编译器建议，我不感兴趣 - 它们会减慢我的工作流程。
谢谢
Do screen readers just read content without paying attention to CSS?
My reason for asking is that I would like to use LESS.js for some of my CSS (so not all of it). As far as I'm concerned, users with JS disabled will get a basic experience anyway so they won't miss some of my presentational CSS.
However, what about Screen Readers... will they miss my extra CSS that's served via Javascript?
P.S. no compiler suggestions please, I'm not interested - they slow down my workflow.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这里要理解的最重要的问题是屏幕阅读器不是浏览器：它是一个可以通过语音、盲文、某种组合或两者的组合（甚至可能是其他方式）读出其他应用程序 UI 的应用程序。
阅读网页时，屏幕阅读器实际上并不加载或解析 HTML 或 CSS：浏览器会执行此操作，屏幕阅读器通常会通过直接访问底层 DOM 来读取浏览器显示的内容（例如，在使用 IE 的 Win32 上） ，通过各种 IHTML* 接口）或通过与辅助功能相关的 API。
（请注意，这意味着支持可能会根据屏幕阅读器和浏览器组合的不同而有所不同；JAWS 可以在 IE 或 Firefox 上工作，但目前不能在 Chrome、Opera 或 Safari 上工作；并且在某些情况下，实际上在 IE 和 Firefox 上读取的内容可能有所不同。）
通常这意味着屏幕阅读器会忽略大多数 CSS - 他们几乎忽略大多数格式和布局并专注于内容；但所有现代屏幕阅读器至少都会考虑显示：和可见性：，因此它们不会读出视力正常的用户看不到的内容。例如，屏幕阅读器不想读出“折叠”文本 - 直到适合这样做为止。这里的关键问题是这两个 CSS 属性实际上具有语义含义，因此屏幕阅读器传达这一点很重要。
由于屏幕阅读器通常从 DOM（直接或间接）获取这些值，因此它们是通过内联样式、外部样式表还是在运行时通过 javascript 设置并不重要。
--
关于听觉样式表的快速说明：现在，它们与屏幕阅读器场景根本不相关。
首先，存在的问题是屏幕阅读器用户可能一开始就没有使用语音输出。
其次，大多数屏幕阅读器用户将其声音设置为非常特定的声音 - 通常是用户可以在高速下很好地理解的中性声音 - 然后他们会将速度提高到大多数人不会的速度完全能够理解。屏幕阅读器用户最不想看到的就是某些页面开始覆盖他们的语音设置。
这使得屏幕阅读器的体验与基于语音的 UI（听觉表可能更合适）有着根本的不同。 UI实际上仍然是基于显示的；它只是恰好被用户以间接的方式访问；这种间接的方式可能是通过言语、盲文或某种组合。但您不必关心这一点，只要您的页面首先有良好的语义标记即可。
The most important issue to understand here is that a screenreader is not a browser: it is an app that reads out the UI of other apps, either via speech, braille, some combination or the two - or possibly even some other means.
When reading the web, the screenreader doesn't actually load or parse HTML or CSS: the browser does that, and the screenreader reads out what gets displayed by the browser, typically by either accessing the underlying DOM directly (eg. on Win32 with IE, via the various IHTML* interfaces) or via an accessibility-related API.
(Note that this means that support can vary depending on the screenreader and browser combination; JAWS can work against IE or Firefox, but not currently Chrome, Opera or Safari; and might in some cases actually read things out differently against IE vs Firefox.)
Usually this means that screenreaders ignore most CSS - they pretty much ignore most formatting and layout and concentrate on content; but all modern screenreaders do take at least display: and visibility: into account, so they will not read out content that a sighted user would not see. For example, a screenreader would not want to read out "collapsed" text - until it was appropriate to do so. The key issue here is that these two CSS attributes actually have semantic meaning, so it's important for the screenreaders to convey that.
Since the screenreaders get these values typically from the DOM (either directly or indirectly), it doesn't matter whether they were set via inline styles, an external stylesheet, or at runtime via javascript.
--
A quick note on aural stylesheets: right now, they are simply not relevant at all to the screenreader scenario.
First, there's the issue that a screenreader user might not be using speech output in the first place.
Secondly, most screenreader users have their voice set to a very specific voice - typically a neutral one that the user can understand well at high speeds - and then they'll pump up the speed to a very fast speed that most folks won't be able to understand at all. The last thing a screenreader user wants is for some page to start overriding their voice settings.
This makes the screenreader experience fundamentally different from a speech-based UI (where an aural sheet might be appropriate). The UI is really still display-based; it just happens to be accessed by the user in an indirect manner; and that indirection might be via speech, or braille, or some combination. But you shouldn't have to care about that, so long as you have good semantic markup in your page in the first place.
当弄清楚如何阅读 CSS 样式的文本。
They're supposed to take cues from the CSS properties defined in the voice module when figuring out how read CSS styled text.
是和不是。屏幕阅读器需要解析 CSS 才能知道是否阅读某个项目。屏幕阅读器不会读取带有
display: none的项目，但是还有其他方法可以隐藏只能通过屏幕阅读器观察到的内容。我强烈建议下载 JAWS 或 Window Eyes 的开发副本，并对您的网站进行实际可用性测试。
Yes and no. CSS needs to be parsed for the screen reader to know whether or not to read an item. Items with
display: nonewont get read by a screen reader, however there are still other means of hiding content that can only be observed with a screen reader.I highly recommend downloading a development copy of JAWS or Window Eyes and performing an actual usability test of your site.