Create a new Keyboard Accessibility demo

Description

Create a new keyboard accessibility plugin that demonstrates the purpose and usage of the component.

This will replace existing keyboard accessibility demos and be the basis for the tutorial documentation.

For this demo, an thumbnail can have 4 states: focus, selected, focused & selected, and neither (it's a bit clumsy, but helps demonstrate the plugin). If a thumbnail has focus, it does not mean it is shown in the viewer. The user needs to explicitly select the image to be viewed. This way the user can move focus to other images while their previous selection stays constant until changed.

Here is the breakdown of the keyboard interaction:

1. The interface is loaded and the first thumbnail is selected (but not focused) and shown large in the main viewer.

2. The user presses tab once and focus moves to the "Keyboard Instructions" link container. The keyboard instructions immediately appear without any need for user action. (if needed revealing the instructions can require keyboard interaction as to not annoy the user with an overlay)

3. The user presses tab again and focus moves to the first thumbnail and selects it, or focus moves to the last selected thumbnail.

4. If the user presses Space bar on a thumbnail that already has focus, nothing happens.

5. If the user presses Right or Left arrow keys, the focus will move to the next image. Performing this action will not change the selection.

6. If focus is in the thumbnail filmstrip and the user presses Tab key, the focus then moves to the main image. If there is Alt Text associated with the image, it will be presented visually to the user.

7. The user presses tab and focus now moves from the main image to the 5-Star ranking widget. Upon focus of this container, instructions are presented to the user letting them know that Left and Right arrow keys will change their selected ranking.

8. With focus on the 5-star widget, the user can press left to decrease, or right to increase the ranking. The value selected persists during the demo session.

Notes on mouse interaction:
Mouse interaction behaves the same way as the keyboard interaction. Whenever an interesting container gains focus by clicking, an instructional message appears to let them know what they can do. The only significant addition to the mouse interaction is the hovering behaviour:

1. User can mouse hover over a thumbnail and it changes to the focus style, but the previous selection stays the same.
2. The 5-star widget will react if the user is hovering over it. For example, if the user hovers over the 3rd star, stars 1, 2, and 3 will activate showing the user the result if they click where they are hovering.

Implementation detail on the 5-star widget:
I have seen an unordered list implementation of the 5-star widget that uses CSS only and reacts to mouse hovers without any Javascript. The only Javascript required for the 5-star widget is to keep track of the rank values for each image during the demo. This way there is some persistence to the user's rankings in a single session of the demo.

Keyboard wrapping for the reorderer is enabled.

Environment

None

Attachments

5

Activity

Show:

Colin Clark December 16, 2010 at 1:04 AM

Reviewed, tested, committed, closed.

Colin Clark December 16, 2010 at 1:00 AM

I've reviewed, tested, and committed Anastasia's latest patch for this issue, which appropriately refactors how we handle selectors throughout the demo. This is sufficient for Infusion 1.3. Given how rich and complex this demo is, I am inclined to agree with the idea that it's a good candidate for component-ification, but this work can easily be done for the Infusion 1.4 release instead.

Anastasia, can you file a separate JIRA for the issue of converting the demo into a component, and I'll close this one.

Anastasia Cheetham December 14, 2010 at 5:36 PM

Antranig, I've attached a patch (FLUID-3799-selectors.patch.txt) that addresses the second of your comments (see my comment on the JIRA for more information). Could you please have a look at it? As to re-implementing the whole demo as a component, please see my email to the list.

Anastasia Cheetham December 14, 2010 at 5:34 PM

This patch (FLUID-3799-selectors.patch.txt) addresses the second of Antranig's comments: the use of hard-coded element types instead of selectors. Selectors have been defined, and the selectable items have been slightly adjusted so that the activate event and the click event happen to the same element, eliminating the need to figure out where the actual event was.

Anastasia Cheetham December 14, 2010 at 3:55 PM

Reopening to address some of Antranig's comments

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Created October 15, 2010 at 8:23 PM
Updated December 16, 2010 at 1:04 AM
Resolved December 16, 2010 at 1:00 AM