Keyboard accessibility

[iamjolly]

The examples need to have draggable elements that are focusable and actionable by the keyboard (some people cannot use a mouse!).

[renatoi]

Either remove statements that the solution is accessible or actually make it accessible.

[drewlee]

Please don't make the claim that this library is accessible. This claim is quite misleading, as there are more than a handful of factors that make an experience truly accessible (keyboard support is just one of them). ARIA alone isn't a panacea, and I'm not sure how it would help in this case since drag and drop related attributes have been deprecated from the WAI-ARIA spec.

[ghost]

I can just about scroll the page without a mouse, but that is it.

[mikeyil]

I'm trying to figure out what they mean by accessible on the claim they've made.

[aut0poietic]

I found the lack of keyboard support pretty disappointing as well -- I got very excited when I initially read it.

@drewlee I've been struggling with this in my own DnD library. Both aria-dropeffect and aria-grabbed exist in ARIA 1.1 (which is still only a candidate recommendation). The spec says they intend to replace them in a future ARIA version and to treat them as deprecated. But for now, they're valid and they're all we got.

Worse, W3C have removed the Drag & Drop section from the Authoring Practices 1.1 and appear to be struggling with how to handle it. I can't imagine they want to truly deprecate a technique without a replacement -- especially when most browsers still support the 1.0 req.

Thinking about forking and taking a stab at adding keyboard access. I'll use the following keymap:

• space to select
• enter to place
• ctrl+m as fallback (via the old 1.0 req. that no one knows or uses)
• arrows to cycle position within a group (horizontal/vertical must be specified)
• tab to switch groups (when there is more than one group)
• esc to cancel

If I can't find time to do this, perhaps this will provide the authors with a starting point for planning their own implementation.

[tsov]

Sorry for the late reply, the plan was always to have accessibility support right out of the box, but we did not have time to add support before the initial beta release, nor did we realize how much impact this project would have.

We also mentioned, in the Interaction section of the website, that keyboard support is coming soon. ;)

The next beta release will contain a handful of performance improvements, touch improvements and accessibility support.

also @aut0poietic thank you for providing an overview of the keymaps 👍 Expect for using enter to place, we were thinking of using the same ones.

I will keep this PR open until we release v1.0.0-beta.2

[tsov]

Quick update on the Keyboard Accessibility progress:

We have divided the work up into 3 parts:

• Focusable draggable containers and elements (be963a0)
• An announcement api that allows users to specify messages on events (a703bc1)
• A keyboard sensor that listens for keyboard events to initialize drag operations (5360c32)

Focusable Plugin

• Commit
• Documentation

We built a plugin that makes draggable containers and elements focusable, if they aren't already. It also decorates the draggable elements with aria attributes if there are none present already. This commit hasn't made it into master yet, but could potentially be merged soon.

Announcements API

• Commit
• Documentation

We built another plugin that hooks into draggables event emitter to allow users to define their own announcements per event, e.g.

new Sortable(containers, {
  announcements: {
    'drag:start': 'Draggable has been picked up',
    'drag:stop': 'Draggable has been dropped',
    'sortable:sorted': 'Draggable has been sorted',
    // or dynamic messages based on event
    'drag:start': ({source}) => `${source.getAttribute('data-title')} has been picked up`,
    'drag:stop': ({source}) => `${source.getAttribute('data-title')} has been dropped`,
    'sortable:sorted': ({source, over}) => `${source.getAttribute('data-title')} has been swapped with ${over.getAttribute('data-title')}`,
  },
});

This should provide enough flexibility for defining your own announcements.

Keyboard Sensor

• Pending Commit

Similar to the other sensors (MouseSensor, TouchSensor, etc), the keyboard interactions will be handled with a KeyboardSensor. The sensors responsibility will be to dictate the drag behaviour, e.g.

1.) Start dragging on focused draggable element on space or ctrl+m
2.) Reorder draggable element on left/right arrow keys
3.) Stop dragging on space or ctrl+m

This part ^ is still a work in progress and still needs to conform to the keymap @aut0poietic outlines.

I am hoping to get this in before the end of this year, but would love to get some 👀 on the solution too. Would anyone be interested in reviewing the changes before merging them into master or the next beta?

[svinkle]

@tsov This is awesome! I've left a few comments. I'll be happy to give this a run-through when available. Great work!

[mgifford]

Has this been applied yet to the demo https://shopify.github.io/draggable/

Would be love to see examples of this there. I don't think that's been optimized for keyboard only users at this point.

[adam-h]

@tsov The KeyboardSensor looks like a great solution, do you have any update as to its status? It looks like both of the other components to this are already in master.

[shivakumaravula]

@tsov We are struggling with the implementation of accessibility. Can you help me in providing a example that works or point me in the right direction please.