W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2000

Re: Proposal for modifying checkpoint 4.17 (Issue 405)

From: Al Gilman <asgilman@iamdigex.net>
Date: Wed, 13 Dec 2000 11:57:40 -0500
Message-Id: <Version.32.20001212222340.04128f00@pop.iamdigex.net>
Message-Id: <Version.32.20001212222340.04128f00@pop.iamdigex.net>
To: Ian Jacobs <ij@w3.org>, Jon Gunderson <jongund@ux1.cso.uiuc.edu>
Cc: w3c-wai-ua@w3.org
[Warning:  I am not taking a position on which proposal is better.  But I had
to get my two cents' worth in on some aspects of this area of the guidelines. 
Details at AG::]

At 02:12 PM 2000-12-12 -0500, Ian Jacobs wrote:
>Jon Gunderson wrote:
>> 
>> Sorry.  I just added the new part about focus and selection.  This would be
>> the proposal for all the changes:
>> 
>> <NEW1>
>> 4.17 Allow the user to configure how the content focus is highlighted
>> (e.g., foreground and background color, voice pitch, etc.). For graphical
>> viewports, offer at least three rendering options, including colors and
>> text decoration (underline, overline and line-through). For graphical
>> viewports, allow the user to select from among the range of system colors.
>> The default focus highlight mechanism must be different from the default
>> selection highlight mechanism. If an element can simultaneously be part of
>> a selection and have focus, the focus styling should have priority over the
>> selection styling when rendering the element. [Priority 1]
>> </NEW1>

AG::

What is the origin of that last sentence?

What if the focus styling and the selection styling are easily combined?

Maybe it is true that it is more important to know that you are in the focus
than that you are in the selection.   But in the natural course of events
it is
ususally easy to apply both effects at once to communicate focus+selection as
the state of some of the content.  As a matter of general usability (and PWD
usability in particular), I would not want the 'priority' of focus over
selection to be invoked unless there were a real problem with applying both
effects at once.  

>
>I have a counter-proposal. First, some observations and resolutions:
>
> 1) Merge 4.16 and 4.17 since now more closely related.
>
> 2) From Issue 353 resolution:
>   
<http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-353>http://www.w3.o
rg/WAI/UA/2000/11/minutes-20001116#issue-353
>
>    a) The default highlighting mechanisms required by the document
>    (for selection, focus, etc.) must not rely on color alone.
>   
>    b) The default highlighting mechanisms .... must differ from each
>    other and not by color alone.
>
> 3) From minutes of 7 Dec teleconf:
>   
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0383.html>http://
lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0383.html
>  
>    a) Remove minimal font requirement.
>    b) However, if fonts used, must be able
>       to configure font characteristics.
>
>Putting it all together:
>
><NEW_IAN>
>   4.17 Allow the user to configure how the content focus and
>   current selection are highlighted 
>   (e.g., through foreground and background color, 
>   voice pitch, etc.). The default highlight styles must not
>   rely on color alone. The default focus and
>   selection styles must also differ from each other, and not
>   through color alone. If text decorations (e.g., underlining,
>   bold, etc.) or font styles are used as a highlight
>   mechanism, the user must be able to configure them 
>   according to the range of text decoration or fonts 
>   available on the system.
>
>AND:
>
>   Delete checkpoint 4.16, since incorporated.
></NEW_IAN>
>
>I don't support an additional requirement that the user
>agent guarantee that the selection and focus always
>be distinguishable for the following reason:

AG::

Jon's proposed wording did not introduce any such requirement.  He merely said
that when the two states collide, which one should win in the "virtual
cascade"
of style rules.  But see above.

>
>  1) I don't think that we should have a requirement that
>     the highlight mechanism used for selection and focus
>     necessarily be different (e.g., a box around focus and
>     color for selection, forbidding the use of two different
>     colors.
>  2) Given that, then the user could specify that both
>     are highlighted with colors, and the UA would have to
>     carry out a calculation each time one or the other changed
>     to determine whether there was overlap and provide a specialized
>     presentation for the case of overlap.
>
>  3) By default, we require that the two highlights differ, and not
>     differ by color alone. That means that if the user chooses
>     to configure them to use the same mechanism, then it's the user's
>     problem, not the UA's.
>

AG::

That is very much how I had been thinking about it: that it is too complicated
to save the user from themself if they actively introduce an ambiguity in
styling among these states.  But that the shipping defaults should be well
differentiated.  In a rich enough output medium the best design is to guide
the
user toward using different degrees of freedom so that the respective effects
always combine gracefully.  But the user should ultimately have full
control to
work around their own specific problems.  In doing so they may apply strange
styling in the combined cases.

Al

> - Ian
>
>-- 
>Ian Jacobs (jacobs@w3.org)  
<http://www.w3.org/>http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783
>  
Received on Wednesday, 13 December 2000 11:57:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:22 GMT