(react-aria-components) Dropzone with FileTrigger has an unnecessary tab stop for keyboard users

[wmaurer]

Provide a general summary of the issue here

The Dropzone with Filetrigger has an extra non-functional tabstop. https://react-spectrum.adobe.com/react-aria/DropZone.html#filetrigger

🤔 Expected Behavior?

When navigating with the keyboard, Dropzone with FileTrigger should have one tabstop, which when 'pressed' with the keyboard opens the "Open File" dialog.

😯 Current Behavior

When navigating with the keyboard, Dropzone with Filetrigger has a tabstop an outer button, which is focused but has no functionality - pressing the button does nothing. This is confusing to keyboard users.

💁 Possible Solution

No response

🔦 Context

No response

🖥️ Steps to Reproduce

Click just before the Dropzone with Filetrigger at https://react-spectrum.adobe.com/react-aria/DropZone.html#filetrigger Press tab. Dropzone is focused & highlighted but has no press functionality. Press tab again. "Select File" button is focused. This button has press functionality.

Version

react-aria-components version used on https://react-spectrum.adobe.com

What browsers are you seeing the problem on?

Microsoft Edge

If other, please specify.

No response

What operating system are you using?

Windows

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[yihuiliao]

The reason for this outer button is so that DropZone can be accessible for keyboard/screenreader users. It might not have the functionality you’re expecting but it allows for those using screenreaders to hear the accessible name. It’s also what allows for objects to be dropped onto the DropZone since this visually hidden button is what receives dropProps.

The idea behind when we thought of combining a FileTrigger with DropZone is that users can both drop objects onto the drop zone and open up the file system easily if needed. However, the FileTrigger, by itself, does not have the capabilities to be “dropped on”, and I don’t expect that we will add that functionality in the future.

In the use case that you are suggesting, I worry that there would be no way to actually navigate to the dropzone when dropping an object without opening the file system.

[wmaurer]

I understand the motivations behind making the component accessible for screenboard users. However the implementation has negative consequences for keyboard users. As a committed keyboard user:

• I don't hear an accessible name, because I'm not using a screenreader. I navigate visually but not with the mouse or touchpad
• I'm not interested in the DropZone - if I'm navigating with the keyboard, I will be opening the file system dialog
• With the current implementation, I see the outer button highlighted and press ENTER. Nothing happens. I have no idea that I would need to TAB a second time to get to a second button, so I think the UI is broken.

My feeling is that the composition of FileTrigger and DropZone does not provide the correct experience for keyboard users, and that the FileTrigger should be able to dropped on.

[reidbarber]

FileTrigger should be able to dropped on.

I think this is a separate issue, and is definitely a reasonable request considering this is how native file inputs work. Also, we could turn this off if a FileTrigger is inside a DropZone, so it doesn't behave like nested droppable areas.

If we do this, I think there are two things we would need to be aware of:

• The type for onSelect is currently (files: FileList | null) => void. Since we can't create a FileList programmatically, we would need to change this to something like (files: Set<File>) => void.
• You can't programmatically set the values of file input elements (it would usually be the name of the first file)

---

When navigating with the keyboard, Dropzone with FileTrigger should have one tabstop

I think this is something we could do, but we would need to be intentional with handling all the scenarios:

DropZone with FileTrigger:

When not in virtual dragging mode: Focus goes straight to the FileTrigger. DropZone isn't focusable. When in virtual dragging mode: Focus goes to the DropZone. FileTrigger isn't focusable.

We would need to ensure that the DropZone's label is read by assistive technologies.

DropZone without FileTrigger:

When not in virtual dragging mode: Focus goes to the DropZone. When in virtual dragging mode: Focus goes to the DropZone.

[wmaurer]

Thank-you @reidbarber for your comments on this. I'm glad to you agree that FileTrigger should be able to be dropped on.

I am not an accessibility expert, simply an enthusiastic keyboard user. You obviously have more knowledge of the accessibility aspects - I had no idea there was such a thing as "virtual dragging"!

I am curious to know what the use case is for a FileTrigger inside a DropZone? If the FileTrigger can be dropped on, then why would a DropZone be needed?

[reidbarber]

To add some context, "Virtual dragging" is essentially our non-mouse "drag and drop mode" described here:

Users can press Enter on a draggable element to enter drag and drop mode. Then, they can press Tab to cycle between the drop targets that accept the dragged data, then press Enter to drop. Escape can be pressed at any time to cancel. Touch screen reader users can also drag by double tapping to activate drag and drop mode, swiping between drop targets, and double tapping again to drop. Screen reader announcements are included to help guide the user through this process. All of this is built into the useDrag and useDrop hooks, and components such as DropZone.

From: https://react-spectrum.adobe.com/react-aria/dnd.html#interactions Related blog post: https://react-spectrum.adobe.com/blog/drag-and-drop.html

I am curious to know what the use case is for a FileTrigger inside a DropZone? If the FileTrigger can be dropped on, then why would a DropZone be needed?

I think it is a somewhat common design for dropzones to also include a button or link that opens the file picker (This is included in Adobe's Spectrum dropzones). Plus the dropzone may need to include interactive elements, so using a FileTrigger as a dropzone wouldn't work for that use case.