- From: Nicholas Shanks <contact@nickshanks.com>
- Date: Tue, 1 Apr 2008 12:07:13 +0200
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. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080401/cbd719aa/attachment.bin>
Received on Tuesday, 1 April 2008 03:07:13 UTC