Brief Note on Dismissing Selects and Listboxen
Native controls can be different from their roled-up ARIA equivalents in a variety of ways. For example, an expanded native HTML
<select> on mobile behaves differently when the dismiss gesture is used than when the same gesture is used with an expanded ARIA
Using Android with TalkBack, a down-then-left gesture closes the
<select>. Using the same gesture with a custom ARIA
listbox does not collapse the control; instead it moves back to the previous page.
Turn off TalkBack, and the swipe-left gesture will close the
<select>, but with
listbox it moves you back to the previous page.
Essentially the left-swipe gesture, or the down-then-left with TalkBack running, which mimics the platform generic Back button, does not work on Google’s Angular
<mat-select>. You can see this in other custom listboxes (such as APG’s combobox pattern), but the Angular page offered an easy side-by-each comparison.
I repeated this with iPadOS and VoiceOver.
The VoiceOver two-finger right-left-right gesture closes a native
<select>. On a
listbox, the same gesture moves you back in the browser history.
A TalkBack and VoiceOver user hears a slightly different announcement for each control, so they may understand to change their interactions. A sighted user relying on the visual affordance of the controls may not realize the controls are effectively different.
From experience with testing with users, once you start to mix controls — essentially dropping a
listbox on the same page as a
<select> — this becomes more than an annoyance.
If you choose a custom
listbox over a
<select> strictly for styling reasons, you can style the heck out of a
<select> already. If you resist because you want to style the list of options, ask yourself if your branding is more important than the consistent interface of the arguably more usable native version (larger text, larger hit areas, adapts to preferences).
There are many other cases where the ARIA equivalent of a control does not match the native platform equivalent, whether by interaction, exposure, visual styles, or something else. I have documented some here:
- Brief Note on Buttons, Enter, and Space, identifying
keydowndifferences, which should be accounted for in a custom button.
- WHCM and System Colors, noting the differences in border and text colors between native and custom controls when in Windows High Contrast Mode.
- Use Legend and Fieldset, which points out bugs in Apple’s implementation of ARIA control grouping.
- Disclosure Widgets, a case where support came so late that the ARIA version may be a better experience for Android and iOS users.
Native controls and their ARIA equivalents sometimes behave differently. Understand that and make sure to account for it (ideally by testing). Try not to mix the native and ARIA version of a control within a page, flow, or maybe even site.
Update: 7 August 2022
Simon Flack noted that Google has proposed a close watcher API through the WICG (so not standards track) may allow authors to support the gesture — if they know about it and why they should. Also, only for Chrome.
Simon also logged the dismiss gesture problem with Chromium for dialogs back in April: Issue 1319915: Talkback “Back” gesture does not trigger <dialog> `close` event.
I’m looking at a product detail page where a user can select a different variant to the one which they currently have (e.g. they have 500mL, we also offer 1L, 2L etc). Because these link to other pages, we have marked these up as a list of links and used aria-current on the currently selected item.
We’ve done this because we don’t know better practice. Would marking things up with listbox and option roles be better or worse? Are you aware of a best practice accessible pattern? Someone suggested radio buttons and selects, but it isn’t a form. It is literally links, but we want the user to realise they should be selecting one.
Thanks in advance if you get time to respond.
In response to.
Nathan, sounds like you have a few links in a disclosure widget. As long as it is coded correctly then that is probably ideal. Not too verbose, easy to code, cake to style, straightforward to use.
To your point, a listbox, select menu, or pile of radio buttons is not a great fit. They would all need a submit button as well.
In response to.
Wow! Prompt reply. FYI they are exposed rather than in a disclosure widget. Thanks for confirming listbox would require submit – that’s the bit I was missing. I don’t want a form that results in a link – I’d rather the link list :)
Just FYI and I realise I am a sample of 1, but it took me an age to find the “reply” link in your comments. It might be more visible next to the permalink.
In response to.
Thanks for the feedback. I appreciate that you found it.
Leave a Comment or Response