RE: ISSUE-115: Mixing of security information and content in non-visual environments? [Techniques]

agreed

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
Behalf Of michael.mccormick@wellsfargo.com
Sent: Wednesday, October 03, 2007 3:15 PM
To: dan.schutzer@fstc.org; public-wsc-wg@w3.org
Subject: RE: ISSUE-115: Mixing of security information and content in
non-visual environments? [Techniques]


Maybe the speech-enabled agent should use two different voices - one for
metadata (including but not limited to security context) and another for
content. 

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Dan Schutzer
Sent: Wednesday, October 03, 2007 11:01 AM
To: 'Web Security Context Working Group WG'
Subject: RE: ISSUE-115: Mixing of security information and content in
non-visual environments? [Techniques]


I am not expert on how we currently handle non-visual environments, but
one could approach this in a similar manner. For example, when a
visually-impaired user accesses a page which is audio only; the page
could be broken into two pieces. The first piece would be a
heading/preface that cannot be modified by the webservice, provides
security and other chrome info and is spoken by a distinctive voice that
differs from the rest of the spoken web page, the content

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Web Security Context Working Group Issue Tracker
Sent: Wednesday, October 03, 2007 11:48 AM
To: public-wsc-wg@w3.org
Subject: ISSUE-115: Mixing of security information and content in
non-visual environments? [Techniques]



ISSUE-115: Mixing of security information and content in non-visual
environments? [Techniques]

http://www.w3.org/2006/WSC/track/issues/

Raised by: Thomas Roessler
On product: Techniques

We currently have material concerning the mixing of security information
and context in non-visual environments. Is there a useful generalization
of the requirement to non-visual UIs? Are there problematic known cases
similar to the location bar favicon mix known for, e.g., screen readers?

Received on Thursday, 4 October 2007 11:34:06 UTC