@carmacleod If I understand correctly, you have removed the variant that the list entry (role=option) has DOM focus. I think that is wrong. Our discussion was about what happens if the option does not have DOM focus. But with DOM focus, the option should also be considered selected (aria-selected=true), regardless of the tabindex. In practice, DOM focus and tabindex will usually coincide, but this does not necessarily have to be the case. My suggestion would be to reinsert "has DOM focus or".

@spectranaut

Two reasons for leaving "has dom focus":

1. this was in it so far, removing this now would make it no longer compatible with old versions.
2. if a list entry has dom focus, the other conditions don't necessarily have to be met (e.g. focus can be set via JS without tabindex=0 at the list entry). The new conditions were only added so that the selected item can be determined even if the item does not have the focus.

But I don't mind if dom focus is removed either. In the end it's just about providing a repair mechanism when no aria-selected is used

I think more work is need to avoid hidden or inert elements that still match this criteria... It may be as simple as adding, "…and are not hidden or inert…" but I'm not in a position to consider prose suggestions deeply at the moment.

@cookiecrook question b/c I have no idea how this is implemented in browsers -- how important is it to specify that hidden/inert options are not implicitly selected if they aren't exposed anyway? Just from an authoring standpoint, I don't think I would care about that detail unless future AOM stuff makes it possible to somehow query the implicit selection of an ARIA listbox.

I do agree with @JAWS-test that disabled options should not get implicit selection no matter what.

what happens if all options are set to tabindex 0+? everything is selected? that seems wrong.... but also, trying to guess at which is the correct selection is more wrong.

Closing this PR, since #1719 was merged