So there’s a new article on native HTML5 drag and drop.
How did this article get published without any thought to keyboard? It’s just bunches of divs that work with mice?
I’m not creating a disqus or facewaste account just to comment on the article directly.
Good question. For me, I’m almost always a mouser, and unfortunately that often means I need to make a conscious effort to even begin considering keyboard use.
TBH I’ve never thought of “drag drop” as being a keyboard thing. That is, more of an “enhancement” for those that could, while (hopefully) not being essential for those that couldn’t.
But I think drag-drop could be approximated using some kind of JavaScript select - move type of code.
Of course that would likely be non-trivial and not “native HTML5” eg.
Good question. For me, I’m almost always a mouser, and unfortunately that often means I need to make a conscious effort to even begin considering keyboard use.
TBH I’ve never thought of “drag drop” as being a keyboard thing. That is, more of an “enhancement” for those that could, while (hopefully) not being essential for those that couldn’t.
Mobiles and tablet usage is increasing daily so designers should ultimately test on portables rather than just dragging a sidebar on their ginormous screens and feel proud that the page is responsive.
This response is from a tablet. Selecting text and trying to select a username from a popup that disappears off the screen is not easy.
Also as mentioned numerous times zoom is disabled…
Edit
Ironically the article zooming works but not on this forum?
That’s unfortunate, because you’re missing out on the opportunity to ask the author directly.
I’m pretty sure the low-ish barrier of creating Yet Another Account gets many people missing that opportunity.
However I’m also aware that it’s a sane response to butt-loads of spam.
I’m just surprised that basics of web standards aren’t even mentioned in the article (like, “These examples are purely mouse-based, but keyboard is an important input device that shouldn’t be forgotten, Sitepoint has another article focussing on that [link-to-brothercake over here]” or something.
Might be only my poor opinion but to me it’s similar to someone explaining some Javascript and doing bad practice stuff like lots of global variables or inline event handlers with href=“javascript:void” stuff. It doesn’t mean their article is useless but it does mean some more copyediting-feedback ought to get back to the author.
For you and many other developers-- so it helps them do the right thing in following web standards if they at least get reminded of it when learning new stuff.
Thing is, my new job has me reviewing material being created for schools, where drag and drop (whether using the native HTML5 api or just javascripting the crap out of some divs) are being created as the sole method a student has to demonstrate knowledge (matching labels to either images or appropriate topic groups is actually a pretty popular method, even back when it was always on paper). That developers for our curricula would be looking around for Drag-N-Drop articles when tasked with creating a course test means they need to get reminded of whatever limits there are to the technology (just as the article rightly mentioned some browser support issues) and this has to include access. In my case I’m talking about education, which already has lots of various barriers but it’s kinda cool to see how that can be made better by moving more stuff into the digital realm… so long as we stick to the web standards. WCAG is a standard and it’s not really any more optional than valid HTML or secure Javascript (that WCAG is called “guidelines” is more a reflection of “you need to do these things but we’re not going to demand how you do them, just recommend possible solutions and ways you can know if you did it well”).
Looking at brothercake’s article, it sure looks like it’s more work at the moment. It does still use the native HTML5 API, just adds some other things on top of it. So I’d call it “Modified HTML5 Drag and Drop”.
In any case, I don’t necessarily expect the author of the more recent article to add in all the keyboard stuff, as it’s trying to stick more to the basics of the API, but I do expect a mention and maybe a link to the other SitePoint article.
Hi guys.
I’m the author for the drag and drop article that you’re taking about (sorry for the lag @Stomme_poes, @Mittineague, @John_Betong , I wasn’t getting forum notifications)
In regards to drag, drop and accessibility overall my article’s primary focus was on how to use the native drag and drop functionality to handle data collection and manipulation.
Traditionally, the main focus on drag and drop has been with devices that are capable of dragging and dropping easily such as mice. The native API introduces several moderately complex concepts and outlining them along with additional factors to make it work on keyboards / other accessibility enabled devices would have made the article overly complex.
I actually looked into the process of adding support for the varying aria roles and elements but overall I felt the core concepts would get lost.
On another note the support for the native API on mobile is actually non existent so I don’t even think of mentioning that the examples and concepts won’t work on them (you could perhaps polyfill them with jQuery UI but considering most of them interact with the “data” of objects it might be a bit of a waste)
Thanks for the feedback / thoughts though guys!
“In any case, I don’t necessarily expect the author of the more recent article to add in all the keyboard stuff, as it’s trying to stick more to the basics of the API, but I do expect a mention and maybe a link to the other SitePoint article.”
And when there are limits on an API (such as keyboard and mobiles/touch), the first paragraph could mention these facts. As a reminder to developers who are googling these things.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.