Keyboard Interaction for Re-ordering Portlets
daphne at media.berkeley.edu
Fri Jan 18 20:49:07 UTC 2008
Interesting conversation. A couple comments below...
On Jan 18, 2008, at 7:49 AM, Joseph Scheuhammer wrote:
> 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
> 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
> be consistent with what is already present.
In Sakai, it would work like the reorder does now. Tabs move between
panes and arrows move between individual items.
> Furthermore, what is it that ensures that the proper keyboard
> 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
> and then arrowing among the thumbnails. The "tabbing" is accomplished
> by setting a "tabindex" attribute on the lightbox container element.
> 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
> 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
> and then loading the Lightbox html example). But, tabbing among the
> thumbnails is a different navigation experience compared to arrowing
> among them.
Ah ha. Most other places in Sakai (if not everywhere) the arrow keys
allow users to navigate between individual items. I assume we'll
always have the reorder available in the Lightbox but if not we may
want to change that behavior to be more consistent with other areas
of the Sakai.
> This leads to the general question: what imposes the keyboard
> navigation protocol in the absence of a Reorderer? Is it a
> 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
> only to keystrokes that change the order? Is keyboard navigation
> someone else's responsibility?
Hmmm...perhaps it should be someone else's responsibility if it would
ever be used without the reorder implemented. Is it true then that
the Image Gallery didn't support arrow navigation between thumbnails
before the lightbox?
> 'This is not war -- this is pest control!'
> - "Doomsday", Dalek Leader -
> fluid-work mailing list
> fluid-work at fluidproject.org
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work