W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2004

Comments on Mozilla content keyboard navigation proposal

From: Catherine Laws <claws@us.ibm.com>
Date: Thu, 16 Sep 2004 12:41:41 -0500
To: mozilla-accessibility@mozilla.org, w3c-wai-ua@w3.org
Message-ID: <OF244361D2.A0D1E7B6-ON86256F11.0057FF09-86256F11.0061350B@us.ibm.com>





Peter,

Here are some of my comments and suggestions regarding this proposal  based
on work we have done at IBM related to Home Page Reader:

1. Instead of using Up and Down Arrows to navigate by line, which is a
visual entity, use them to navigate by an entity which is content based,
which I'll call an item. Here is the definition of an item as we define it
in HPR:  Items include the smallest of a paragraph, header, table summary,
table cell, control, select menu item, list item, or map area  A more
technical definition is that an item is all text obtained by moving
backwards and forwards (in the DOM) until Item-elements are encountered.
Item elements are: ADDRESS, APPLET, AREA, BLOCKQUOTE, BODY, BR, CAPTION,
CENTER, CODE, DD, DIV, DL, DT, EMBED, FORM, HR, H1, H2, H3, H4, H5, H6,
IFRAME, ISINDEX, LEGEND, LI, MAP, NOFRAMES, NOSCRIPT, OBJECT,OPTION, P, PRE
(and each line in PRE), SAMP (and each line in SAMP), SELECT, TABLE
summary, TD, TEXTAREA, TH, UL, XMP(and each line in XMP).

As a general statement, change all movement based on a visual interval,
such as a line, to a content-based interval based on an item defintion.
Instead of using PgUp and PgDn to scroll based on a visual interval, such
as the number of visual lines, consider scrolling based on content, such as
10 items at a time. Have Home and End move to the beginning/end of an item
instead of a line.

2. It seems confusing to have 2 different definitions of a word. I prefer
the Window definition of a word, not the GTK definition. Would the default
preference be based on the operating system environment?

3. I agree with other responses - Ctrl + Home/End should move to the
beginning/end of a page in general. On a frameset page, Ctrl + Home/End
should move to the beginning/end of the current frame as stated.

4. Focusable widgets should include elements with mouse and keyboard event
handlers, such as onmouseover, onkeypress, ondblclick, etc. So the Tab key
should include those elements with event handlers that are not links or
controls as well. There needs to be a keyboard way to trigger onmouseover
and ondblclick event handlers since Enter and Spacebar won't do it. I
suggest adding these event handlers to the context menu for an element,
which should be displayed using Shift + F10.

5. For table navigation, the Up and Down Arrow keys if defined as previous
and next item keys, should work well for navigation through a table
serially. To provide advanced table navigation up and down columns as well
as across rows, with special navigation for spanned cells and for
identifying headers, I think you need a special table caret browsing mode
that you could enter and exit with a special function key (like F4 or F8
for example). Table navigation keys could be defined as follows:

Up and Down Arrow keys move up and down one physical cell.
Left and Right Arrow keys move left and right one physical cell.
To move to spanned cell boundaries: Shift + Up/Down/Left/Right arrow keys
move up/down/left/right by one logical table cell (spanned cell consisting
of more than one physicall cell).
Home and End move to the first/last cell in the current row.
Page Up and Down.  Moves to the top/bottom cell in the current column.
Control + Home/End. Moves to the first/last cell in the table.
Table orientation keys. Control + Up , Down, Left or Right Arrow keeps the
current focus but jumps to the top/bottom cell in the column or the
first/last cell in the row. You can continue to navigate through the table
from this cell by holding the Control key down and using the Arrow keys to
move around. When you have finished exploring the table, you release the
Control key and the focus is still where you began.

6. I agree with other postings that F8 should not be used to navigate out
of a form control. I think Tab/Shift + Tab is fine for navigating out of a
control if you want to go to the next/previous link or control, but you
still need a key for navigating to the next/previous item after/before a
control that is not a control. I suggest creating a navigation technique
called block jumping using Ctrl + Up or Down Arrow. With block jumping, you
navigate between sets of focusable widgets and non-focusable widgets.  A
block of focusable widgets is a set determined by scanning a string of
characters which are part of a focusable widget and extending the scanning
until a block of text greater than 10 (or some other number of) characters
is encountered. A block of text is the set of characters left between
blocks of focusable widgets. A block of text can include focusable widgets,
but more than 10 characters must exist between the embedded focusable
widgets. The number 10 can be a variable that is changed as a hidden
setting or by user preference. Block jumping is very useful for skipping
over navigation bars, such as map areas and lists of links.

7. In a TEXTAREA, the Enter key will cause focus to move to a new line, not
submit a form. So you need to move out of the textarea with the Tab key or
some othe type of control before pressing Enter to submit the form.
However, let me see if I understand completely your proposal about the Tab
key. If you are using the arrow keys (up, down, left, right) to navigate
and you move focus to a text field, do you need to press the Tab key to
starting editing, or will the Tab key take you to the next control after
the text field? Where will the next down arrow take you after you move to a
textarea with the down arrow key - to a new line or to the next item (or
line as you proposed)? I think you need a key to "enter" and "exit" edit
mode.

8. For Select, why have F4 defined for dropping down the list when Alt +
Down Arrow will do that?

9. For plug-ins and embedded objects like Flash, I think it is better to
not just fall into and out of the object with the Tab key. I think Tab
should navigate to  the object but not pass keyboard control to the object
until the user presses a key to request that. I suggest Ctrl + Tab (or F6)
for navigating into and out of the object, thus treating the embedded
object as if it were a frame. With Tab, you would have to navigate to the
last control or link in the object before you can jump out. Does xembed
protocol handle the problem of passing keyboard focus back and forth
between the browser and the object and handling the desired keys for doing
this?

10. To help with orientation, I suggest that a Where am I type key (like
Atl + F1) be implemented that displays a dialog describing the current
location of focus in the page relative to an item or focusable widget
number and relative to and within any container - such as a table, form,
list, map, or select menu. Ideally, it could identify some known
information such as an explicit label for the currently focused control,
headers for the current table cell, or a table summary for the current
table.


Cathy Laws

IBM Accessibility Center, WW Strategic Platform Enablement
11501 Burnet Road,  Bldg 904 Office 5F017, Austin, Texas 78758
Phone: (512) 838-4595, FAX: (512) 838-9367, E-mail: claws@us.ibm.com, Web:
http://www.ibm.com/able

Whatever you do, work at it with all your heart.
Received on Thursday, 16 September 2004 17:42:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:33 UTC