Suggestions regarding Image Editor Keyboard Accessibility

Colin Clark colinbdclark at gmail.com
Thu Aug 11 17:55:41 UTC 2011


Hi all,

On 2011-08-11, at 10:48 AM, Jonathan Hung wrote:
> Traditionally in a webpage / portal design the follow keyboard navigation works well. I'm providing this here as background information on a traditional interaction:
> - Tab key changes focus between top-level items
> - Shift+Tab would put focus to the previous top-level focusable item
> - Enter key changes focus to the first focusable item inside the currently focused object
> - Once inside a 2nd level object, arrow keys are used to move between items.

You're close here. Step three isn't typically true for most container-style widgets. Hitting tab moves focus into the container and selects the first item within the container. The Enter key activates an action or selection, rather than moving focus into the container. Try it out with your favourite desktop or HTML widget (such as a tabs control or a select box) to see what I mean.

> For the Image Editor, keyboard access similar to the Fluid Infusion Image Reorderer may work nicely (http://build.fluidproject.org/infusion/demos/reorderer/imageReorderer/html/imageReorderer.html). You will want to resize the Image Reorderer window so the images are arranged 3x2 grid to see how this may work.
> 
> Essentially:
> - Tab key moves focus around top level items including the crop bounding box.
> - Enter key puts focus on the top-left drag handle
> - Arrow key moves focus between drag handles (up and down keys puts focus on the drag handle immediately below the current selected handle).
> - While holding CTRL, pressing an Arrow key would begin a "drag" action.
> - Releasing CTRL will conclude a drag action.
> - Similarly, if focus is on the crop bounding box (not on a handle), holding CTRL+arrow keys will move the crop bounding box around the canvas. Although, I can see this particular interaction not requiring the CTRL modifier - but I think it's good to keep the keyboard interactions for "moving something" consistent.

I think this could be a workable solution for the current design. If we're drawing a default-sized box automatically for the user, allowing them to arrow around to select a control point makes sense, and the Reorderer's modifier key approach works as a way to move the control point.

However, I'd encourage us to look at how bounding boxes work in a few popular image editors, such as Photoshop, to see if we're on the right track. One interesting point is that some editors don't draw a default-sized box, instead, the user selects a point and draws out the box the their desired size.

Another approach might be to treat the bounding box as a single element, using the arrow keys to stretch out a border in the direction indicated. We'd likely need a modifier to do the equivalent shrink operation.

Either way, I think we probably need to do a quick comparative analysis of other image editing tools before assuming we've got it right, and also talk to some users. Our friend Johnny Taylor has quite a bit of experience using Photoshop entirely with a mouse, so perhaps he has some insights into what to look for (or to avoid) based on his hands-on experience.

> An alternative to the CTRL+Arrow key interaction is to use the Enter key as a move mode "on and off" when a drag handle is selected:
> - Tab key moves focus around top level items including the crop bounding box.
> - Enter key puts focus on the top-left drag handle
> - Arrow key moves focus between drag handles (up and down keys puts focus on the drag handle immediately below the current selected handle).
> - Pressing Enter key while a drag handle is selected puts the drag handle in "move mode".
> - Pressing an Arrow key would move the drag handle.
> - Pressing Enter key again would conclude "move mode" and the originally selected handle remains selected.
> - Similarly, if focus is on the crop bounding box (not on a handle), Enter key will move the crop bounding box in and out of move mode.
> 
> This alternative interaction may actually be desirable because it doesn't require the user to hold down two keys simultaneously - thus reducing motor skill requirement and overall user error.

This seems a fair bit more complex, and brings with it all of the problems of mode-based interfaces ("Which mode am I in again?" "Why won't this key do what it was doing a second ago?"). Keep in mind, too, that most users who have difficulty chording on a keyboard will be using the built-in sticky keys feature of any operating system, so modifier keys shouldn't be a problem.

James, Johnny, do you have any thoughts or advice?

Colin

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org



More information about the fluid-work mailing list