- 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