Re: Proposal for modifying checkpoint 4.17 (Issue 405)

Responses in JRG:
At 11:57 AM 12/13/2000 -0500, Al Gilman wrote:
>[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.

JRG: This issue of discrimination of selection and focus was raised during 
last call: Issue #405
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#405

In terms of priority the colors or other attributes that over lap would 
give priority for final rendering to focus.  If people decide to use the 
same values for focus and selection, that is there choice and the priority 
will not make any difference.

> >
> >I have a counter-proposal. First, some observations and resolutions:
> >
> > 1) Merge 4.16 and 4.17 since now more closely related.
> >

JRG: It really doesn't make a difference to me if they are together or 
separate.  Just so it is clear what the requirements are.

> > 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.

JRG: I only require this in the default configuration.  People can still do 
as they please or the user agent may decide that is a good feature, but I 
did not think I was requiring for every configuration.


> >  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.

JRG: What I was trying to say, but not very well apparently, is that the 
focus values should override selection values if there is ever a situation 
that the two would apply to the same element.  There would not be a need 
for "mixing" the two values into a new value.

<NEW_JON>
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,  strike through, over-line) or border styles are used as a 
highlight mechanism, the user must be able to configure them according to 
the range of text decoration or border styles available on the system.  If 
selection and focus can simultaneously occur on the same element, the focus 
style should be have priority over the selection style for rendering the 
highlight for those elements.
<NEW_JON>

1. I don't think we want to encourage font or font weight as a highlighting 
mechanism, since it encourages dynamic page reformatting and 
disorientation.  Even bolding a character can cause page automatic 
reformatting.  Let's stick with text-decoration (CSS) and border (CSS) as 
the preferred techniques, since they do not cause auto reformatting.

2. Focus style should have priority over selection style.  No mixing, just 
priority.

Jon

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Wednesday, 13 December 2000 13:10:12 UTC