Review Example of Collapsible Dropdown Listbox

[mcking65]

The collapsible dropdown listbox example developed for issue #470 is ready for review.

Task Force Member Reviews Requested as of Nov 29, 2017

• Review by Ann (@annabbott)
• Review by Aaron (@aleventhal)
• Review by James (@jnurthen)

[devarshipant]

Type a character: focus moves to the next item with a name that starts with the typed character.

Does not work in IE edge.

Type multiple characters in rapid succession: focus moves to the next item with a name that starts with the string of characters typed.

Does not work in IE edge.

Label (Transuranium elements:) is not programmatically tied to its control. Consider using for / id attributes.

[jnurthen]

Label (Transuranium elements:) is not programmatically tied to its control. Consider using for / id attributes.

I don't think that can work for a button. If you were to add a for/id labelling it would overwrite the value which we certainly don't want to happen. Really this should not be a button IMO as there is no way to label it correctly.

@mcking65 is this pattern correct? Is this how it is meant to be coded?

[devarshipant]

Really this should not be a button IMO as there is no way to label it correctly.

I did not notice that the control has a button and an unordered list with role listbox. Although visually it is a single label and its control (listbox).

• aria-labelledby creates that association ("exp_elem" on ul points to Transuranium elements), but I could not get JAWS / NVDA to speak the label. It could be due to button element receiving focus before ul.

[mcking65]

This pattern is a way of making a custom element that replaces <select size="1"`. It is a hybrid of the best of what Mac and Windows offer for native html selects.

The visual rendering comes from Windows. On Windows, the popup does not cover up the button-looking thingy. On Mac it does.

From an accessibility API perspective, windows calls the button-thingy a combobox. However, that does not match the ARIA definition of a combobox. MacOS calls it a button, which works very well.

On MacOS, the popup is a menu, but it actually behaves more like a single-select listbox. On Windows, the popup is a single-select listbox, which works really well.

The reason button works so well is that its label is mutable by the JS but not the user except via the popup. And, with aria-haspopup, it effectively communicates the collapsed, popup nature.

Right now, the visible label is tied only to the listbox. However, I think it is right that it should be tied to both the button and the listbox. I will fix that.

This is just one way of doing this. Another is to use a menu of menuitem checkboxes like on MacOs.

Longer term, I would like to further tweak the ARIA definition of combobox to be more flexible still. We made good progress in ARIA 1.1, but I think we can do still better in ARIA 1.2. In the mean time, this is a very accessible way of making this kind of element and have it reliably rendered across platforms.

[mcking65]

With commit 56fd415, the button label includes both the adjacent label of "Choose an element:" and the button content that specifies the currently chosen element.

[aleventhal]

Should it be saying "not selected" each time I down arrow? Using NVDA.

As far as I'm concerned, for this kind of widget, the selection should move with the focus.

[mcking65]

@aleventhal, It looks to me like selection is moving with focus and that is correctly reflected in both Firefox and Chrome and reported correctly by JAWS in both browsers. NVDA does not say that in Firefox, it only says not selected in Chrome. Almost seems like a strange NVDA bug.

[mcking65]

@devarshipant, type ahead is working for me in IE11. We are not making any statements about Edge support in the first release of practices.

[devarshipant]

@mcking65 -- ok, edge is out then. I am not clear on the type ahead functionality. Is the user supposed to expand the listbox (after pressing spacebar) and then use type ahead? For me, type ahead does not work when the listbox is collapsed.

[annabbott]

No issues noted.

[goetsu]

Hi @mcking65 , with iOS last version it's currently impossible to open the dropdown when voiceover is turned on and impossible to close the dropdown when voiceover turned off and after touching the button to open it

[bramd]

This seems to work fine in most cases. However, if NVDA is used and both the "Automatic focus mode" options in the Browse Mode preferences are turned off it will just announce list when pressing enter/space on the button in browse mode. With a native select, it would have entered focus mode.

Since listbox is intended for widgets that handle keyboard focus (e.g. should be used in focus mode), I consider this a bug in NVDA, but wonder how other screenreaders handle this.

[shirsha]

When the focus is on the button the keyboard user can expand and collapse the listbox with [enter] key, it is working as expected.
When the focus is on the button the keyboard user can expand it with [Spacebar], but can't collapse it.
Either disable the function of expanding the listbox with [spacebar] or allow the user to close it using [spacebar]

[scottaohara]

I opened an issue about a mobile VoiceOver bug. Apologies if that should have been in this thread.

[sidnc86]

In Windows, there is another behavior. In collapsed state, one can use up/down arrows on keyboard to change the selection of options without expanding the listbox. Any plans to include that behavior? Of course IOS doesn't let that happen in case of select element. It sticks to the current implementation that you have got out there of presenting it as menubutton. I don't know behavior of select element in Mac as haven't used one yet.

[sidnc86]

In this example, up/down arrow seems to work only in Focus Mode of NVDA. I tried it on NVDA+Chrome combination. But still, pressing up/down arrow on menu button automatically expands the listbox. Whereas in Windows, for a select element, pressing up/down arrow changes selected option without expanding the listbox. Can we get this part working? That what I meant to have in my previous comment.

[ianmcburnie]

I'm sure this will be fairly obvious to most people, but I'm going to mention it anyway! Unlike a native select, the value of the listbox will not be submitted to the server as part of the form. Because, of course, buttons only pass their value if used to submit the form. Not much can be done about this I know, except perhaps clearly describe this situation (in the notes perhaps?) and provide a couple of workarounds (e.g. binding another, hidden input with the value of the button, or fully binding a hidden select). What do you think?

One benefit of the readonly combobox approach is that it uses a text input instead of a button, and so the value gets automatically submitted with the form. Sadly though, we at eBay have ran into several issues with a readonly combobox on iOS. Hence why we are exploring this newer pattern of yours.

[Zauberbutter]

What about mentioning an alternative with select > option. Because the functionality is provided without JavaScript too.

[mrcsmcln]

Is it just me or is aria-selected completely missing on the options from the JS example? It's referenced in the attributes column of the table, but I can't seem to find it via inspection or in the source code. Looks like this applies to the multiselectable examples too.

[mcking65]

@mrcsmcln,

If the listbox is not multiselect, selection follows focus and aria-selected is set on line 321 in listbox.js.

If it is multiselect, select is triggered with space and set with the function call on line 149.

[tmcconechy]

The currently selected value does not seem to be read (Tried Chrome Vox and Voice Over on Mac).
When i tab to the button i just hear that its a popup button, but the value is not read out in any way.

Seems like only the aria-labelledby is being read.

[carmacleod]

@tmcconechy

The currently selected value does not seem to be read (Tried Chrome Vox and Voice Over on Mac).
When i tab to the button i just hear that its a popup button, but the value is not read out in any way.

I assume you are using Chrome. Did you also try VoiceOver in Safari?

It's the same for me in Chrome on Windows with both JAWS and NVDA, i.e. I only hear "Choose an element:". However, both screen readers correctly say the full label in Firefox.

Oddly, Chrome set the button's role to "combobox". So perhaps Chrome has confused itself into thinking that the button text is the "combobox value" and not part of the label. I opened Chrome Issue 950761: button with aria-haspopup="listbox" should not default to combobox role to address this.

[carmacleod]

@mcking65

Longer term, I would like to further tweak the ARIA definition of combobox to be more flexible still. We made good progress in ARIA 1.1, but I think we can do still better in ARIA 1.2.

Is there an open issue for this work? Perhaps w3c/aria#817 ?

[tmcconechy]

@carmacleod - I did use safari and voice over. I think like you said its just reading one label.

[joanmarie]

@tmcconechy

Oddly, Chrome set the button's role to "combobox". So perhaps Chrome has confused itself into thinking that the button text is the "combobox value" and not part of the label. I opened Chrome Issue 950761: button with aria-haspopup="listbox" should not default to combobox role to address this.

From my initial triage, it looks like the role isn't the issue; but a different issue. As a side effect of updating Blink to handle a change in AccName, the button text isn't being used (we're looking for the selected item in the list, and nothing in the associated list claims to be selected). Will fix Blink.

[trjohnst]

Apologies if this is not the right forum for this feedback but I noticed the example specifies an id reference for the aria-haspopup attribute yet the documentation indicates that this should simply be a true/false value and not an id reference. Not sure whether the documentation needs updating or the example but it seems like they are both owned by aria-practices so I wanted to flag it.

[scottaohara]

hi @trjohnst

I think you might be mistaking the listbox token as an id?

The documentation you linked to is the ARIA 1.0 documentation which only had true and false values for aria-haspopup. In ARIA 1.1 listbox among other token values were added.

Does this help or am I missing the error you found?

[trjohnst]

@scottaohara apologies, yes I was mistaking the value as an id reference. Thank you for the updated documentation!

[craigkovatch]

It seems strange to me that the button has neither aria-owns nor aria-controls...?

[scottaohara]

@craigkovatch there is already an aria-haspopup, what do you find missing here that the other attributes would solve for?

[craigkovatch]

@scottaohara aria-haspopup is a useful descriptive property but it doesn't link the element of the button with the element of the list in any way. How is AT to understand the relationship if, say, the popup is rendered in a different part of the DOM for stacking reasons?

[eps1lon]

@scottaohara aria-haspopup is a useful descriptive property but it doesn't link the element of the button with the element of the list in any way.

@craigkovatch I was wondering the same thing but how and why would AT announce this relationship? I think the authoring practices cover this by including the currently selected value in the label. I would hope that "'Choose an element Neptunium' + has listbox popup" makes it clear that there are more values to select. Once the user opens the popup they get more information about possible values.

This does require a bit more manual wiring by making sure the label is concatenated properly and focus moves upon opening. I would love to hear some feedback from AT users if the example implementation is sufficient or if they think there is some information missing.

[esoyke]

As listbox-collapsible.js retrieves elements by ID (namely 'exp_button' and 'exp_elem_list'), how do you handle a scenario with more than one listbox? Seems like you can't.

I am trying to get my Angular app to pass accessibility audit but every Angular dropdown select library I've found doesn't pass. Our auditor suggested to use this W3C JavaScript example, but this won't work as we have multiple dropdowns and this assumes a single instance.

[craigkovatch]

how and why would AT announce this relationship

@eps1lon Great point. Maybe it's not necessary. If not, I have unnecessarily burdened many of our developers with adding aria-controls on everything 🙃

[scottaohara]

if it has aria-haspopup then generally focus would be moved to that popup when invoked. so yes. aria-controls may well be unnecessary depending on what you're doing (especially since it's support is rather dismal, presently).

[mcking65]

This example was deprecated with PR #1852