ISSUE-51

distinguished Chrome is not the answer (public comment)

State:

CLOSED

Product:

wsc-usecases

Raised by:

Bill Doyle

Opened on:

2007-04-17

Description:

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.

Related Actions Items:

No related actions

Related emails:

1. RE: ISSUE-51: distinguished Chrome is not the answer (public comment) (from tyler.close@hp.com on 2007-05-21)
2. Re: ISSUE-51: distinguished Chrome is not the answer (public comment) (from tlr@w3.org on 2007-05-21)
3. Re: ISSUE-51: distinguished Chrome is not the answer (public comment) (from Mary_Ellen_Zurko@notesdev.ibm.com on 2007-05-21)
4. Re: ISSUE-51: distinguished Chrome is not the answer (public comment) (from Mary_Ellen_Zurko@notesdev.ibm.com on 2007-05-18)
5. Re: ISSUE-51: distinguished Chrome is not the answer (public comment) (from Mary_Ellen_Zurko@notesdev.ibm.com on 2007-04-19)
6. Re: ISSUE-51: distinguished Chrome is not the answer (public comment) (from hahnt@us.ibm.com on 2007-04-19)
7. ISSUE-51: distinguished Chrome is not the answer (public comment) (from dean+cgi@w3.org on 2007-04-17)

Related notes:

Display change log