- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Tue, 01 Apr 2008 09:14:19 +0100
Nicholas Shanks wrote: > On 1 Apr 2008, at 9:00 am, Benjamin Hawkes-Lewis wrote: > >> Hmm ? http://www.w3.org/TR/wai-aria/#hidden seems to be specified as >> equivalent to visibility: hidden, a property that theoretically >> shouldn't affect speech rendering but does (accidentally) hide content >> from screen readers. It doesn't say anything about display: none;. > > > I know that everyone already knows this, but I think a reminder might be > timely: > Be careful not to confuse screen readers, who's job it is to read what > is displayed on the screen, That's something of a simplification; the word "read" in particular is as likely to confuse as to clarify (yes, the name doesn't help here). It's the job of a screen reader to provide people with severe visual impairments with access to a computer system. That regularly entails more than "reading what is displayed on screen", including also things like querying document or application models and constructing further internal models on top of those (for example, to produce a list of links, or extract hidden help text, or construct a text-stream view of a webpage in a virtual buffer). http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_withoutvisinfosheet.hcsp http://en.wikipedia.org/wiki/Screen_reader "A program whose 'job it is to read what is displayed on the screen' " works better as a description of simpler text-to-speech programs (which also exist). > with a voice browser, who's job it is to > parse a HTML document into a DOM tree and apply media-less and aural CSS > (and potentially never display anything on screen). I agree it's important to distinguish screen readers from voice browsers. Two example differences from an end-user perspective: 1. Screen readers typically provide access to an entire system rather than simply being a self-voicing application for browsing the web or an application that happens to include speech output. 2. Screen readers also typically output braille. :) > visibility: hidden and display: none should both hide content from > screen readers. I don't think it's that clear-cut in theory or practice. Screen readers don't map directly to the speech/aural or braille media types. But they don't map directly to the screen media type either. They involve different modes of access, not just a different media type. See also one slice of the complicated story at: "Does JAWS support cascading style sheets (CSS)?" http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=1165 -- Benjamin Hawkes-Lewis
Received on Tuesday, 1 April 2008 01:14:19 UTC