Bug: First element in listbox should receive focus

[wagnermaciel]

The Scrollable Listbox Example does not match the behavior described by the Listbox Pattern Keyboard Interaction docs.

Expected

According to the docs, "When a single-select listbox receives focus, if none of the options are selected before the listbox receives focus, the first option receives focus."

Actual

In the example, the listbox itself receives focus.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Bug: First element in listbox should receive focus.

The full IRC log of that discussion

<jugglinmike> Topic: Bug: First element in listbox should receive focus
<jugglinmike> github: https://github.com//issues/3138
<jugglinmike> Matt_King: There's a discrepancy between the implementation and the guidance for the scrollable listbox example
<jugglinmike> Matt_King: The pattern says the first item should receive focus. I think that's probably correct guidance
<jugglinmike> Matt_King: The problem here is that there isn't an item in the list that says "choose your favorite element" or "choose value" or something like that
<jugglinmike> Matt_King: If we focus the first item, it would amount to choosing the first item for the user by default
<jugglinmike> Matt_King: This kind of has more to do with the design of the example. If you focus the first one by default, that means there's a default favorite
<jugglinmike> Matt_King: So I'm wondering if a better fix is to add an option to the beginning of the list--one labeled something like "Choose an element". That coul get selected by default.
<jugglinmike> howard-e: For me, it does feel right to support what the bug reporter said. A placeholder or "option zero" could be good here. Provided it was styled appropriately
<jugglinmike> howard-e: That is--a "disabled look"
<jugglinmike> arigilmore: The dropdown implementation in my company's UI framework may be relevant...
<jugglinmike> Adam_Page: In the original bug, the reporter quoted the keyboard interaction instructions, but only partially
<Matt_King_> Preview of proposed fix: https://deploy-preview-362--aria-practices.netlify.app/aria/apg/patterns/listbox/examples/listbox-scrollable/
<jugglinmike> Adam_Page: They did not include the final statement in the text they referenced. That statement reads, "Optionally, the first option may be automatically selected."
<jugglinmike> Adam_Page: We could update this so that we don't automatically select it, we just require the press of the "space" key
<jugglinmike> q+ Lola
<jugglinmike> ack Lola
<jugglinmike> Matt_King: My concern is that if there is nothing selected, then--JAWS and NVDA would normally announce the label of the list box without speaking a value because no value is selected
<jugglinmike> Matt_King: If there's an item focused that isn't selected, is it going to be somehow represented as the value of the list box?
<jugglinmike> Matt_King: I'm unable to test the current behavior using JAWS and Chrome at this moment; I don't understand why that is...
<jugglinmike> Matt_King: In NVDA, when I navigate to the listbox, it says, "List clickable neptunium". It doesn't tell you whether it's selected, which is interesting
<jugglinmike> Matt_King: If I select a value, tab out, and then return...
<jugglinmike> Matt_King: In NVDA, there's no way to read the ones that are not selected in a single-select list box, so there isn't a distinction between focus and selection
<jugglinmike> Matt_King: I know I've seen other implementations with a placeholder value which represents the empty value
<jugglinmike> Matt_King: That's why I was wondering if that could be the answer for our implementation, and I even kind of wonder if the pattern should say something about it
<jugglinmike> Matt_King: Is that common practice in your experience, Adam_Page?
<jugglinmike> Adam_Page: I think so. This particular use case is probably something I would discourage from a UX perspective because it presents options to the user, but it doesn't give them a user a mechanism for removing their selection
<jugglinmike> Adam_Page: To get out of that, the UX recommendation is usually to add an option which represents "no selection"
<jugglinmike> Adam_Page: It seems like a fix for this particular issue, but it kind of kicks down the road the question of whether this is a valid use case (where nothing is selected by default and there is no way to remove a value once one has been selected)
<jugglinmike> Adam_Page: We could either pattern change this pattern to be more realistic, or we could let this example continue to exist as it does and just update our documentation to explain how it should behave
<jugglinmike> Matt_King: How would we make it more realistic? Would it be enough to add a placeholder value?
<jugglinmike> Adam_Page: I think that is enough
<jugglinmike> Matt_King: It sounds like Adam_Page, arigilmore, and howard-e agree that a placeholder would make this a more realistic example
<jugglinmike> Matt_King: That could receive focus by default
<jugglinmike> Zakim, end the meeting

[wagnermaciel]

Fixed by #3139

[wagnermaciel]

@mcking65 Are there scenarios where the listbox itself should receive focus instead of the items?

I ask this because while tidying up #3139, I noticed that this behavior was explicit/intentional in some examples.

[mcking65]

@wagnermaciel asks ...

Are there scenarios where the listbox itself should receive focus instead of the items?

I ask this because while tidying up #3139, I noticed that this behavior was explicit/intentional in some examples.

This example uses aria-activedescendant, so the ul with role listbox is the active element, i.e., the listbox is the focused element. There is documentation about aria-activedescendant linked in the table of states and props below the example.

Is that what you were asking about?