Re: Keyboard navigation in JHTML component

[Calum Benson <calum benson ireland sun com>]

earl johnson wrote:

> An "input focus here" glyph, see discussion below, should also show up
> at the beginning of the first item in the page -or- where it was last
> at if the user is going back and fourth between the browser controls
> and the GtkHTML widget.

Yes, I just wasn't sure whether that should show up by default or not--
wouldn't it be a bit distracting to have it show up on every web page
you visited whether you intended to interact with that page or not? 
Maybe not, I guess, it's probably more beneficial to show it than to not
show it.

> Do you mean:
>         Shift+Tab key cycles focus to the previous activatable element
>         Tab key cycles focus to the next activatable element

Yes, that's what I meant.  Just the usual behaviour, in other words.

> My vote: the <some other key> should be arrow keys.

Well, I thought about that, but once a block of text has focus, the
arrow keys would move the cursor around within that block-- the way it
was described in this proposal, anyway.  Or are you suggesting that all
the text on the page should be considered as one block?  That's probably
a better idea, come to think of it.

> Finally, arrow keys are how the other browsers handle this (up/down at least for
> Netscape, up/dn/l/r for IE).

Hmm, last time I tried either of those browsers I couldn't select text
from the keyboard alone-- I'll have to try again, it obviously wasn't
very intuitive!

> As for the glyph to choose my suggestion is make it so it clearly does not 
> look like the editing glyph (which is typically a vertical line or i-bar).

Yes, sounds like a good idea.

> On dealing with interactive objects (text fields, links, etc.), how
> about have shift+arrow simply hilite them and not give them focus -
> leave giving focus to these to Tab/shift+Tab.

Certainly makes sense for links... I suppose it does for interactive
elements too, if you were copying from a web page into a webpage editor,
for example.  And it would make the "consider all static text on the
page to be part of the same block" idea work better.

> Finally, if you haven't already, it would be good to look at how IE
> handles active element and hiliting navigation. It's been a while since
> I looked at them but I thought they did a pretty good job with dealing
> with some if not all the problems you've cited.

Well, as I said, last time I looked at it I couldn't get any keyboard
navigation to work at all, other than for the interactive elements on
the page-- maybe I just wasn't trying hard enough!  I'll take another
look.

> I think GtkHTML's  actions should be as close as possible to IEs because 
> so many people with disabilities use it instead of Netscape.

Good point.

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems