I think this is a bug with OOUI's DropdownInputWidget (or FieldLayout maybe). cc @Volker_E

Putting onto my radar.

Well this sure does look fishy. A non-visible but interactive control, and a visible 'non-control'/div which has been made interactive by using tabindex=0

And the summary field has tabindex=2, which explains why it has initial focus (possibly intentional)

I had a similar report on this but I couldn't figure out the problem: https://www.wikidata.org/wiki/Topic:U9h5wrvz22hmrlie

Thanks, @TheDJ – tabindex=2 might have sounded like a good idea, but is unintuitive from a normal keyboard user perspective. Will dive further into if there has been more explanation given to put it on "2" by default. Incremental tabindex is set on all elements, just DropdownInputWidget doesn't pass it through on the handle.
This needs to be fixed.

@Volker_E I think incremental tabindex is something we used to do and have since deprecated. It's probably just that it wasn't removed from all components after it was deprecated, and then when this was reworked, it broke ?

In T189610#4067723, @TheDJ wrote:

Well this sure does look fishy. A non-visible but interactive control, and a visible 'non-control'/div which has been made interactive by using tabindex=0

That can't be accessible I think...

It is harmless. The <select> element is hidden with display: none, so it is not interactive. We keep it there instead of <input type=hidden> to allow the browser to remember/restore the selection in case of back/forward navigation.

In T189610#4103562, @TheDJ wrote:

@Volker_E I think incremental tabindex is something we used to do and have since deprecated. It's probably just that it wasn't removed from all components after it was deprecated, and then when this was reworked, it broke ?

We use that in some forms (e.g. the deletion form, also the edit form), I don't think we've ever "deprecated" it. I don't know why it was done, perhaps it improved the behavior in some browsers popular in 2005 when this code was written. However, I would be wary of removing it, as various site scripts might rely on it. (E.g. inserting additional elements into the form that users don't expect to be tabbable, like buttons to insert canned edit summaries.) Let's not touch this if it's not broken.

In T189610#4089184, @Volker_E wrote:

Incremental tabindex is set on all elements, just DropdownInputWidget doesn't pass it through on the handle.
This needs to be fixed.

This is the real issue here, I think. JS DropdownInputWidget apparently doesn't support 'tabIndex' (PHP works fine).

Change 424156 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[oojs/ui@master] DropdownInput-/RadioSelectInputWidget: Fix support for 'tabIndex'

https://gerrit.wikimedia.org/r/424156

Change 424156 merged by jenkins-bot:
[oojs/ui@master] DropdownInput-/RadioSelectInputWidget: Fix support for 'tabIndex'

https://gerrit.wikimedia.org/r/424156