Keyboard Interaction for Re-ordering Portlets

[Colin Clark]

Hi Joseph,

Wow, this is a very detailed question. At risk of glossing over some  
of your finer points, I'll try to respond.

The Reorderer's approach uses so-called "progressive enhancement."  
When it is present, it provides a richer keyboard navigation  
experience, allowing you to select elements using the arrow keys.

When it's not present, the standard browser rules for tabbing remain,  
and we don't want to do anything to get in the way. That's why, in the  
Lightbox as an example, we dynamically add tabindex "-1" values to the  
thumbnail links in JavaScript. This preserves the standard tab  
navigation behaviour when JavaScript is turned off, but allows us to  
enhance the keyboard navigation scheme when it is available.

We'll likely also move to a process where we add ARIA to Fluid  
components dynamically, so that in cases where JavaScript isn't  
available, our markup once again degrades gracefully.

Does this help to answer your question?

Colin

On 18-Jan-08, at 10:49 AM, Joseph Scheuhammer wrote:

> 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 -
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>
>