Re: Keyboard navigation in JHTML component

[Earl Johnson <Earl Johnson sun com>]

Hi Calum,

> 
> > 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.
> 
My thought was this wouldn't show up till the user engaged in keyboard
navigation on a page. It would go away when a new page was visited
until the user again engaged in keyboard navigation on the new page.


> > 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.
> 
If block = hilited text. In text editors, when the arrow keey is
pressed after hiliting text the hilite region goes away.

If block is just un-hilited text and objects then I vote to consider
the whole page, a block. If the page contains frames then each frame
would be considered a block so the arrow navigation respects the frame
boundaries.


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

ej