Hi -

I'm creating a new issue here at the suggestion of mgifford related to this issue in D7:
http://drupal.org/node/448292

This issue is around how accessible (or not) the drag/drop implementation is for non-sighted or keyboard-access users.

I attended a workshop on accessibility by Dan Featherstone at Future of Web Design last fall and he talked about a very similar issue that you can see in Basecamp - same sort of pattern for drag/drop of to-do items, etc. His take was that rather than trying to tackle getting focus on a row and then using arrow keys - simply add up and down arrow elements that can be tabbed-to which when clicked, move the row in question up one position. It's a UI pattern that's pretty common when drag/drop is not an option, and more readily understood than 'weight'. It can also be pretty compact visually with a good 'title/tool-tip'. I would think that there might be a way to hide it from general visibility but expose them to tabbing via screen readers. (This last part might not be bulletproof, but you get the idea).

To further elaborate - the way the UI might work better (basing on the Basecamp idea) is for the drag/drop control to become visible when mousing over the row, also giving greater visual importance to a single icon for drag/drop rather than showing it on every row. This way small, discrete arrows to bump up/down one row at a time won't appear cluttered or redundant. I realize it's a big flip in the UI convention, but this would be a HUGE benefit in accessibility and also offer an improvement for 'normal' users to boot. I do think that having the drag/drop icons everywhere can be pretty 'noisy' and work to de-emphasize their importance - AND it would work better for touch-based interfaces that don't really have a 'hover' state at all.

Attaching a screenshot from Basecamp to illustrate the drag/drop capability. It unfortunately does not include an up/down arrow implementation. I'll do my best to mock up an example soon.

Jason

CommentFileSizeAuthor
drag-drop-example.jpg21.39 KBjpamental
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Frank Ralf’s picture

Frank Ralf CreditAttribution: Frank Ralf commented

Hi Jason,

That's definitely a great suggestion we should pursue!

You might consider changing the title of this thread as in its initial implementation that pattern might increase usability for sighted users but not be necessarily more accessible.

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented

This is a very interesting idea & I look forward to discussing it more for D8.

Is it possible to provide a mock-up of what this would look like?

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented

Note that in hierarchical controls (e.g. Menus, Taxonomy vocabularies, etc.) the drag and drop icon can move left/right in addition to just up/down. This doesn't seem to be covered in the basecamp implementation.

Frank Ralf’s picture

Frank Ralf CreditAttribution: Frank Ralf commented
Title: UI Pattern suggestion for better accessibility with current drag/drop interface implementation » Drag and Drop for table rows is not accessible to screen-reader users - UI Pattern suggestion

@webchick
That's right, but IMHO the principle is still valid, only showing the control if and when it is needed, e.g. on hover.

jpamental’s picture

jpamental CreditAttribution: jpamental commented
Title: Drag and Drop for table rows is not accessible to screen-reader users - UI Pattern suggestion » UI Pattern suggestion for better accessibility with current drag/drop interface implementation

First I have to apologize to Derek Featherstone - I seem to be incapable of remembering that his first name is Derek and no Dan. I have absolutely no idea why I can't keep this straight.

@webchick - I hadn't thought all the way through that aspect but I'd think we could work out a left/right (indent/outdent) as well as up/down. My thought was that since addressing non-sighted users in addition to those with fine motor skill issues (and all of the devices with touch interfaces) is an increasing percentage of overall users that it was worth bringing up.

@mgifford, @Frank_Ralf - I'll try to get a mockup of a possible solution together this week.

Jason

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented
Title: Drag and Drop for table rows is not accessible to screen-reader users - UI Pattern suggestion » UI Pattern suggestion for better accessibility with current drag/drop interface implementation

Can this be brought into D7 using the Accessible Helper Module?

jpamental’s picture

jpamental CreditAttribution: jpamental commented

@mgifford - It seems like a good place for it. I admit this dropped off my radar but I'll try to get a mockup together for better discussion.

Thanks!

Jason

Everett Zufelt’s picture

Everett Zufelt CreditAttribution: Everett Zufelt commented

I'm not sure how easy this would be to implement as a contrib module. The key function used to implement tabledrag is: drupal_add_tabledrag(). There does not seem to be a hook to modify the behavior.

From what I can tell a contrib module would need to either 1. Hack core implementations of this function to get them to point to a different function, or replace misc/tabledrag.js with it's own implementation.

bowersox’s picture

bowersox CreditAttribution: bowersox commented

+1 @jpamental, thanks for this great idea!

@everett, I agree that it may not be easy to override this in contrib. I suggest this approach: (1) use this issue to discuss and strategize about the optimal drag/drop interface; (2) then determine what can be done in D7/D8 whether by hacking, or in core or contrib.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented

Replacing misc/tabledrag.js should be pretty easy. We have a hook_js_alter() now.

I don't think we can in good consciousness radically revamp the UI for drag and drop in D7 core anymore.

Everett Zufelt’s picture

Everett Zufelt CreditAttribution: Everett Zufelt commented

@webchick

Agreed that we really cannot perform this type of modification to tabledrag in D7 core anymore.

Thanks for pointing out hook_js_alter().

Frank Ralf’s picture

Frank Ralf CreditAttribution: Frank Ralf commented

@webchick
Thanks for the hint regarding http://api.drupal.org/api/function/hook_js_alter/7

This page links to some implementation examples.

Everett Zufelt’s picture

Everett Zufelt CreditAttribution: Everett Zufelt commented
Title: UI Pattern suggestion for better accessibility with current drag/drop interface implementation » UI Pattern suggestion for better accessibility of table drag implementation
nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented
Category: bug » feature

Interesting but not a bug :D

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

now's the time brainstorm this #1524414: Rewrite tabledrag.js to use jQuery UI :)

Frank Ralf’s picture

Frank Ralf CreditAttribution: Frank Ralf commented

It's been a long time ...

Is the UI suggestion from the original post still valid as a role model?

Drag & Drop example inspired by Basecamp

gmclelland’s picture

gmclelland CreditAttribution: gmclelland commented

I guess for mobile displays we could change the drag icon to always be shown and then change that (with a media query) on the desktop to appear on hover.

Then we should probably move the edit and delete links into the dropdowns.

See the related issues
#1608878: Add CTools dropbutton to core
#1480854: Convert operation links to '#type' => 'operations'

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

A smallish sprint kind of thing will be made around tabledrag this friday, please post your ideas about what would be a better UX for tabledrag while keeping in mind that it has to work on mobile somehow.

Thanks.

bryancasler’s picture

bryancasler CreditAttribution: bryancasler commented

There seems to be a few scenarios a user might expect for table sorting depending on their input capabilities and experience. Likely a single UI will not meet all these scenarios.

  1. You hover over a row you want to move. You click/touch and drag the row to where you want it.
  2. You hover over a row you want to move. You click/touch a corresponding option on that row to bump it up or down in the sort.
  3. You tab to the row you want to move. You activate a corresponding option on that row to bump it up or down in the sort.

Some DnD UI
Gmail: http://snpr.cm/oSsPcV.png
Youtube Playlist: http://snpr.cm/ObiKYj.png
http://flexponential.com/samples/DraggableIconItemRenderer/DraggableIcon...
http://yuilibrary.com/yui/docs/dd/list-drag.html

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented
Priority: Normal » Minor

Any word on the output of the sprint?

An enhancement would be great. Neat UI. There is a working version for accessibility & table drag so bumping this down to minor.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

We ended up with that basically #1635416: Make drag & drop mobile friendly. Some overlap with #19.

If the accessibility part is ok, I guess we either rename this for broader scope of close it.

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented
Status: Active » Closed (duplicate)

I'm going to call it a duplicate of #1635416: Make drag & drop mobile friendly then. We'll want to do an accessibility review of that, but think we can move the discussion over there.