Lightbox: Cut and Paste / Drag and Drop

[Colin Clark]

Hi Rich,

Thanks for reminding us about these. We are definitely planning to add  
these ARIA semantics to the Lightbox component over the next week or  
two.

Colin

Quoting Richard Schwerdtfeger <schwer at us.ibm.com>:

>
>
> I would to point everyone to the latest ARIA working drafts. We have a new
> section on drag and drop properties:
> http://www.w3.org/TR/aria-state/#dragdrop
>
> One of the big accessibility issues with drag and drop is identifying what
> you can grab and where you can drop it. One of the reasons for introducing
> these properties was to indicate this information through accessibility API
> in the browser to a screen reader and optionally using style sheets to
> "light up" the "grab" and "dropeffect" areas by applying CSS selectors to
> the properties. The AT or user can navigate to the drop points as needed.
>
> Rich
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
> Chair, IBM Accessibility Architecture Review  Board
> blog: http://www.ibm.com/developerworks/blogs/page/schwer
>
>
>
>              Paul Zablosky
>              <Paul.Zablosky at ub
>              c.ca>                                                      To
>              Sent by:                  fluid-work at fluidproject.org
>              fluid-work-bounce                                          cc
>              s at fluidproject.or
>              g                                                     Subject
>                                        Re: Lightbox: Cut and Paste / Drag
>                                        and Drop
>              06/06/2007 03:31
>              PM
>
>
>
>
>
>
>
>
> The power of the drag-and-drop metaphor lies in the fact that the state of
> the transaction is continuously visible as the transaction progresses.
> It's easy for the user to see how far it has gotten, and it's easy to see
> how to back out (put it back where you found it).  While the name
> "drag-and-drop" suggests a two-part event, the user can really be thinking
> "move" -- a single atomic step.
>
> With cut-and-paste, we really do have two parts: object selection, and
> target selection.  It's harder to indicate the interim status while the
> select object hovers between locations (perhaps it's in the Star Trek
> transporter pattern buffer?).  But there are various things to be
> considered:
>       How do I back out, just using the keyboard?
>       If I abandon the transaction after the cut, how does the object
>       become unselected?
>       Under what circumstances does a cut become a delete? (Other than
>       pasting into the trash receptacle)
>       If I forget what I was doing (e.g. the phone rang), how am I reminded
>       that my cursor carries a payload to be pasted, and how do I find out
>       what that payload is, and that it's a cut, not a copy?
>       What happens if I attempt another cut while one is still pending?
> Having all  these things apparent contributes to making the user's life
> easier, but they must be expressed in an obvious and intuitive way.
>
> One way around some of these concerns is to specify the paste target
> location first.  There's less downside if you abandon or forget your paste
> location. But this approach has it's own risks, and it's really
> non-intuitive.  (It is how ATM's work -- you specify the target account
> before you submit the envelope.)
>
> Given all that, I agree that cut-and-paste (CtrlX/CtrlV) is the way to go.
> We just have to do what we can to make it feel as safe as a "move" does.
>
> Paul
>
> Jonathan Hung wrote:
>
>
>       On 06/06/07, Shaw-Han Liem <shawhan.liem at utoronto.ca> wrote:
>         So the question was: If we do decide to implement the added
>         'cut/paste' keyboard shortcuts, does it make sense to change the
>         visual design and behaviour so that it more closely follows the
>         'cut
>         and paste' convention (for example, when you "cut" an image, it
>         would
>         disappear and be replaced by a 'cursor' until it is pasted again).,
>
>       This raises some interesting issues. If you cut an image and it
>       disappears from the UI, how do we indicate where to paste? Does this
>       mean implementing a cursor?
>
>       Also, the convention of having the item disappearing when cut is
>       something I see mostly with text. For all other computer "objects"
>       like file folders, images, etc., a greyed-out version is left behind
>       until you paste it to your destination. Leaving a greyed-out version
>       is useful as it gives you a visual cue. Also if they abort the
>       cut-and-paste command, the greyed-out token implies that it isn't
>       permanent, whereas cutting it completely from the UI may appear like
>       a deletion.
>
>       I like the idea of using the conventional CTRL+X / CTRL+V pattern...
>       it will make adoption and learning a lot easier and quicker.
>
>       - Jonathan.
>       --
>       Jonathan Hung / jonathan.hung at utoronto.ca
>       University of Toronto - ATRC
>       Tel: (416) 946-8312
>
>
>       _______________________________________________
>       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
>