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

I like simple phrases like "secure content", "secure site", "secure
connection"

 

  _____  

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
Behalf Of Mary Ellen Zurko
Sent: Monday, November 05, 2007 10:35 AM
To: public-wsc-wg@w3.org
Subject: ISSUE-115 Mixing of security information and content in non-visual
environments? 

 


[some data from Al Gilman]

** on the product

The technical strategy that I would consider a kneejerk proposal from
the Universal Design / Accessibility quarter is that the 'lock' is an icon
indicating a state (a.k.a. mode) of the dialog.  This state is a concept.
It is represented in different modalities by different 'signs' for the
same 'sense' (in the language of semiotics).

a) write up the conceptual definition of this mode or state in excruciating
detail.

b) Say it in a sentence.

c) Back it up with a representative help paragraph or page.

Maybe you will arrive at a one-word term of art, but here phrases
seem like a more convincing verbalization:

"secure content"
"secure site"
"secure connection"

In response to Thomas's curiosity as to what screen readers say about
the padlock: I don't know, so I asked:

http://lists.w3.org/Archives/Public/w3c-wai-ig/2007OctDec/thread.html#msg26

The quick answer is that screen readers do say something, but the
terminology is part of their own 'skin' and the exact selector that
they are matching may be the https: in the URI and not something
deeper and surer.  It's going to take more than user experience to
check into that depth.
For the latter we will need to follow up with both the AT vendors and
the DOM and/or DCCI folks for a standard way the lock status of the
content is conveyed programmatically in APIs.  If there is not already
a standard interface to this information in the DOM we need to move
post-haste to enshrine it in the Delivery Context Ontology.  Even
'though it is context information that derives from the process that
brought you the DOM content.

Maybe API level standardization already exists and you can teach us.

Back to the UI look and feel -- it seems the audio-only dialog
concept for sharing this information is something spoken on entry to
the page. This means (here comes WebAPI and WAF) that we may need to
re-think the protocol and the presentation in the context of AJAX.