Tab and arrow keys in the Lightbox component

Thu May 24 17:58:04 UTC 2007

We discussed these questions and a  few more at the stand-up this  
morning.  I volunteered to start a list of these interactions on the  
wiki (which will evolve into the style guide I assume).  To keep  
everyone else up to speed I'll briefly answer here.

-Daphne

On May 24, 2007, at 7:19 AM, Shaw-Han Liem wrote:

> Hi Everyone,
>
> This spreadsheet example covers some of the questions we've had with
> regards to how the keyboard-only scenario should work within the
> Lightbox component. We sat down with the mockups and a few issues came
> up. Daphne, we were hoping you might be able to help us iron out  
> these:
>
> - What happens at the 'edges' of the grid? For example, if an image in
> the right-most column is currently in focus, and the right-arrow  
> key is
> pressed, should we wrap around to the next row? The spreadsheet  
> example
> simply ignores these keypresses. Similarly, what happens when you hit
> 'up-arrow' from the top row, etc.
In the lightbox case we want keyboard users to be able to move  
linearly through their group of images.  So, yes, wrap to the next  
row when focused on the last image in a row and the user presses the  
right arrow key.   Up-arrow from the top row takes user to the last  
row.  Similarly, a down-arrow from the last row takes the user to the  
first row.
>
> - Where do we place the focus if they cancel the 'move' task without
> pasting? For example, a user selects and image, uses the cursor  
> keys to
> move to a position, but then decides to cancel the action.
This is a mute point now since we aren't using the copy/paste  
metaphor.  Instead, the arrow keys are used to move between  
thumbnails.  Ctrl+arrow (Cmd + arrow on Mac) "picks up" the thumbnail  
in focus and moves it along until the ctrl key is unpressed.
> Similarly,
> where do we place the focus after a successful move action? It seems
> logical to place the user 'where they began' after a cancel, and  
> 'where
> they finish' after a success, but we wanted to confirm this.
Yep.  Makes perfect sense to me.
>
> These were the two main points we were thinking about, if anyone  
> has any
> input or suggestions, please chime in!
>
>
> Shaw-Han
>
>
>
> Richard Schwerdtfeger wrote:
>> Hi Colin,
>>
>> The style guide is supposed to specifiy this but it is moving at a
>> snails pace.
>>
>> I would like to find more information on the "lightbox" component.
>>
>> What you are describing appears to be a 2-dimensional grid within the
>> context of the page. So, your script will need to keep track of the
>> element in the grid which last had focus. Once you tab out of the  
>> grid
>> you will want to tab back into the grid where you left off. I would
>> recommend doing this by setting the element in the grid which is to
>> receive focus when tabbing back in to a value of "0." This allows the
>> grid element with focus to be in the logical DOM tab order. GUIs work
>> the same way. If you leave and exit a spreadsheet you will want to go
>> back to where you left off. At page load time you will want to set  
>> the
>> first "cell" to a tabindex="0". Each cell in the grid should have  
>> a role
>> of "gridcell."
>>
>> Regarding "selected" their is an aria state for selected which you  
>> would
>> reference using aaa:selected="true" It also sounds like you want a  
>> role
>> of grid for the lightbox control.
>>
>> Here is a sample grid: http://www.mozilla.org/access/dhtml/ 
>> spreadsheet
>>
>> Selection is achieved, in this example, by hitting cntrl right  
>> arrow or
>> down arrow and then hitting the space bar to "select" the element.  
>> You
>> then attach some styling to the selected ARIA state (CSS 2  
>> supports this
>> and this is supported in IE 7 and FF)
>>
>> Cheers,
>> Rich
>>
>>
>> Rich Schwerdtfeger
>> Distinguished Engineer, SWG Accessibility Architect/Strategist
>> Chair, IBM Accessibility Architecture Review Board
>> blog: http://www.ibm.com/developerworks/blogs/page/schwer
>> Inactive hide details for Colin Clark <colin.clark at utoronto.ca>Colin
>> Clark <colin.clark at utoronto.ca>
>>
>>
>>                         *Colin Clark <colin.clark at utoronto.ca>*
>>                         Sent by: fluid-work-bounces at fluidproject.org
>>
>>                         05/22/2007 06:22 PM
>>
>> 	
>>
>> To
>> 	
>> fluid-work at fluidproject.org
>>
>> cc
>> 	
>>
>> Subject
>> 	
>> Tab and arrow keys in the Lightbox component
>>
>> 	
>>
>>
>> Hi all,
>>
>> As I may have mentioned in my post last week, we're working on the
>> keyboard-accessible functionality of the Lightbox component to start.
>> Daphne and I have had a few discussions on Breeze about what key
>> commands are most appropriate for this type of component.
>>
>> After doing some quick research, here is a summary of the recommended
>> behaviour for accessible keyboard navigation in rich internet  
>> applications:
>>
>> 1. The tab key moves focus between major areas of the page, in this
>> case, to the collection of images as a whole. In HTML-speak, the
>> container should have a tabindex of "0."
>>
>> 2. The arrow keys (up, down, left right) moves focus among images  
>> within
>> a collection of images in a two-dimensional way. In HTML-speak, each
>> image should have a tabindex of "-1" and the JavaScript should  
>> move focus.
>>
>> There's still the question of how the user specifies a selection.  
>> Is it
>> through the familiar cut-and-paste metaphor, or something else?  
>> It's my
>> understanding that Daphne and Mike Elledge are going to discuss this
>> functionality in more depth later this week, but it would be great to
>> hear from others who have experience building keyboard accessible  
>> DHTML
>> widgets.
>>
>> Rich, does the ARIA Style Guide specify best practices for this  
>> type of
>> interaction?
>>
>> Here are a couple of relevant links:
>>
>> Mozilla Developer Center's Key-navigable DHTML widgets article:
>> http://developer.mozilla.org/en/docs/Key- 
>> navigable_custom_DHTML_widgets
>>
>> ARIA Roadmap, which provides general information on use of tabindex:
>> http://www.w3.org/TR/aria-roadmap/
>>
>> Colin
>>
>> -- 
>> Colin Clark
>> Technical Lead, Fluid Project
>> Adaptive Technology Resource Centre, University of Toronto
>> http://fluidproject.org
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070524/0fd5ea16/attachment.htm>