W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2017

RE: Drag and Drop with Drupal 8

From: Sean Murphy (seanmmur) <seanmmur@cisco.com>
Date: Wed, 8 Nov 2017 00:03:38 +0000
To: Matt King <a11ythinker@gmail.com>, "'Jennifer Sutton'" <jsuttondc@gmail.com>, "'Mike Gifford'" <mike@openconcept.ca>, "'w3c WAI List'" <w3c-wai-ig@w3.org>
Message-ID: <9bffedb9b24c434891e2e0269b2dd905@XCH-RCD-001.cisco.com>
Matt,

Liked the concept you outlined. What about relationship? A applied relationship for objects I have seen implemented before  I have outlined below:

When you have a blank canvas and you are laying out elements. There is an relationship from the top edge (y) and the left edge (x) of the parent container. The top left hand corner of the child element is the reference point. The element will have a defined domention. For example using pixcels as the means of measuring which is just for example purposes to explain this concept which I have seen in Visual Basic 6 with Jaws for windows in the early 2000’s.

A container has 1000 pixcels across (x) and 1000 pixcels down (y). the person places a element (object) like a button  100 pixcels down from the top edge of the container () and 50 pixcels from the left edge (x). The screen reader says “50 by 100 pixcels for the button using the x/y coordinates. The screen reader knows the size of the button height and width in pixcels. If another object overlappeds the button, then the user is alerted of the new element being on top of the other element. In this quick example, there was extra information provided as well when objects were overlapped. This worked quite well for containers inside containers.

When I used VB6, this approach was quite usable and gave you an understanding where elements was on the page. The above would work with the concept you outlined as well.


[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/08_standard_graphic.png]




Sean Murphy
ENGINEER.CUSTOMER SUPPORT
seanmmur@cisco.com<mailto:seanmmur@cisco.com>
Tel: +61 2 8446 7751










Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Please click here<http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html> for Company Registration Information.







From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Tuesday, 7 November 2017 6:00 PM
To: 'Jennifer Sutton' <jsuttondc@gmail.com>; 'Mike Gifford' <mike@openconcept.ca>; 'w3c WAI List' <w3c-wai-ig@w3.org>
Subject: RE: Drag and Drop with Drupal 8

I’d be happy to help out with designing the Drupal accessibility implementation for this function. A bonus would be that we come up with a reusable pattern and example that I could incorporate into the ARIA Authoring Practices.

In ARIA 1.1, very soon to be final, we deprecated aria-grabbed and aria-dropeffectk. Net, they didn’t really seem to be helping solve the problems they were intended to solve, and the ARIA working group believes there are better approaches.

Similarly, early working drafts of ARIA Authoring Practices included some draft guidance for drag and drop. We didn’t have agreement on its veracity and utility. Given the huge backlog of much more basic issues with the guide, we removed it. We will publish a first release of the Authoring Practices before the end of this year, and it will not include drag and drop.

In the mean time, a task force led by Benetech is digging more deeply into this space. See:
https://github.com/benetech/DiagramDevelopers-DragAndDrop/wiki/DragAndDrop-Analysis


One goal of that work is to help figure out what, if anything, should be included in ARIA 2.0 to facilitate this type of interaction.

For the Drupal use case, I think the move and resize example Jennifer referenced that Jesse and Cordelia from Salesforce put together is a pretty good start for the interaction. The live region messages could use some refinement. And, it might be possible to make it work a bit more gracefully with some screen readers by putting the move and resize buttons in a toolbar:

<div role=”toolbar” aria-label=”Move and Resize”>
  <button>Move Block 1</button>
  <button>Resize Block 1</button>
</div>

By using toolbar, with Windows screen readers, you are more likely to end up in a mode where the screen reader will pass through arrow keys. Another option could be to use the application role instead of the toolbar role. We redefined application in ARIA 1.1, and I think this would be an appropriate use. However, I like toolbar better because it would allow the two buttons to be grouped in a single tab stop without requiring additional instructions. It would also facilitate extending functionality with more buttons.

When the “move block 1” button is pressed, I’d recommend changing the label on the button to “Moving block 1”. DOM focus would remain on that button during the moving process. And, during the move, aria-describedby could point to the element containing the live content that describes the current position of the block. It could also point to an element containing the instructions, e.g., press arrow keys to move the block. When the move is complete, the label would change back and the aria-describedby would be removed.

Given that the blocks getting moved around could:

·        contain content that screen reader users may want to read and navigate like a document

·        Could contain many focusable items

·        Could occupy variable numbers of cells in a virtual layout grid

ARIA gridcells or table cells might not be the most usable containers for the blocks of content getting moved around. ARIA grids are not ideal for content where the user may frequently wish to use reading mode (at least not the way screen readers currently implement their reading modes). And, table navigation functions are often confusing when the cells are irregularly shaped.

It is important that screen reader users be able to quickly navigate from one block to another, understand a block’s boundaries, position,  and dimensions, and be able to easily explore its contents. One approach that could accomplish this is to use a div for each block that has role region and a label that helps the user understand which block it is as well as its position. Some off-screen content that is contained in the block (preferably at the end) and referenced by aria-descirbedby that provides more detail about size and position would be helpful. That could be the very same content that is live when the block is getting moved or sized.

For non-screen reader users, it would be very helpful to have a way of quickly moving around the grid to choose which block to operate on. This is where the ARIA grid construct could be helpful. However, there are other ways to provide arrow key navigation among blocks without using an ARIA grid widget. For instance, we could add a “block chooser” button to the toolbar that is inside of each block. When pressed, it would highlight the block and visually indicate that pressing arrow keys moves the highlight around to different blocks rather than moving the currently highlighted block. If a screen reader user were using this, a live region that is outside the layout canvas could help the user understand which block is highlighted. At a DOM level, the focus would move from region to region, and when enter is pressed, the focus would land on the “block chooser” button that is inside the currently highlighted block.

Hth,
Matt King

From: Jennifer Sutton [mailto:jsuttondc@gmail.com]
Sent: Monday, November 6, 2017 11:54 AM
To: Mike Gifford <mike@openconcept.ca<mailto:mike@openconcept.ca>>; w3c WAI List <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Subject: Re: Drag and Drop with Drupal 8


Greetings, WAI and Mike:



This kind of Drag and Drop functionality is needed, more and more, and even if/when it's done right, I think it's so rarely done that I'm not sure screen reader users (only, here) will actually have seen it often enough to understand how to do it.



In Mike's issue, here, for easy reference:
            https://www.drupal.org/node/2920006


there's discussion of using ARIA grid. Again, grids are rare, and often not done right, so I'm not sure whether that would be necessary for drag and drop; it might be "over-ARIA-fication."

I'll add a few more links, below, but suffice it to say, in my mind, WordPress *may* also come to need this functionality, such as, perhaps, via the new Gutenberg editor. So, it would be great if folks could collaborate/learn from one another.

To that end, I'm bcc-ing some WordPress folks who, as far as I know, aren't on the WAI list. And I'm including some others who may have an interest/additional contributions.



To my way of thinking, user testing with a range of users will be essential to getting this right, but the CMSs are in an excellent position to serve as training grounds for end users + promote tested approaches.



There are several more links, below, perhaps for addition to Mike's Drupal issue. And good luck to all.

Best,

Jennifer



A discussion of four possible patterns -- post via SalesForce:

https://medium.com/salesforce-ux/4-major-patterns-for-accessible-drag-and-drop-1d43f64ebf09


This, from Shopify, which has been begun, but wasn't finished, last I looked at it:
https://shopify.github.io/draggable/


This SitePoint article by James Edwards that came out a while ago, but likely has concepts worth considering:
http://www.sitepoint.com/accessible-drag-drop/


And finally, this, related to Drag and Drop and React, which may not have much to do with accessibility, but does seem to have some useful usability concepts:
https://medium.com/@alexandereardon/rethinking-drag-and-drop-d9f5770b4e6b



On 11/5/2017 11:52 AM, Mike Gifford wrote:
We’ve built a bunch of great accessibility solutions in Drupal 8 Core, but we haven’t modernized our Drag/Drop solution significantly. Because of some great innovations with a Layout Builder, we’re having to work on a 2D solution to this problem.

We’ve got links to some terrific ideas here, but it seems that there isn’t a good best practice out there that works for grids or other complex spatial organization.
   https://www.drupal.org/node/2920006


We’re looking for examples of what we might have missed here.  Also, if there are folks interested in working on a common GPL solution to this, that would be amazing.

MIke
--
Mike Gifford, President, OpenConcept Consulting Inc.
Drupal 8 Core Accessibility Maintainer - https://drupal.org/user/27930

Twitter: @mgifford @openconcept_ca

Open source web development for social change - http://openconcept.ca

Drupal Association Member | Acquia Partner | Certified B Corporation




image001.png
(image/png attachment: image001.png)

image002.gif
(image/gif attachment: image002.gif)

Received on Wednesday, 8 November 2017 00:04:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 6 December 2017 16:04:47 UTC