- From: Greg Lowney <gcl-0039@access-research.org>
- Date: Wed, 27 Jan 2010 22:25:33 -0800
- To: WAI-UA list <w3c-wai-ua@w3.org>
- Message-ID: <4B612DDD.2030708@access-research.org>
Here are some thoughts on the proposal for ACTION-178 and ACTION-150 -
Focus. (Below as rich text and as an attached Word document in case the
formatting doesn't come through well enough.)
To summarize:
1. Adopt ISO/ANSI terminology rather than diverging/inventing new
2. Don't define terms except in documents where they're used
3. Thoughts on input focus vs. visual focus, selection, and highlighting
1. Adopt ISO/ANSI terminology rather than diverging/inventing new
I strongly recommend we should adopt language from existing
international standards on accessible software design unless there is
compelling reason otherwise. (Sometimes harmonizing with existing W3
standards makes sense, but inventing new terminology for things already
defined rarely does.)
ISO 9241-171 (Ergonomics of human-system interaction --- Part 171:
Guidance on software accessibility) and ANSI/HFES 200.2 (Human Factors
Engineering of Software User Interfaces, Part 2: Accessibility) both use
the same terms and mostly identical definitions. Many of these were
taken from earlier international standards (with references provided).
Years of work among many national standards bodies went into developing
these; they may not be perfect, but they're very good, and they're
already widespread.
Here are the ANSI/HFES glossary entries.
*4.9 Cursor: **Visual indication of where the user interaction via
keyboard (or keyboard emulator) will occur*
NOTE 1 Keyboard focus cursors and text cursors are types of cursors.
NOTE 2 Contrast with keyboard focus cursor (4.20), text cursor (4.32),
and contrast with pointer (4.28).
*4.12 Focus Cursor: **Indicator showing which user interface element has
keyboard focus*
NOTE 1: Also called "location cursor". See also *Input focus* (4.16) and
*Cursor* (4.9).
NOTE 2: The appearance of this indicator usually depends on the kind of
user interface element that has focus. The user interface element with
focus can be activated if it is a control (e.g. button, menu item) or
selected if it is a selectable user interface element (e.g. icon, list
item).
EXAMPLE: A box or highlighted area around a text field, button, list or
menu options can serve as a focus cursor.
*4.16 Input Focus: **Current assignments of the input from an input
device to a user interface element*
EXAMPLES: Pointer focus and keyboard focus are input foci.
*4.19 Keyboard Focus:* *Current assignment of the input from the
keyboard or equivalent to a user interface element*
NOTE: For an individual user interface element focus is indicated by a
focus cursor.
*4.20 Keyboard Focus Cursor: **visual indication of where the user
interaction via keyboard (or keyboard emulator) will occur*
Note: Contrast with keyboard focus (4.19), pointer (4.28), and text
cursor (4.32).
*4.28 Pointer: **Graphical symbol that is moved on the screen according
to operations with a pointing device*
NOTE 1: The location or representation of the pointer may also change to
reflect the current state of software operations.
NOTE 2: Users typically interact with user interface elements on the
screen by moving the pointer to an object's location and manipulating
that object.
NOTE 3: Examples of devices that are used to control pointers include mice,
tablets, fingers, and 3D wands. The pointer can also be moved using the
keyboard (e.g. MouseKeys).
NOTE 4: Although the pointer is sometimes called a "pointing cursor",
this document uses the word 'cursor' only to refer to an indicator of
keyboard focus.
NOTE 5: Contrast with *Focus cursor* (4.12) and *Cursor* (4.9).
*4.29 Pointer Focus: **current assignment of the input from the pointing
device to a window*
NOTE The window with pointer focus usually has some distinguishing
characteristic, such as a highlighted border and/or title bar.
*4.32 Text cursor: **visual indication of the current insertion point
for text entry*
NOTE Contrast with "pointer" and "focus cursor."
2. Don't define terms except in documents where they're used
Terms like "full focus" and "split focus" may be useful concepts, and
should be defined in documents in which they're used, but we don't
currently use them and it's not yet clear where we would. Could you show
where you would use them in the main guidelines document?
If they're only used in the supplemental materials (e.g. the
Implementing document) then shouldn't they only be defined there?
Otherwise we simply clutter up the document, potentially confuse the
reader, and lock ourselves in to definitions that we might want to
change when we actually get around to needing them.
3. Input focus, selection, and highlighting
ISO and ANSI/HFES have quite a few terms related to input focus, which
is defined by ISO as "in relation to a given input device, the
indication of the object upon which the user directs input. Examples:
Pointer focus and keyboard focus are input foci."
I would like to contrast that with a few other concepts which we did not
define in those standards because they (for the most part) were not needed.
3.1 Input focus, keyboard focus, and pointer focus
It's important to differentiate between the input foci for different
input devices, such as keyboard input focus and pointer focus. Don't use
the term input focus when you mean the more specific keyboard focus.
While many users are used to being able to click the mouse in order to
move the keyboard focus, that isn't always the case. Some elements only
take keyboard input, not mouse input, while in other cases an element
that takes mouse input cannot take keyboard focus. The latter is almost
always due to bad user interface design, and it usually fails to meet
accessible design guidelines.
One can often use the mouse to perform tasks without affecting the
keyboard focus. The most common example is hovering the mouse in order
to scroll a window or display a transient pop-up, but in some systems
(e.g. X Windows) it is possible to use a pointing device to perform a
wide range of tasks in a background window without bringing it to the
foreground or giving it the keyboard input focus.
3.2 Active vs. Inactive input focus
/Active input focus/ is the input focus in the active context (e.g. in
the active window), while /inactive input focus/ is the keyboard input
focus in an inactive (background) window. While an inactive window does
not have the system's keyboard focus, it may still have its own keyboard
focus assignment, which would be acted on if keyboard events are
programmatically simulated into the window (e.g. by a macro or voice
input utility). In some cases (e.g. X Windows) this inactive input focus
is still visually distinguished, although usually (and hopefully) by a
different visual indicator than is used in active windows.
For example, a text editor will almost always have a keyboard focus
somewhere in every document it's displaying, one being the active pane
and the others being inactive panes. The user can move the keyboard
focus from one pane to another, or to some of the application's user
interface (e.g. a menu or dialog box). When a pane is reactivated, the
input focus is where it was when the pane was inactivated. You can think
of that as saving and restoring the input focus location, or as
activating and deactivating it, but it seems to me that the latter makes
more sense when you consider that macros, scripts, and other add-ins can
often still reference and act on that location regardless of whether or
not its pane is active.
3.3 Visual Focus
In The Microsoft® Windows® Guidelines for Accessible Software Design
(1995) I explained the concept this way:
*Visual Focus*
Many accessibility aids need to identify the "focus point" where the
user is working. For example, a blind-access utility must describe the
text or object that the user is working on, and a screen-magnification
utility pans out to enlarge whatever is at a particular point on the
screen. Other utilities may move pop-up windows, so they do not cover
"where the action is."
Sometimes, it is easy for an accessibility aid to determine this
location; the operating system provides it when it moves the focus
between windows, menus, or standard controls. It is more difficult to
determine the location when an application uses its own method of
indicating the visual focus /within its window/, such as highlighting a
cell in a spreadsheet, an icon, or a windowless custom control. In these
cases, to be accessible, the application must make its focus location
available to other programs in the system...
A common example of visual focus (or a ramification of it) is that the
user can often manually scroll a window such neither the input focus nor
the selection are shown in the viewport. That is, sometimes visual focus
is where the user seems to be looking (as in when they've scrolled the
window, or when they're typing or moving the mouse) and other times it
may refer to where the software *wants* the user to look (as in when it
flashes an icon or pops up a message).
3.4 Selection
This is one that ISO and ANSI use but we failed to define it. (Oops.)
The concept is fairly universal and well understood, with the exception
that many fail to realize that it's entirely independent of input focus
and highlighting. For example, in Windows Explorer one makes a
discontiguous selection by holding down the Ctrl key while navigating
with arrow keys, thus moving the focus without changing the selection
(see illustration below).
Illustration: In a Windows "Listview" control, items two and three are
selected (shown highlighted in blue), while the keybord (indicated by a
dotted outline) focus is on item five.
Here is an example of Mozilla Firefox having an inactive selection (the
word "Edit" selected in the content pane) and an active selection (the
letter "n" selected in the Find input box):
Illustration: Mozilla Firefox having an inactive selection (the word
"Edit" selected in the content pane) and an active selection (the letter
"n" selected in the Find input box).
3.5 Highlighting
Highlighting is a general term for when software visually differentiates
something in order to draw the user's eye towards it or make it stand
out from its surroundings. Text cursors and keyboard focus cursors are
both examples of this, but it can also be used for alerts and to call
out text or graphics for a wide range of reasons.
For examples, Mozilla Firefox allows the user to indicate (with a
differently colored background) all occurrences of a search string, as
shown in the following illustration:
Illustration: Mozilla Firefox window has the word "Edit" selected,
several occurrences of the string "an" highlighted, and the text input
cursor in the "Find" text input field.
As another example, Microsoft Windows indicates menu items that have the
keyboard input focus by drawing them with a special combination of
foreground and background colors. (ISO and ANSI call this is called a
keyboard focus cursor.)
-------- Original Message --------
Subject: Action 178
From: Kim Patch <kim@redstartsystems.com>
To: WAI-UA list <w3c-wai-ua@w3.org>
Date: 1/21/2010 2:25 PM
> Greetings,
>
> Action 178 has to do with taking a look at the focus definition.
>
> I've worked some with Mark on this. Thoughts, notes from the
> discussion with Mark, proposed definition change as it stands right
> now, original definition and excerpts from every place in the working
> draft where focus occurs is in the following Google document -- here's
> the link:
> http://docs.google.com/Doc?docid=0ASiGLIaAlHSKZGR3d3FrbWJfMjMzZHJtemhuY3o&hl=en
>
> I'll be away next week (ATIA Orlando) but am aiming to have these
> proposed changes ready for a survey the next week.
>
> Any and all input appreciated.
>
> Cheers,
> Kim
>
> --
> ___________________________________________________
>
> Kimberly Patch
> President
> Redstart Systems, Inc., makers of Utter Command
> (617) 325-3966
> kim@redstartsystems.com
>
> www.redstartsystems.com <http://www.redstartsystems.com>
> - making speech fly
>
> Patch on Speech <http://www.redstartsystems.com/blog/> blog
> Redstart Systems <http://twitter.com/RedstartSystems> on Twitter
> ___________________________________________________
Attachments
- application/msword attachment: 2010-01-27_Focus__Selection__Highlighting.doc
Received on Thursday, 28 January 2010 06:27:54 UTC