Definition of anatomy for selected files

[gregwhitworth]

This was resolved on in the telecon, but a scenario was brought up related to when files are selected.

RESOLUTION: When there are no files currently selected there will be one tab stop for the entire file control

So I will close this out and spin up another one to discuss that one as that will need an anatomy adjustment.

Originally posted by @gregwhitworth in #107 (comment)

[gregwhitworth]

To be a bit more crisp, in that telecon the scenario was brought up that it is common to be able to modify the selected files to potentially upload once they are selected. So we need to investigate the usecases for this scenario and determine if there needs to be any adjustment to the anatomy or event definitions.

@mrmckeb offered to take a first run at the research to make a proposal.

[mrmckeb]

Native behaviour

Using the multiple attribute allows a user to select multiple files for upload. The selection happens through the system UI. None of the major browsers (Chrome, Edge, Firefox, Safari) allow any interaction with selected files, and they don't provide information other than the count of files selected.

Chrome, Edge, and Safari

Firefox

When files are selected, clicking the file input again will open the system file selection window again. If the user cancels this action, the previous selection is only retained in Firefox and Safari. Chrome and Edge will show that no files are selected for upload.

Libraries and other examples

The most common pattern is to immediately upload files to a server and to append those to a list, keeping the input at the bottom of the list.

In this pattern, each file can be deleted (the server is responsible for completing this action).

The below table ignores libraries that were marked as N/A in #107.

Feature	MOJ	GitHub	Ant Design	Carbon	Evergreen	Materialise	Bootstrap
Immediate upload	✔	✔	✔	✔	✔	✔	✔
Multiple files at once	✔	✔	✔	✔	✔	✔	✔
File list	✔	✔	✔	✔	❌	❌	❌
Links to uploaded files	✔	❌	❌	❌	N/A	N/A	N/A
Rename uploaded files	❌	✔	❌	❌	N/A	N/A	N/A
Delete uploaded files	✔	✔	✔	✔	N/A	N/A	N/A
Navigation	Tab	Tab	Tab	Tab	N/A	N/A	N/A
Drop target	Input	Input	Input (optional)	Button (Optional)	❌	Input	Input

Notes:

• These examples don't deal with limitations on the number of uploads allowed.
• In most examples, it's not clear that files are actually being uploaded immediately. This could be a privacy concern for some users.
• For those that uploaded immediately, most had progress indicators.
• It wasn't always visually clear if drag and drop were supported.

---

Ministry of Justice (UK)

Although it's hard to find references that aren't behind authentication, this implementation mirrors the patterns used by governments and banks (and similar), where multiple images or documents are being submitted.

This example also indicates progress of uploads, and makes it clear that files have been uploaded.

Each row is a div, with a dd wrapping each the a (link to file) and button (delete) elements.

---

GitHub (attaching binaries to a release)

When selected, the dropzone visually changes to a standard file input. Can rename files.

Below, the input is in focus.

GitHub opted to use an unordered list.

---

Ant Design

Input stays above the list, no ability to rename/open files. Last input in focus in the below example.

Only div elements are used for the list.

---

Carbon

Input stays above the list, no ability to rename/open files.

Only div elements are used for the list.

---

Evergreen

Uses a readonly file input beside a button, operates as a native file input.

---

Materialise

Files are not uploaded to the server immediately, and names are displayed.

---

Bootstrap

A styled native file input.

---

Thanks to my colleague and friend Meaghan Li for her input into this research.

[gregwhitworth]

Thank you so much for this @mrmckeb - this is wonderful.

Chrome and Edge will show that no files are selected for upload.

Ironically I worked on an interop bug for EdgeHTML that depended on this behavior, and yes I find this an odd behavior (here is the bug from 2016). We should tackle this once we get to eventing for file.

For all of the libs and the examples you showed, did the list of selected files container reside in the same containing parent as the button that toggled the file picker? Effectively, does this anatomy still hold true based on your research?

Based on what I see I think we're going to have to allow a slot to be around the label and possibly change the name of that as well since it seems the majority of web properties to match the browser solutions in being simple strings.

[mrmckeb]

Thanks @gregwhitworth.

I've confirmed with those that use a list, and yes - that's correct. The input and list are siblings.

There were no examples where the input is a child of the list, or any other approaches. But they may exist... If anyone has a different example, that would be great.

[gregwhitworth]

Thanks @mrmckeb - based on that I don't think the anatomy needs to change. Also, based on the previous resolution no focus spec text needs to change. It seems that we're at a 50/50 split (if we include browsers to your matrix above) of listing them out with actions. I do recall @levithomason saying that Fluent is moving to the model of listing them out with interactions on each file. I think it's worth having the discussion around whether a file input's anatomy should adjust to have the name and delete button part in an unordered list if more than one is selected.

cc: @emilio @heycam

[gregwhitworth]

oh, also @mrmckeb - what is the behavior like for the ones that list them out?

• When you add more than one file does focus move to them by default?
• What happens when you hit the tab key (eg: does it move to the first selected file input then the delete button [if one exists])?
• If you enable an AT what is spoken alloud?

[mrmckeb]

Hi @gregwhitworth,

1. The focus remains on the input.
2. Tab doesn't seem to be controlled. So, if the list is below the input, then yes. The MOJ example has the list above, so you'd need to shift tab to delete.
3. The screen reader only indicates that the upload input is in focus again. No information about the files is provided unless the user navigates to those. The button label for delete is generally "Delete", or "Clear file" in Carbon's case.

[gregwhitworth]

Ok, I think this then raises another question then. All of them do not move focus to the selected files by default. It sounds like there are no aria-live regions or similar associations to inform the user of changes.

Ok, so it seems that there is NO need to adjust the current anatomy as defined. One last question, can you take a glance at social media sites, email, etc to see how they handle this? Because none of them that I tested follow this anatomy structure, they're actually quite disjointed. Do they all leverage the file input hack?

Doing a quick search of MDN, WHATWG, etc there doesn't seem to be an API to invoke the explorer and allow for this without the file input hack. I think we may want to consider having this as the default anatomy but also denoting that the parts at times can be disjointed. I also think that we should, if one doesn't already exist - recommend an API to invoke the file window. This would allow this disjointed behavior while still be able to be explicit in how to handle them.

Now we'll need to discuss if there is a way in which to join these declaratively. I'm going to cc in @una @dandclark @mfreed7 @chrishtr @melanierichards just in case they know of one that I don't and also since they're looking into these controls/components from a web platform level.

[gregwhitworth]

Ok, so there is one underway with the Native File System API currently in the WICG.

I think we should handle this scenario. Ultimately the parts are the same and I'd expect the accessibility recommendations to not change on placement. Ultimately this is effectively stating that the parts may not be of the same host element. We should possibly come up with a standardized way to denote the relationship of this. We have the for attribute which may be sufficient. At any rate, @mrmckeb want to think about how the current spec could be adjusted to handle this disjointed scenario?

[gregwhitworth]

We just discussed this on the telecon and @mrmckeb updated everyone on the research. The question that I raised near the end was that the majority of the usecases include a list with an additional part for removal of that item. I'll provide an updated proposed anatomy to represent this and we can resolve on the next call.

Additionally, it seems that there is a common need to have a file appear in a separate location in the DOM, not directly adjacent. I'll open a new issue regarding that.

[mrmckeb]

@gregwhitworth I did a quick review of social media sites, but couldn't find any real examples of this either. They were fairly inconsistent (although the new Facebook and Twitter experiences were similar to each other), and they also didn't make use of aria-live.

All of the social media sites I reviewed used hidden file inputs, as does Gmail. None of the examples I found had improved semantics.

I think an API would be great to have, and I think it's clear that this is a big missing feature from the web today - which as you mentioned, is why the Native File System API is in development. This is a really welcome addition.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.