Keyboard Interaction for Re-ordering Portlets

[Joseph Scheuhammer]

All,

Due to a discussion Shaw-Han, Michelle, and I had yesterday afternoon, 
here are some more questions/food for thought:

This thread started as a proposal to answer the question of the correct 
keystrokes that the Reorderer uses to navigate and move orderable 
portlets.  But, there is another related question:  what if there is no 
Reorderer present?  What are the navigation keystrokes in that case?  
Whatever they are, if a Reorderer comes into play, its keystrokes should 
be consistent with what is already present.

Furthermore, what is it that ensures that the proper keyboard navigation 
in imposed when an Reorderer is absent?  Let me unpack that question 
using the Lightbox as an example:  When the Reorderer is present, one 
can navigate among the thumbnails by tabbing to the lightbox container, 
and then arrowing among the thumbnails.  The "tabbing" is accomplished 
by setting a "tabindex" attribute on the lightbox container element.  
The arrowing is added via the Reorderer JavaScript code.

Hence, if there is no Reorderer present in the Lightbox, then all the 
user can do is tab to the lightbox container.  Users cannot arrow among 
the thumbnails.  As it happens, they can tab among them since each 
thumbnail contains links, and because browsers are "hard-coded" to use 
tab key presses to move among links.  (Note:  you can quickly simulate 
the absence of the Reorderer by disabling JavaScript in your browser, 
and then loading the Lightbox html example).  But, tabbing among the 
thumbnails is a different navigation experience compared to arrowing 
among them.

This leads to the general question:  what imposes the keyboard 
navigation protocol in the absence of a Reorderer?  Is it a combination 
of ARIA and tabindex; that is, properties of the markup and built-in 
browser functionality?  Or, is there a general KeyboardNavigator 
component independent of the Reorderer that handles this in all cases?  
Is a general KeyboardNavigator even possible?  Is a KeyboardNavigator a 
case of "dom facism" since it imposes a navigation structure over and 
above what the markup may already define?

I don't have any answers; I'm still trying to wrap my head around the 
question(s). In fact, the question might actually be:  should the 
Reorderer impose any keyboard *navigation* at all?  Should it be limited 
only to keystrokes that change the order?  Is keyboard navigation 
someone else's responsibility?

-- 
;;;;joseph

'This is not war -- this is pest control!'
      - "Doomsday", Dalek Leader -