Re: Keyboard navigation in JHTML component

[Calum Benson <calum benson ireland sun com>]

Calum Benson wrote:
>
> 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.

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

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.  

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