W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

Proposed changes to checkpoints related to focus, selection, and current viewport

From: Ian Jacobs <ij@w3.org>
Date: Wed, 07 Mar 2001 19:12:24 -0500
Message-ID: <3AA6CE68.3C6E999D@w3.org>
To: w3c-wai-ua@w3.org
Hello,

I'm trying to implement some of the changes and clarifications
regarding focus and viewports that we discussed at the 1-2 March
face-to-face meeting [1]. I outline the conceptual model 
I'm working from and then propose changes to a few checkpoints
and definitions. I think that most of the proposals in this
section are editorial (with the exception of the change proposed
for checkpoint 7.2).

Reference document: 24 Feb 2001 Draft [2].

[1] http://www.w3.org/WAI/UA/2001/03/ua-minutes
[2] http://www.w3.org/WAI/UA/WD-UAAG10-20010224/

---------
The model
---------

0) Each viewport has four associated state variables: content focus,
   user interface focus, selection, and point of regard.
  
   * The point of regard may be, but is not required to be,
     established by the content focus or the selection. 
 
   * The selection may be empty. I think that the content and
     user interface focus can be empty as well (but I'm not
     sure). The point of regard is probably never empty.

1) At any given moment during the user's session, if N viewports
   are open, only one of 2N content focuses and user interface
   focuses will receive keyboard (or other device) input; this
   one is the current focus. 

   Only one of N selections will receive keyboard (or other
   device) input; this is the current selection.

   I don't think we need to define "current point of regard"
   because we have a requirement to keep a chosen graphical
   viewport on top and the concept isn't useful in the audio
   world.

   There is generally only one pointing device location (which
   directs pointing device events).

2) It is hard to define "current viewport" because in some
   environments, one viewport may house the current focus and
   another may receive pointing device input. This split does not
   generally happen on Windows or Mac systems. But since it could
   happen (even in the Windows environment if you get the right
   software) and I can do this in X Windows.

   It also seems that the "current viewport" is closely bound to
   input devices rather than what the user is currently viewing
   (output). The term might cause confusion as to whether it
   is determined by input or output.

   Note: I doubt there are systems where you could change the
   content focus in one viewport and the selection in
   another. But I don't know for sure.
   
3) For user agents that implement history mechanisms, each entry
   in the history may have distinct values for the four state
   variables (content focus, user interface focus, selection, and
   point of regard). 

4) If there are N viewports open, and each one has M entries
   in its history, there are N times M values available for
   each of the current content focus, user interface focus, 
   and selection. Our requirements deal with changes
   to these state variables and highlighting of these state 
   variables.

Comment: There are other checkpoints related to selection, focus,
and viewports that are not mentioned below because I think they
are unaffected by this discussion.

---------------------------
Proposal 1: Checkpoint 4.15
---------------------------

<OLD 4.15>
  Allow the user to configure whether the current focus
  moves automatically to a viewport that opens without an
  explicit request from the user.
</OLD 4.15>

a) Do not broaden the checkpoint to require additional
   configuration so that the current selection, 
   and pointer do not move automatically to a viewport 
   that opens without an explicit request from the user. I
   actually think that additional configuration not to move
   the pointer around would be a good thing, but I am not
   proposing that change.

b) I don't think that configuration is necessary at all
   if the user agent never moves the current focus 
   automatically.

c) Some editorial changes to simplify the text.

<NEW 4.15>
  Allow configuration so that the current focus does not move
  automatically to viewports that open without explicit user
  request. Configuration is not required if the current
  focus can only ever be moved by explicit user request.
</NEW 4.15>

For the techniques document: 

  * Suggest additional configurability for the other state 
    variables.

---------------------------
Proposal 2: Checkpoint 4.17
---------------------------

<OLD 4.17>
 For graphical user interfaces, allow the user to
 configure the user agent so that the viewport with the current
 focus remains "on top" of all other viewports with which it
 overlaps.
</OLD 4.17>

a) Do not broaden the checkpoint to require additional
   configuration so that the viewport with the 
   current selection or the one designated by
   the pointing device remains on top. What does "on top"
   mean for more than one state variable? (One may offer
   different configs; that could be in the Techniques document.)

b) Editorial simplification

<NEW 4.17>
 For graphical user interfaces, allow configuration
 so that the viewport with the current focus remains "on top" 
 of all other viewports with which it overlaps.
</NEW 4.17>

---------------------------
Proposal 3: Checkpoint 7.1
---------------------------

<OLD 7.1>
 Allow the user to navigate among all viewports (including
 frames). Note: Navigating into a viewport makes it the current
 viewport.
</OLD 7.1>

a) I think that the term "navigation" is unclear (we had some
   of this discussion at the face-to-face). I think that
   instead we should say that each viewport has to be able to 
   have the current focus/selection/pointing device designation. 
   I don't think this broadens the checkpoint since I suspect we
   already meant all of these things.

b) Delete the Note about current viewports (as part of dropping
   the term from the document). This is a change from what
   we decided at the face-to-face meeting.

<NEW 7.1>
 Allow the user to make the selection and focus of each
 viewport the current selection and focus, respectively.
 For interfaces that support a pointing device, allow 
 the user to interact with each viewport using the pointing 
 device.

   Note: Often, a change to one of these variables may
   cause a change to another (e.g., cliking in a viewport with
   the pointing device makes that viewport's focus the current
   focus, and its selection the current selection.
</NEW 7.1>

---------------------------
Proposal 4: Checkpoint 7.2
---------------------------

<OLD 7.2>
 Associate a point of regard with each state in a
 viewport's browsing history and when the user returns to a
 state in the history, restore the associated point of regard.
</OLD 7.2>

a) I think that all four state variables should be restored
when you return to a state in the viewport's history. I think
this is a slight broadening of the checkpoint.

b) Note: We do not require the UA to implement a history
   mechanism. If it is implemented, the UA must do these things.

<NEW 7.2>
 For each state in a viewport's browsing history, associate
 a point of regard, content focus, user interface focus, and
 selection. When the user returns to that state in the history,
 restore all four of these states.
</NEW 7.2>

---------------------------
Proposal 5: Checkpoint 8.7
---------------------------

<OLD 8.7>
 Provide a mechanism for highlighting the current
 viewport. For graphical viewports, the default highlight
 mechanism must not rely on color alone.
</OLD 8.7>

a) Avoid the term "current viewport". I propose
narrowing this checkpoint to the viewport with the current
focus (the same scope as 4.15 and 4.17).

<NEW 8.7>
 Provide a mechanism for highlighting the viewport with the
 current focus. For graphical viewports, the default highlight
 mechanism must not rely on color alone.
</NEW 8.7>

------------------------------------------
Proposal 6: Delete the term "current viewport"
-------------------------------------------

-----------------------
Proposal 7: Definitions of focus, content focus, user
interface focus, current focus
-----------------------

Focus is a user interface mechanism that has the following properties: 

 It designates a location of potential user interaction. In most
 user agents today, the focus is only sensitive to keyboard
 input, but this could be generalized to other input devices. The
 focus is highlighted in the viewport so that it stands out.

 The focus has state (more so than the transient pointing
 device), so the user may use it as a placeholder.  For instance,
 the user may set the focus (through the user interface or
 programmatically), review other content (e.g., by scrolling the
 viewport or otherwise moving the point of regard), and then
 return to the focus having decided to activate the designed
 enabled element.

User agents generally implement two types of focus:

 The "content focus" designates an enabled element. A viewport
 has at most one content focus.
 
 The "user interface focus" designates a control of the user
 agent's user interface (e.g., a radio button, text box, menu,
 etc.). A viewport has at most one user interface focus.

In this document, the term "focus" used alone includes both types
of focus. Where either content focus or user interface focus is
meant, that term is used.

When several viewports coexist, each may have one content focus
and one user interface focus. At all times, only one content
focus or one user interface focus receives input events; this is
called the current focus.

-----------------------
Proposal 8: Definitions of selection, current selection
-----------------------

The selection generally identifies a range of content (e.g.,
text, images, etc.) in a document. The selection may be
structured (based on the document tree) or unstructured (e.g.,
text-based). Content may be selected through user interaction,
scripts, etc. The selection may be used for a variety of
purposes: for cut and paste operations, to designate a specific
element in a document, to identify what a screen reader should
read, etc. The selection may be set by the user (e.g., by a
pointing device or the keyboard) or through an application
programming interface (API).

A viewport has at most one selection (though the selection may be
rendered graphically as discontinuous text fragments). When
several viewports coexist, each may have one selection. At all
times, only one viewport's selection receives input events; this
is called the current selection.

On the screen, the selection may be highlighted using colors,
fonts, graphics, magnification, etc. The selection may also be
rendered through changes in speech prosody, for example.

-----------------------
Proposal 9: Definition of point of regard
-----------------------

The point of regard is a position in rendered content that the
user is presumed to be viewing. The dimensions of the point of
regard may vary. For example, it may be a point (e.g., a moment
in an audio rendering or a cursor in a graphical rendering), or a
range of text (e.g., focused text), or a two-dimensional area
(e.g., content rendered through a two-dimensional graphical
viewport). The point of regard is almost always within a viewport
(though the dimensions of the point of regard could exceed those
of the viewport). The point of regard may also refer to a
particular moment in time for content that changes over time
(e.g., an audio-only presentation). User agents may determine the
point of regard in a number of ways, including based on viewport
position in content, content focus, selection, etc. A user agent
should not change the point of regard unexpectedly as this may
disorient the user.

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Wednesday, 7 March 2001 19:12:29 GMT

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