[whatwg] [HTML5] Accessibility question
Benjamin Hawkes-Lewis
bhawkeslewis at googlemail.com
Tue Apr 1 01:14:19 PDT 2008
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
More information about the whatwg
mailing list