[file] Figure out the right focus model for <input type=file>

[emilio]

In #92 I'm reusing the setup that at least Gecko, WebKit and Chromium have, which is that the whole <input> is focusable atomically, and the <button> is not tab-navigable.

It seems focus delegation could be used instead and may be more intuitive for users, but that makes type attribute changes quite painful.

[aneeshack4]

Looks like this is something we can add to agenda to discuss in the next telecon?

[gregwhitworth]

@aneeshack4 for sure, it would be good to have some research & discussion prior to that however. @aneeshack4 or @emilio do either of you want to do a review of component libs, WIA-ARIA, UAs and Mac/Windows to see what the common paradigm? You can just produce a table similar to the one in issue #102

[aneeshack4]

@emilio @gregwhitworth
In between meetings right now, getting this research started... will finish filling out this table tonight.

Focus for file input when tabbing:

Name	Mozilla	Ant Design	AtlastKit	Carbon	Evergreen	Lightning	FAST	Semantic UI	Fluent	WIA-ARIA
<input>	✔	❓	not a control, just a pattern	❌	✔	just spans	N/A	N/A	N/A	❓file upload state spec doesn't mention focus
<button>	❌	✔	N/A	✔ but it's span of role button	✔	just spans	N/A	N/A	N/A	❓

The usage of <input> and <button> to create file pickers isn't consistent - not everyone has both or either... I personally liked Evergreen's the best because it allowed tab focus on both and it was clear, nothing was excluded on tab stops.

More details:
Looks like Ant Design has its <button> and <input> in the same span and it's hard to tell if focus is going on the input too:

whereas MDN/Mozilla doesn't have a <button> and the focus just has one tab stop on<input>

Carbon doesn't have a <button> either and their <input> gets the sole tab stop - on tab only the span of role button gets the focus rect:

Evergreen allows focus on both the <input> and the <button> separately:

Lightning doesn't have a <input> or <button> just spans:

Mac: it's just a single push button that opens a file picker and the focus is placed on the button - though I can't inspect like on web to see the underlying structure. There is HIG guidance on these push buttons. I believe the UIDocumentPickerViewController is most commonly used in native. As far as I understand, it's similar for Windows - just one button with label text inside and there's only one tab stop.

[gregwhitworth]

Thanks for this, to add an additional one Chromium browsers have a single tab stop.

whereas MDN/Mozilla doesn't have a and the focus goes on the whole

This is because the input is a replaced element. It does have a button it just isn't rendered in the dev tools. So it getting one stop is consistent with Chromium. IE11/EdgeHTML both had two tab stops for this control. While it won't cause interop issues now it does raise that there are others that may have thought two stops had value.

@aneeshack4 When you say "whole" or "button" - does "button" mean that it had 2 tab stops or that it focused only the button and not the entire control?

[melanierichards]

IE11/EdgeHTML both had two tab stops for this control. While it won't cause interop issues now it does raise that there are others that may have thought two stops had value.

We did receive feedback in EdgeHTML that keyboard users would prefer one tab stop for file inputs, as that was more efficient when tabbing around content. Revisiting the semantics/keyboard experience was on our investigation backlog before moving to Chromium. Granted, there may be some selection bias here: the feedback was ad hoc, vs through a user study where both options were presented, so we wouldn't have heard from people who may have been happy with two stops.

[aneeshack4]

@gregwhitworth Thanks for the clarifying question - I just corrected it to remove the usage of the word whole as it's confusing - replaced it with 1 tab stop.

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

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

[andrico1234]

Closing based as this issue was resolved in a Telecon