[whatwg] [HTML5] Accessibility question
contact at nickshanks.com
Tue Apr 1 03:07:13 PDT 2008
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).
> "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
>> 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
>> 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
> See also one slice of the complicated story at:
> "Does JAWS support cascading style sheets (CSS)?"
Besides my opinion that JAWS is probably the worst example of an
accessibility program that exists, it is far from being just a screen
— Nicholas Shanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2427 bytes
Desc: not available
More information about the whatwg