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

Reply via email to