RE: link in new window debate

Uhmm... how about this thing called CSS?  Separate function/information from
display...

Re: AT detecting.  Most "generalized" AT applications operate at the OS
level.  JAWS (and I believe Window Eyes) use Internet Explorer for web
access, even Homepage Reader uses the IE rendering agent.  How would you
detect somebody using a braille output device?  Then there is the whole
mobility impairment side... how exactly do you propose "testing" for
somebody using "sip and puff" tools, or voice recognition software? (I know
of a quadriplegic who exclusively uses Dragon Dictate/Dragon Naturally
Speaking).

Nope, Universal Accessibility should not depend on alternate streams...
you're heading into a mess of tangled pages when you go down that road...

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   1.866.932.4878 (North America)


> >
> I totally agree that both AT user and others should receive the same
> information.  But that does not mean I can't present that information in
> two different interfaces. An AT detector would be great for this
> purpose. There is no reason why I can not present my information to you
> in an all text format, with text navigation etc, if you are using a
> screen reader, and present it in a graphic rich format if you are a
> person who prefers a visual display.
>
> I'm not talking browser detector BTW. We never browser detect, but AT
> detecting could be very useful, for applying preference settings for
> example. See the IMS ACCLIP specifications, or the preset accessibility
> settings in ATutor, for example .  Same information, different interface
> element depending on how the reader prefers information to be presented.
>
>
> greg
>
>
>
>

Received on Tuesday, 18 November 2003 15:34:09 UTC