E-mail List Archives
Thread: Question on Drop-down with MAC VoiceOver
Number of posts in this thread: 8 (In chronological order)
From: Ramshif .
Date: Thu, Mar 24 2022 11:47AM
Subject: Question on Drop-down with MAC VoiceOver
No previous message | Next message →
Hello,
This is to understand if below issue is a failure of WCAG?
I have a drop-down (attached) when opened and by pressing Tab key keeps the=
focus to the drop-down (by closing the list) instead of going to the next =
interactive element. Is this a WCAG failure or an actual behavior of VoiceO=
ver on MAC? I haven't seen this behavior with other drop-down which are pre=
sent in w3c/ARIA pages.
Thanks in advance.
From: glen walker
Date: Thu, Mar 24 2022 1:06PM
Subject: Re: Question on Drop-down with MAC VoiceOver
← Previous message | Next message →
Looks like you are using a native select/option element so whatever
behavior you are seeing should be native to the Mac.
Ignoring voiceover for the moment, do you have the option turned on to
allow the tab key to navigate to all elements? There's a general Mac
setting and a Safari setting (you didn't say which browser you were using).
The general setting is in system preferences > keyboard > shortcuts.
Select the "use keyboard navigation..." checkbox.
The Safari setting is in preferences > advanced. Select the "Press TAB to
highlight..." checkbox.
On Thu, Mar 24, 2022 at 11:47 AM Ramshif . < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
>
> This is to understand if below issue is a failure of WCAG?
> I have a drop-down (attached) when opened and by pressing Tab key keeps
> the focus to the drop-down (by closing the list) instead of going to the
> next interactive element. Is this a WCAG failure or an actual behavior of
> VoiceOver on MAC? I haven't seen this behavior with other drop-down which
> are present in w3c/ARIA pages.
>
> Thanks in advance.
>
>
> > > > >
From: Ramshif .
Date: Thu, Mar 24 2022 11:41PM
Subject: Re: Question on Drop-down with MAC VoiceOver
← Previous message | Next message →
Thanks for your response Glen.
Yes, I have both options turned on and I am using Safari browser.
Get Outlook for Android<https://aka.ms/AAb9ysg>
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of glen walker < = EMAIL ADDRESS REMOVED = >
Sent: Friday, March 25, 2022 12:36:19 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Question on Drop-down with MAC VoiceOver
Looks like you are using a native select/option element so whatever
behavior you are seeing should be native to the Mac.
Ignoring voiceover for the moment, do you have the option turned on to
allow the tab key to navigate to all elements? There's a general Mac
setting and a Safari setting (you didn't say which browser you were using).
The general setting is in system preferences > keyboard > shortcuts.
Select the "use keyboard navigation..." checkbox.
The Safari setting is in preferences > advanced. Select the "Press TAB to
highlight..." checkbox.
On Thu, Mar 24, 2022 at 11:47 AM Ramshif . < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
>
> This is to understand if below issue is a failure of WCAG?
> I have a drop-down (attached) when opened and by pressing Tab key keeps
> the focus to the drop-down (by closing the list) instead of going to the
> next interactive element. Is this a WCAG failure or an actual behavior of
> VoiceOver on MAC? I haven't seen this behavior with other drop-down which
> are present in w3c/ARIA pages.
>
> Thanks in advance.
>
>
> > > > >
From: Ramshif .
Date: Fri, Mar 25 2022 2:44AM
Subject: Re: Question on Drop-down with MAC VoiceOver
← Previous message | Next message →
Hi Ramshif,
Since the drop down is not a customized one I would agree with Glen. However, I am confused with a Customized drop down with the behavior you mentioned as well as @Glen if it's a native drop down as you confirmed then how does the drop down which are available as an example in W3 and ARIA not having the same issue?
Regards,
Allysa.
On Mar 25, 2022, at 11:12 AM, Ramshif . < = EMAIL ADDRESS REMOVED = > wrote:
Thanks for your response Glen.
Yes, I have both options turned on and I am using Safari browser.
Get Outlook for Android<https://aka.ms/AAb9ysg>
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of glen walker < = EMAIL ADDRESS REMOVED = >
Sent: Friday, March 25, 2022 12:36:19 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Question on Drop-down with MAC VoiceOver
Looks like you are using a native select/option element so whatever
behavior you are seeing should be native to the Mac.
Ignoring voiceover for the moment, do you have the option turned on to
allow the tab key to navigate to all elements? There's a general Mac
setting and a Safari setting (you didn't say which browser you were using).
The general setting is in system preferences > keyboard > shortcuts.
Select the "use keyboard navigation..." checkbox.
The Safari setting is in preferences > advanced. Select the "Press TAB to
highlight..." checkbox.
On Thu, Mar 24, 2022 at 11:47 AM Ramshif . < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
>
> This is to understand if below issue is a failure of WCAG?
> I have a drop-down (attached) when opened and by pressing Tab key keeps
> the focus to the drop-down (by closing the list) instead of going to the
> next interactive element. Is this a WCAG failure or an actual behavior of
> VoiceOver on MAC? I haven't seen this behavior with other drop-down which
> are present in w3c/ARIA pages.
>
> Thanks in advance.
>
>
> > > > >
From: Ramshif .
Date: Fri, Mar 25 2022 2:50AM
Subject: Re: Question on Drop-down with MAC VoiceOver
← Previous message | Next message →
Previous email was received as personal, forwarded to the same thread to be in a loop.
On Mar 25, 2022, at 2:14 PM, Ramshif . < = EMAIL ADDRESS REMOVED = > wrote:
Hi Ramshif,
Since the drop down is not a customized one I would agree with Glen. However, I am confused with a Customized drop down with the behavior you mentioned as well as @Glen if it's a native drop down as you confirmed then how does the drop down which are available as an example in W3 and ARIA not having the same issue?
Regards,
Allysa.
On Mar 25, 2022, at 11:12 AM, Ramshif . < = EMAIL ADDRESS REMOVED = > wrote:
Thanks for your response Glen.
Yes, I have both options turned on and I am using Safari browser.
Get Outlook for Android<https://aka.ms/AAb9ysg>
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of glen walker < = EMAIL ADDRESS REMOVED = >
Sent: Friday, March 25, 2022 12:36:19 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Question on Drop-down with MAC VoiceOver
Looks like you are using a native select/option element so whatever
behavior you are seeing should be native to the Mac.
Ignoring voiceover for the moment, do you have the option turned on to
allow the tab key to navigate to all elements? There's a general Mac
setting and a Safari setting (you didn't say which browser you were using).
The general setting is in system preferences > keyboard > shortcuts.
Select the "use keyboard navigation..." checkbox.
The Safari setting is in preferences > advanced. Select the "Press TAB to
highlight..." checkbox.
On Thu, Mar 24, 2022 at 11:47 AM Ramshif . < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
>
> This is to understand if below issue is a failure of WCAG?
> I have a drop-down (attached) when opened and by pressing Tab key keeps
> the focus to the drop-down (by closing the list) instead of going to the
> next interactive element. Is this a WCAG failure or an actual behavior of
> VoiceOver on MAC? I haven't seen this behavior with other drop-down which
> are present in w3c/ARIA pages.
>
> Thanks in advance.
>
>
> > > > >
From: Mark Magennis
Date: Fri, Mar 25 2022 6:47AM
Subject: Re: Question on Drop-down with MAC VoiceOver
← Previous message | Next message →
Hi Alysa,
If I understand you correctly, you are asking why does a W3C example drop down coded using ARIA not behave the same way as a standard <select>.
It's because the keyboard behaviour of <select> controls varies a lot between different browsers (and often seems illogical). When you code an ARIA widget you have to code one set of keyboard behaviours, so which do you choose? Do you code it to work the way a <select> works in Safari? Or the way it works in Chrome? I imagine (I'm guessing because I haven't looked at the example) the answer is that you try to follow the standard approach for keyboard behaviour of ARIA widgets, e.g. Tab in, Arrow within, Tab out, ESC to close, etc. You may also take into account ways in which a <select> behaves that are consistent across browsers and try to stick with them to emulate the native control better. But sometimes there is a clash between the standard ARIA widget behaviour and the way the standard HTML controls works, as in what happens with Tab and ESC while a <select> is open in different browsers. It's very variable and not at all logical in my opinion.
Mark
From: allyssa jessicon
Date: Fri, Mar 25 2022 7:07AM
Subject: Re: Question on Drop-down with MAC VoiceOver
← Previous message | Next message →
Hello Mark.
I could see <li> has been used in ARIA example whereas the attached HTML used <select> instead. As per my understanding you conclude that it's just fine?
Get Outlook for iOS<https://aka.ms/o0ukef>
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Mark Magennis < = EMAIL ADDRESS REMOVED = >
Sent: Friday, March 25, 2022 6:17:41 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Question on Drop-down with MAC VoiceOver
Hi Alysa,
If I understand you correctly, you are asking why does a W3C example drop down coded using ARIA not behave the same way as a standard <select>.
It's because the keyboard behaviour of <select> controls varies a lot between different browsers (and often seems illogical). When you code an ARIA widget you have to code one set of keyboard behaviours, so which do you choose? Do you code it to work the way a <select> works in Safari? Or the way it works in Chrome? I imagine (I'm guessing because I haven't looked at the example) the answer is that you try to follow the standard approach for keyboard behaviour of ARIA widgets, e.g. Tab in, Arrow within, Tab out, ESC to close, etc. You may also take into account ways in which a <select> behaves that are consistent across browsers and try to stick with them to emulate the native control better. But sometimes there is a clash between the standard ARIA widget behaviour and the way the standard HTML controls works, as in what happens with Tab and ESC while a <select> is open in different browsers. It's very variable and not at all logical in my opinion.
Mark
From: Mark Magennis
Date: Fri, Mar 25 2022 8:07AM
Subject: Re: Question on Drop-down with MAC VoiceOver
← Previous message | No next message
Either way is okay. From an accessibility perspective it's better to use the native HTML <select> because it will behave the way the user expects in whatever browser you're using. But if it's necessary or preferable for reasons other than accessibility to create a select dropdown using ARIA, then as long as you code logical keyboard interactions that aren't radically different from those of the native element in any browser then users will be at worst mildly surprised or confused at the way it works but should still be able to use the control effectively.
In the ARIA example they're probably putting role="option" on the <li> so it's no longer exposed as an <li> anyway and could just as well be <div role="option"> (notwithstanding graceful degradation but I'm guessing that is no longer an issue ... waits for correction).
Mark