Re: Keyboard navigation in JHTML component

[earl johnson <Earl Johnson sun com>]

Hi Calum,

> >
> > Okay, thanks... well in that case, we need to come up with a proposal
> > for how we can do it better in the GNOME HTML component, and quick  :)
> 
> Well, here's one suggestion for selecting text/images from a read-only
> HTML page using only the keyboard--  mostly courtesy of Bill, but with a
> couple of details added by me...
> 
> 1. Tab key initially gives focus to the GtkHTML component, as per
> current proposal.  At this point, GtkHTML widget shows focus somehow
> (e.g. thick border), but none of the focusable elements on the HTML page
> do so.
> 
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.

> 2. Once GtkHTML widget has focus, (Shift+)Tab key cycles focus to the
> next/previous activatable element on the HTML page, i.e. a link or form
> control. (As per current proposal).
> 
Do you mean:
	Shift+Tab key cycles focus to the previous activatable element
	Tab key cycles focus to the next activatable element

> 3. Once GtkHTML widget has focus, in addition to (Shift+)Tab, you can
> also press (Shift+)<some other key> to cycle focus around each of the
> HTML elements that are seen at the accessibility object level (Bill can
> probably offer a more accurate description here!)  This includes the
> aforementioned links and form controls, but also static images and
> individual blocks/paragraphs of text.  
> 
My vote: the <some other key> should be arrow keys. I think it will get
rid of all or most the problems you cite below. Also, a web page is
basically a compound document containing text, regular text documents
use the arrow keys for cycling thru text in documents so for
consistancy, regardless of whether the text and objects in the page are
editable, the GtkHTML widget should follow this convention. Finally,
arrow keys are how the other browsers handle this (up/down at least for
Netscape, up/dn/l/r for IE).

As for indicating where the "input focus here" is, how about using a triangle
or some glyph to indicate where any text/object hiliting will begin if
Shift+arrow is used and for just indicating where keyboard navigation
is moving regardless of whether hiliting is occuring. 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).

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.

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. I think GtkHTML's
actions should be as close as possible to IEs because so many people
with disabilities use it instead of Netscape.



> Problem #1: which <some other key> could we choose, since Tab,
> Shift+Tab, Ctrl+Tab and Alt+Tab are already taken?
> 
> When a block of text is given focus in this way, focus is indicated by a
> dotted rectangle around the whole block, for example.  A text cursor
> also appears at the start of that block.  The cursor can be moved around
> within the focused block using (Ctrl+)arrow keys in the usual way, and
> text within the block selected using Shift+(Ctrl+)arrow keys in the
> usual way.  Moving focus on to another element on the page would clear
> any selection in the previous element.
> 
> Problem #2: how would you select text that spanned more than one
> block/paragraph?  
> 
> Problem #3: When an image is given focus in this way, should it be
> selected automatically, ready for copying?  What if it's an image map? 
> (See next problem!)
> 
> Problem #4: How would one usefully cycle through the possible links in a
> client-side image map, or would we expect that level of functionality to
> be best left to an AT?  Or would it make sense for (Shift+)<our other
> key> to cycle focus through the discrete polygonal areas in the map,
> highlighting each in turn, after the image itself had first received
> focus?
> 
> 4.  At any time, Ctrl+Tab moves focus out of the GtkHTML widget
> altogether and onto the next widget, and Shift+Ctrl+Tab moves it to the
> previous widget.  (Unless the currently-focused item on the HTML page
> accepts Tab characters, e.g. a text field, in which case, Ctrl+Tab moves
> to the next activatable element on the page). This is as per the current
> proposal.  
> 
> Problem #5:  what if *all* the activatable elements on the page accept
> Tab characters, and therefore they all need you to press Ctrl+Tab to
> skip to the next one--  how would you get focus out of the HTML widget
> altogether?  An unlikely scenario, but I guess it could happen...
> 
> Anyway, I thought this sounded like a good first attempt at a solution
> (questions of technical feasability aside!), but it obviously still has
> some flaws... anybody care to suggest some refinements, or a completely
> different solution altogether?
> 
> 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