Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

How is focus within the listbox handled with VoiceOver touch gestures on iOS? #1309

Open
terracoda opened this issue Jan 24, 2020 · 5 comments
Open

How is focus within the listbox handled with VoiceOver touch gestures on iOS? #1309

terracoda opened this issue Jan 24, 2020 · 5 comments
Assignees
@mcking65
Labels
Feedback Issue raised by or for collecting input from people outside APG task force Pattern Page Related to a page documenting a Pattern question Issue asking a question

Comments

@terracoda
Copy link

We have implemented something very similar to the Choose an element listbox on this example page:
https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox-collapsible.html

For us, we have a list of of 9 Solutes rather than elements, but it is the same idea.
See the PhET Sim called Molarity. It has sound and interactive description.

What is unclear to me is the interaction when using VoiceOver on iOS. I sent an email to the wai-arai-ig list, but maybe this is a better place for the question.

We have the interaction working nicely with VO and keyboard on MacOS; however, on iOS the listbox can stay open if the cursor is moved out of the box without making a new selection or dismissing the listbox.

Basically, if the box is open and the user flicks up or down the cursor will move out of the box into the surrounding content, but focus is not entirely lost, so the box stays open. The cursor can also move out of the box when flicking left or right beyond the top or bottom of the list.

My questions are:

  1. Should users have access to the surrounding content when a listbox or combobox is open?
  2. If yes, is there a better way to handle the closing of the box besides listening for loss of focus?
  3. If no, what’s the best way to handle these popped-up list interactions? Is it best to treat them more like an opened dialog and restrict focus to the popped up list until the interaction is dismissed or a new selection is made?

Our current solution works the same as the provided element example. The provided element example exhibits the same issues as our implemented list of Solutes.

Any thoughts?

I am linking to our own issue, so I can catch any thoughts from you folks.
phetsims/molarity#213
@LaurenceRLewis
Copy link

A button to control the visibility of the popup (listbox) is recommended for pointer and touch users. The button should be focusable BUT not included in the page tab sequence.

@terracoda
Copy link
Author

terracoda commented Mar 12, 2020 via email

@mcking65
Copy link
Contributor

@terracoda wrote:

  1. Should users have access to the surrounding content when a listbox or combobox is open?

Yes. If you do not want this to be the case for mobile users because, for instance, user testing shows it is a problem, then consider a different pattern. Perhaps a combobox that opens a dialog.

I think that VoiceOver/Safari on iOS could do a much better job of supporting these patterns.

  1. If yes, is there a better way to handle the closing of the box besides listening for loss of focus?

Unsure ... you want to be careful that simply moving the VoiceOver reading cursor to other parts of the screen does not gratuitously close the popup. That would be quite frustrating if you thought you expanded it but then couldn't find it!

what’s the best way to handle these popped-up list interactions? Is it best to treat them more like an opened dialog and restrict focus to the popped up list until the interaction is dismissed or a new selection is made?

What is probably most important for mobile is that the popup is immediately adjacent to the controlling button in the reading order. I have experienced many of these in web views where it really hard to find the popup on the screen.

This might be extra hard in some cases because I don't think that Safari is yet supporting changing of reading order with aria-owns, which would mean that the popup literally has to be a DOM sibling of the controlling button. That is often not possible.

If you can't make them siblings, then you might have to follow the dialog path. However, that would be a bit wonky and heavy for desktop screen reader users if the only thing in the dialog is a listbox.

So, depending on your constraints, you might need 2 versions of the widget, one for desktop browsers where users typically have a keyboard and one for browsers, like iOS/Safari, where they do not.

@mcking65
Copy link
Contributor

@terracoda commented:

Thanks for sharing Lawrence, I am curious why it would be recommended for the button to not appear in the tab order. We have a button that pops up a listbox in this interactive science simulation, and it works well for all users including screen reader users using keyboard or VoiceOver touch gestures. https://phet.colorado.edu/sims/html/molarity/latest/molarity_en.html https://phet.colorado.edu/sims/html/molarity/latest/molarity_en.html Taliesin
…
On Mar 11, 2020, at 11:29 PM, Laurence Lewis @.***> wrote: A button to control the visibility of the popup (listbox) is recommended for pointer and touch users. The button should be focusable BUT not included in the page tab sequence. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1309 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOQMJCNJ34MBATAAWVOHJ3RHA6YBANCNFSM4KLME4WQ.

@LaurenceRLewis is quoting guidance for a combobox where the combobox itself controls the visibility of the popup for keyboard users. Mouse or touch users can click/tap either the combobox input field or the adjacent down arrow button. Because the down arrow button functionality is provided by the combobox itself, the down arrow button is left out of the Tab sequence.

In the case of a collapsable listbox controled by a button, you definitely need the button in the Tab sequence. That is analogous to a menubutton.

BTW, APG plans to add a select-only listbox, which would usually be preferable to the collapsable listbox. The select-only combobox is the ARIA 1.2 equivalent of HTML:select@size=1. It solves several of the shortcomings of the ARIA 1.1 collapsable listbox.

@mcking65 mcking65 added Feedback Issue raised by or for collecting input from people outside APG task force Pattern Page Related to a page documenting a Pattern question Issue asking a question labels Mar 16, 2020
@mcking65 mcking65 self-assigned this Mar 16, 2020
@mcking65 mcking65 added this to the 1.2 Release 1 milestone Mar 16, 2020
@terracoda
Copy link
Author

terracoda commented Mar 16, 2020 via email

@mcking65 mcking65 removed this from the 1.2 Release 1 milestone May 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mcking65 mcking65

Labels
Feedback Issue raised by or for collecting input from people outside APG task force Pattern Page Related to a page documenting a Pattern question Issue asking a question
Projects
Listbox Pattern and Examples Development Project
Status: In Progress
Milestone
No milestone
Development

No branches or pull requests
3 participants
@terracoda @LaurenceRLewis @mcking65