- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 07 Mar 2001 19:12:24 -0500
- 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 UTC