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