Hi Oliver,
It is important that I share your views with the group as Joseph Schehammer
has my modified my revisions based on work by the style guide working group
and these will be discussed on Monday's call.
Rich
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
blog: http://www.ibm.com/developerworks/blogs/page/schwer
Oliver Keim <oliver.keim@sap.com> wrote on 12/05/2008 02:00:49 AM:
> Oliver Keim <oliver.keim@sap.com>
> 12/05/2008 02:00 AM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS, stefan.schnabel@sap.com>
>
> cc
>
> Subject
>
> Drag and drop accessibility
>
>
> Hi Rich,
>
> I was asked by Stefan Schnabel to read and comment on the Drag and
> Drop proposal.
>
> From our point of view there is no need to create a distinct
> interaction design for getting mouse-based drag and drop working
> with the keyboard. We propose to make use of copy and paste, which
> is basically the same interaction pattern. Same steps, known keyboard
use. I
>
The current design is recommending a way to select each of the objects for
drag and then use a copy/paste.
keyboard paradigm to start and complete the drag. The user
needs to know how to do this:
http://lists.w3.org/Archives/Member/w3c-wai-pf/2008OctDec/att-0339/00-part
That said there is an alternative vehicle is allowed as long as it is
documented on the page.
The current proposal uses control+c to indicate that all items have been
selected for drag similar
to copy which you indicate. Jon Gunderson's example gets away with using
the space bar but he is only
selecting one item at a time. Perhaps if we stick to using the space bar
for selecting and control+c as
you indicate we have consensus with your suggestions.
The group has also instituted a contol+v for the drop unless multiple
operation drop types are supported by the
drop target in which case they have opted for a shift+control+v.
> In addition it adds more value to applications if applications
> provide good clipboard features. And it adds another "more value":
> No doubled interaction methods of transfering data from one point to
> another - I think this might be a major topic if drag and drop will
> be made accessible and the applications also provide copy and paste
I think, per above, we are consistent with what you are suggesting. Please
look at
Joseph's post linked to above.
> - different from each other. This is something nobody really wants
> to have or deal with.
>
> The thing is: copy and paste and drag and drop provide data objects
> in a temporary space. For copy and paste it is the clipboard, with
> all its capabilities of saving various clipboard formats and custom
> clipboard formats at the same time, so the receipient of the data
> selects what matches best. For drag and drop there is also some
> temporary space, unfortunately most often it is application centric
> and provides only a single format.
>
> Combining both patterns would create a more comprehensive system
> design and future capabilites for drag and drop users as well. Even
> cross-border drag and drop (across windows, across applications,
> across systems) would be easier to handle.
>
> I liked the idea of using Shift+Ctrl+v for enhanced pasting, which
> is basically what has been implemented in open office and is named
> "paste special...". So it is a known pattern. Using Shift to
> activate enhanced functionality is also a well known pattern.
>
> We also appreciate the use of Shift+F10 and the contextmenu key as
> the trigger to open a context menu at the drop target. The context
The style guide group is currently promoting the use of Shift+control+v
as the context menu for the drop. Shift+F10, on the Mac greys out
everything but the
current Window.
> menu contains the copy/paste functions, just the way it is
> implemented within the Windows explorer or was implemented within
> the OS2 presentation manager. (To be honest: On Apple systems this
> is a lack of their Finder design: copy and paste cannot be used as
> an alternative to drag and drop - unfortunately, because I love my mac.)
>
I use a mac too.
> 1. Navigate to the source
>
> 2. Identify objects:
> Within the source control
> - all items need to be keyboard-navigable.
> - the focus navigation is independent from the selection
I think this is consistent with what we have.
> - all item containers need to provide multi-selection (or single
> selection but this adds repeated unnecessary interaction for the user)
>
This we need to discuss.
> 3. Initiate
> Objects are identified by:
> - each item is navigated and selected (best practise: toggeling the
> selection state, see Windows explorer design)
> - at the end of the selection the objects are taken to the temporary
> space, the clipboard - using Ctrl+c.
>
I think the subtle difference is the default operation may be a move or
execute but
not copy. That said, we can still use ctrl+c which simplifies things.
> 4. Navigate to the destination(s)
> Move focus to all the controls/elements/components which might
> consume the clipped content.
>
> 5. Paste
> At all the destination places the clipped content is being pasted
> into the focused control.
> If there is need to paste the content into several controls the
> focus is first navigated to each of them and the clipped content is
> then pasten into these. For standard paste use Ctrl+v, for enhanced
> pasting use Shift+Ctrl+v (paste special...) where a user then
> selects how to procede.
OK so, it sounds like you are not advocating Shift+F10
> Alternativly provide context menu functions to: paste, paste
> special... or, within another sub menu, the functions to more
> special drag and drop features like "create reference or shortcut",
> "move", "copy". This menu might also, as proposed, provide a menu or
> a dialog to identify destination areas, as an option.
> In addition comes to the context menu, that RIA components might
> check if they accept the clipped content. If they do the context
> menu item "paste"/"copy"/"move" then are active. If the destination
> does not accept the clipped content the context menus hows the menu
> items as inactive.
>
> 6. Cancelling
> There is no need to cancel a drag and drop operation if it is
> implemented in conjunction with the clipboard cut/copy/paste design.
> There is no distinct stop for the copy and paste pattern, and from
> my point of view this copy and paste-related design might also help
> to avoid the cancellation of a drag and drop function where the drag
> and drop pattern requires distinct start and stop functionality.
>
Well, that depends if you want to move the user back to the source of the
selection. So, here
the models diverge. The group should discuss.
> I would not clean up the drag and drop clipboard space, because of
> applying the drop at serveral places. The space will be cleaned up
> with the next copy or cut trigger. As long as the clipped content is
> within the clipboard space the focus still can be moved and the
> paste actions can still be triggered.
>
This I disagree with. You have marked all targets that were chosen for drag
which the AT may wish to refer
to. Also, we have existing dropeffects to indicate to the AT which drop
targets are capable of receiving the drag source.
The ATs need to know which targets can receive the drop and what operations
they support.
> The styleguide should also clearly define these patterns, because
> they are required for all of the above.
> a) Keyboard navigation between controls (tab, shift+tab, ctrl+tab)
> b) Keyboard navigation within controls (arrow keys, home, end, ctrl
> +home, ctrl+end, etc)
> c) Selection (implicit selectin with arrow keys usage, explicit
> focus navigation by Ctrl+arrow keys, explicit selection toggle with
> Space or Ctrl+space)
> d) copy and paste keyboard keys: Ctrl+c, Ctrl+v, Ctrl+x, Shift+Ctrl
> +v, and for touch typers the old IBM styled keystrokes because these
> are more efficient to be used for users who navigate very much to
> apply pasted objects to the navigated target. (using arrow keys and
> pasting at serveral times).
>
I am posting this to the group. So, they can copy.
> Richard, I will be glad to dicuss and elaborate further on this
> topic. Should we do this in the open round of the wai list?
> I was not sure about, so I wrote this message directly to your email
account.
>
We have a WAI-ARIA working group meeting on Monday at 3PM EST which
unfortunately is 10PM
your time. You are welcome to call in. I am posting my response to your
feedback to the list.
Thank you!
Rich
> best regards, Oliver
>
>
> Oliver Keim
> Development Architect
> SAP User Experience Accessibility
>
> SAP AG
> Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany
> T +49 (6227) 7-41522
> F +49 (6227) 78-18394
> mailto:ok@sap.com
> www.sap.com
> Sitz der Gesellschaft/Registered Office: Walldorf, Germany
> Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO), Léo
> Apotheker, Werner Brandt, Claus Heinrich, Gerhard Oswald, Peter Zencke
> Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
> Board: Hasso Plattner
> Registergericht/Commercial Register Mannheim No HRB 350269
>
> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
> irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
> eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
> Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-
> Mail. Vielen Dank.
>
> This e-mail may contain trade secrets or privileged, undisclosed, or
> otherwise confidential information. If you have received this e-mail
> in error, you are hereby notified that any review, copying, or
> distribution of it is strictly prohibited. Please inform us
> immediately and destroy the original transmittal. Thank you for your
> cooperation.
>
>
>
>
>
>