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.

Received on Tuesday, 17 April 2007 12:14:49 UTC