Re: Drag and Drop with Drupal 8

Thanks Matt,

> On Nov 7, 2017, at 1:59 AM, Matt King <a11ythinker@gmail.com> wrote:
> 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.

That sounds great! 

> In ARIA 1.1, very soon to be final, we deprecated aria-grabbed and aria-dropeffect. 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.

Ok, good to know. Often developers gravitate to things like that (as they sound like they should work).

> 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.

Makes sense. 

> 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 <https://github.com/benetech/DiagramDevelopers-DragAndDrop/wiki/DragAndDrop-Analysis>
I added that to the list of projects here:
 https://www.drupal.org/node/2920006

> 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.

Cool

> 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>

Something like that might be possible. 

> 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.

Excellent. 

> 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

Would be great to have this in the issue queue.  Can you bring it over there?

> 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.


The first step is to define were we want to go and provide examples that are worth following.

We can then see what we can do to bring those best practices into Drupal’s behaviour.

It was great to hear GitHub’s Project Pages and moving their cards.

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