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

Re: Action 178

From: Greg Lowney <gcl-0039@access-research.org>
Date: Wed, 27 Jan 2010 22:25:33 -0800
Message-ID: <4B612DDD.2030708@access-research.org>
To: WAI-UA list <w3c-wai-ua@w3.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
> ___________________________________________________




Received on Thursday, 28 January 2010 06:27:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 28 January 2010 06:27:56 GMT