Fwd: Suggestions regarding Image Editor Keyboard Accessibility

Antranig Basman antranig.basman at colorado.edu
Fri Aug 12 01:30:45 UTC 2011


Does this sound like a new axis of variation that we will aim to capture as part of the preferences + 
profile system of the "UI Options family"?

"I prefer modal interfaces to the use of keyboard chording"
"I prefer to navigate using the smallest number of distinct keys possible"

To me, these sound like preferences that would make sense across a wide variety of widgets/interactions.

Antranig.

On 11/08/2011 19:18, Colin Clark wrote:
> 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
>
> johnny at abledaccess.com
> http://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 (
> 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
>
>
>
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work



More information about the fluid-work mailing list