Tab and arrow keys in the Lightbox component

Shaw-Han Liem shawhan.liem at utoronto.ca
Thu May 24 14:19:47 UTC 2007


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.

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

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



More information about the fluid-work mailing list