Re: ISSUE-51: distinguished Chrome is not the answer (public comment)

I hate to open up the great Chrome debate again, but Al is right that we 
need to be able to refer to the chrome is a way that is not purely visual. 


I propose changing in section 9:

Chrome is the part of the browser window outside of the area displaying 
the current web page. 

to

Chrome is the representation through which the user interacts with the 
browser itself, as distinct from the web content accessed. In graphical 
layout terms, it is the part of the browser window outside of the area 
displaying the current web page. 

There are also some interesting tidbits in this one for when we're doing 
prototyping (on link representation), so I'll want to keep this (or a 
companion) open even after we agree/decide on this change. 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




Web Security Context Issue Tracker <dean+cgi@w3.org> 
Sent by: public-wsc-wg-request@w3.org
04/17/2007 08:14 AM
Please respond to
Web Security Context WG <public-wsc-wg@w3.org>


To
public-wsc-wg@w3.org
cc

Subject
ISSUE-51: distinguished Chrome is not the answer (public comment)








ISSUE-51: distinguished Chrome is not the answer (public comment)

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

Raised by: Bill Doyle
On product: Note: use cases etc.

>From public comments
raised by: Al Gilman Alfred.S.Gilman@ieee.org

http://lists.w3.org/Archives/Public/public-usable-
authentication/2007Apr/0000.html


distinguished Chrome is not the answer 
where it says, in 9.1 Poorly defined area for chrome
(user should recognize what information is from browser and not page)
must change
The present definition for the chrome is layout-wise.  Change to "the 
representation through which the user interacts with the browser itself, 
as 
distinct from the web content accessed."  Compare with the language in 
UAAG 
1.0, Guideline 1.
please consider
Think again.  You are asking the user to make crisp distinctions where 
they 
don't want to, and we don't want them to need to.  The chrome represents 
functionality that, in the way the user recalls it, doesn't change from 
page 
to page.  What you use frequently, you want to bring from recall memory 
and 
you don't want display capability wasted on tickling your recognition 
memory 
for these things.  The innovations are strongly confined inside the page. 
So 
it's rational for the chrome to be a wallflower.  And it's not just the 
chrome.  The GUI web presents the user with lots of information that they 
ignore.  The only problem is that what they ignore and what they notice 
varies 
from user visit to user visit.  The user doesn't distinguish page content 
that 
doesn't get their attention from chrome that doesn't get their attention 
because, well, frankly, their attention is elsewhere.  So asking them to 
split 
hairs among what they don't care about is a futile approach.
please consider
Review the relationship of sounds to events and ShowSounds to the critical 
job 
of  attention-getting on event.  Different modality mixes have working BCP 

solutions to this problem and they are different, based on the modality 
mix.
Why? 
audio is more atomic than is graphics; it's harder to be out of earshot 
than 
to be out of the visual focus.  On the other hand, it's not always 
available.
please consider
Design the event information (filtering, compression to friendly terse 
gestures) on the basis of a VoiceXML dialog.  Then abstract to SCXML for 
flexi-
modal presentation.
Why?
You will note that screen readers say 'link' when a hyperlink is 
encountered. 
That is to say, some of the dialog-situation information that is conveyed 
with 
(status) presentation properties (color, underline) in the GUI 
presentation is 
spelled out, articulated in language on-transition events, for the audio 
presentation.  Designing for a voice dialog, and backing all messages with 
at 
least a "say it in a sentence" [if longer] backup will improve your 
coverage 
of events the user needs to understand, and can be pruned for the default 
GUI 
presentation.  Spelling out both a status and an events view of the 
process 
will both improve the quality of your work and make repurposing the the 
presentation go better.
please consider
I want to return to the matter of High Contrast mode.  The reason you are 
going to have trouble seeking a remedy within the confines of present Web 
technology is illustrated by the similarity between two functions that are 

attempting to make the browse experience user-centric and accountable to 
the 
user's interest: security and accessibility.  The Web technology of today 
is 
characterized by the CSS cascade rule that local rules trump global rules. 
 
This is effective in making point and click operation efficient/easy, but 
not 
stable/secure/accessible.  What we are up against is a re-factorization of 
the 
user-web engagement into aspects, where there needs to be better support 
for 
the stability of the security aspect (and the presentation-adaptation 
aspect, 
as well).  For the purposes of information integrity assurance, we can't 
let 
the local escape from global discipline.  But that's a change from the 
techbase.  With the ascendancy of Web Applications (rapidly rising market 
share w.r.t. installed) you can't just retreat into "what the browser 
should 
do."  There has to be a rationalized and enforced continuity between what 
happens in OS, [AT], browser,[plugin], webApp layers.