Lightbox: Cut and Paste / Drag and Drop

Colin Clark colin.clark at
Wed Jun 6 23:19:17 UTC 2007

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  


Quoting Richard Schwerdtfeger <schwer at>:

> I would to point everyone to the latest ARIA working drafts. We have a new
> section on drag and drop properties:
> 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:
>              Paul Zablosky
>              <Paul.Zablosky at ub
>    >                                                      To
>              Sent by:                  fluid-work at
>              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> 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
>       University of Toronto - ATRC
>       Tel: (416) 946-8312
>       _______________________________________________
>       fluid-work mailing list
>       fluid-work at
> _______________________________________________
> fluid-work mailing list
> fluid-work at

More information about the fluid-work mailing list