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

Re: Comments on Mozilla content keyboard navigation proposal

From: Peter Korn <Peter.Korn@Sun.COM>
Date: Thu, 16 Sep 2004 16:34:24 -0700
To: Catherine Laws <claws@us.ibm.com>
Cc: mozilla-accessibility@mozilla.org, w3c-wai-ua@w3.org
Message-id: <414A2300.6070308@sun.com>

Hi Catherine,

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

Thank you very much for this very detailed and thoughtful set of comments! 
(thanks also to the many other comments received so far - keep them coming gang!).

> 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.
> CENTER, CODE, DD, DIV, DL, DT, EMBED, FORM, HR, H1, H2, H3, H4, H5, H6,
> (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.

This makes a lot of sense to me.

> 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?

I agree.  However, this is something we inherit from the existing code.  I'm 
not sure how easy it is to remove this.

> 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.

This seems to be the growing consensus.

> 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.

I agree - anything you can manipulate with a mouse you should be able to 
manipulate with a keyboard, and anything you can manipulate with the keyboard 
you should be able to reach via keyboard navigation.

Your suggestion of using Shift+F10 to trigger these events is in keeping with 
the GNOME desktop definition of using Shift+F10 to open a popup menu for 
desktop elements that have focus and for which a popup menu exists.  The 
challenge I see is for objects that have multiple mouse-effects (e.g. both a 
mouseover and a ondblclick).  Should a popup menu be automatically constructed 
with localized text for menu items "Perform mouseover efect", "Perform 
ondblclick effect"?  I forget, can one associate ALT tags with each of these 
effects (and is it required)?  (if not I think it is an oversight in the WCAG).

> 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.

I'm very leery of special modes personally (my Macintosh heritage showing I 
suspect).  It may be that the complexity of tables forces such a thing on us 
(and the existence proof of Home Page Reader suggests it is a workable 
option).  I'd like to get more comments on this suggestion...

Mind you, I'm still dealing with my leeryness about the use of F8 for "form 
control mode".  Being modeless is hard!

> 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.

I think the idea of Ctrl+[Up|Down] is intriguing, but a hard constant like 10 
gives me the heebie-jeebies (that's a technical term).  More thinking needed 
here I think...

> 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.

In accessible UNIX Mozilla HTML forms are implemented as GTK+ widgets.  It is 
very natural to continue to use the keyboard navigation scheme of those base 
GTK+ widgets (described in more detail in the GNOME Accessibility Guide at 
http://www.gnome.org/learn/access-guide/2.6/access-guide.html).  Tab works for 
most GTK+ widgets, but Ctrl-Tab is needed for editable text widgets.  That 
would be needed for a TEXTAREA.

I believe down arrow in a TEXTAREA should not normally take you out of that 

The big issue here with forms is that you can select text within a form.  How 
do we allow that from the keyboard (and of course this is critical if we are 
relying on caret movement for screen reading).  This is where the whole 
F8/Ctrl-F8 thing comes in: to toggle between a sort of "virtual caret" mode 
that simply treats the form as "static" text you read through, and a live form 
you can interact with.

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

Good point; I think I missed that one in our internal edits.  Actually, why 
not use Alt+Spacebar, which is the way one does this with GTK+ drop-down list 
boxes (see Figure 3.8 in 

> 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?

Hmmm... I dunno... Perhaps Kyle can comment here.

> 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.

I think a "where am I" is crucial for blind users, and I think that feature 
properly belongs in the screen reader itself (which in the UNIX case is the 
Gnopernicus NumPad ENTER key on Layer 0).  I take your point that the level of 
information you suggest is perhaps more than a screen reader can reasonably 
determine by itself (and in the absence of an AccessibleDocument interface, 
yet to be defined let alone implemented by Mozilla).

In addition to the list of features in our proposal (and the additional 
feature list(s) being generated by folks responding to this proposal), we 
should also consider where to implement these features.  Specifically your 
suggestion #10 above feels like it might be best implemented by a XUL Mozilla 
extension.  Many of the other features being discussed could also be 
implemented in such an extension(s) (as I think Aaron Leventhal has 
suggested).  My preference is that things as basic as caret navigation be 
built into the core product, but perhaps more advanced things (and especially 
things like "skip to next <H1> item", "list all hyperlinks in a dialog") 
belong in Mozilla extensions.


Peter Korn
Sun Accessibility team
Received on Thursday, 16 September 2004 23:34:31 UTC

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