Fwd: Suggestions regarding Image Editor Keyboard Accessibility

Colin Clark colinbdclark at gmail.com
Fri Aug 12 01:18:26 UTC 2011

Begin forwarded message:

*From:* Johnny Taylor <johnny at abledaccess.com>
*Date:* 11 August, 2011 6:54:56 PM EDT
*To:* Colin Clark <colinbdclark at gmail.com>
*Cc:* Jonathan Hung <jhung at ocad.ca>, Pulkit Goyal <pulkit110 at gmail.com>,
Fluid Work <fluid-work at fluidproject.org>, James Yoon <jyoon at ocad.ca>
*Subject:* *Re: Suggestions regarding Image Editor Keyboard Accessibility*

As for me, and my Photoshop experience, it's been an interesting ride.
Especially now that I'm evaluating my habits so intently.

I started by using the mouse keys, nearly exclusively -- I'd navigate to any
spot on the screen I needed to interact with and control it via the keypad.
Much like a mouse. Because, honestly, I haven't the most precise control of
my fingers -- spacially speaking. I find the trackpad on my MacBookPro
incredibly awkward to use, most times. I can use it to move to any spot on
the screen and click, once, but as for most of the gestures in Lion, not
that I've tried nor am I in a hurry to, forget about it.

But as my recovery progressed I switched to the mouse and used it in the
exact same manner. Go to any spot on the screen and do what I needed to do.
Thinking it through right now, there's another reason for that. Since my
dexterity is impaired and I typically only use one hand -- Photoshop is the
exception, I'll break out my pinky on my left hand for those situations
where a modifier plus a click is required -- I need to shift my eyes, when
I'm working, down to the keyboard, to see what I'm doing, then back up to
the screen again. It's time consuming. When I'm working in Photoshop, I tend
to use the mouse exclusively, and don't much look away from the screen.
Where as when I type I rarely look away from the keyboard.

But you're looking to do both. I say keep the need to look at what you're
doing on the keyboard with you're hand at the bare minimum. A users eyes
need to be focused on the screen. Using the arrow keys as much as you can,
in my mind, is a primary goal. If I don't need to look at what I'm pushing
(on the keyboard), which I don't when using the arrow keys, I can't imagine
a lot of people would. Honestly, not that this is practical, I have
significant issues with having to use the tab key, too. One step at a time.

That's my advice? Do all that is possible with those 4 keys. Which
essentially means, limit both a persons need to stray too far from that
point on a keyboard and having to take their eyes off the screen.


johnny at abledaccess.com
And the solution is inclusion...

On 2011-08-11, at 1:55 PM, Colin Clark wrote:

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 (
You will want to resize the Image Reorderer window so the images are
arranged 3x2 grid to see how this may work.


- Tab key moves focus around top level items including the crop bounding

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

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

- 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

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


Colin Clark
Technical Lead, Fluid Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20110811/afccf66e/attachment.html>

More information about the fluid-work mailing list