Hacker News Reader

Comment by callum85 | Hacker News Reader

I wouldn't want a DnD library to magically 'implement' accessibility for me. How would that even work in a one-sizzle-fits-all way? If I'm building a UI that needs both mouse interaction and keyboard interaction, I want to consider and build both those things, not expect all the keyboard stuff to happen automatically because I used a library to manage mouse events.

EDIT there's a bad autocorrect in there but I'm going to leave it

View on HN

Just wondering if this library provided keyboard access only manipulation, would you have expected it to provide mouse events?

I'm biased on the keyboarding should be required perspective: I deal with accessibility day in and day out, and a library such as this had to be ripped out and removed from the organization, simply because junior developers would prototype and ship without thinking about that required use-case of keyboard access.

> I want to consider and build both those things, not expect all the keyboard stuff to happen automatically because I used a library to manage mouse events.

I understand what you're saying and commend you for it, but other developers might not want to implement all that themselves, or more often than not, might not even be aware that they have to. In other words, a JavaScript library with zero accessibility features gets added to one hundred websites over night, and in an instant, you have one hundred inaccessible websites. It is an all too common pattern in recent years, as most projects, even the big ones, don't even include accessible examples.

But this is a library. It's not a drop-in 'sortable list' component (which I agree could, and should, have built-in keyboard accessibility). It's a general purpose toolkit for setting up drag interactions.

Asking if it 'implements' keyboard accessibility is like asking if a box of hardware tools implements wheelchair accessibility – it might be possible to build something wheelchair-accessible using the toolbox, but that's up to you.

I completely agree that there are lots of devs who won't consider accessibility when using this or other DnD libraries, and that's a shame, but it's not the place of a DnD library to magically create an alternative keyboard UI that somehow corresponds with whatever drag-and-drop UI you've built using the library. That just couldn't work. A human needs to think about it.

You make some good points, and I agree that my original question, as it was phrased, isn't the best fit for a library such as this. Perhaps, what I should've asked is whether the demo, which developers will use as a jump-off point, implements any keyboard accessibility (it doesn't, by the way, so I'm not hopeful that any projects using this will be keyboard-accessible).

Author here. It's really easy to do. I implement tons of keyboard accessibility alongside dragula in my projects. In the demo it just felt out of scope. In one project I use dragula for a sprintboard, where you can cancel drags with Esc, drop with Enter, and move cards manually across columns with the arrow keys or a shortcut for each column (e.g 'o' for open)

So yeah, it's not part of the lib but it's deadbrain-easy to add on top.

Reply on news.ycombinator.com