On 1 Apr 2008, at 10:14 am, Benjamin Hawkes-Lewis wrote:
Nicholas Shanks wrote:
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.
Well i would disagree: that's the job of an accessibility suite for the blind. A screen reader is just one component of such a suite.
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).
Am at work and haven't time to read these at the moment. Will do so this evening.
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. :)
Then I would call such software a "screen reader + braille renderer + hacks around in your OS program doing nasty things" program. I don't think a pure screen reader should know anything about CSS or DOM or an application's internals.
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
Besides my opinion that JAWS is probably the worst example of an accessibility program that exists, it is far from being just a screen reader.
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
