WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Controls on iOS Native App

for

Number of posts in this thread: 10 (In chronological order)

From: allyssa jessicon
Date: Wed, Nov 02 2022 5:06AM
Subject: Controls on iOS Native App
No previous message | Next message →

Hello everyone,

Good morning!

"Straight up to the question.

What's the exp]ected behaviour of checkbox and toggle buttons in
native mobile applications in iOS?

It seems that only the selected state is getting announced by
VoiceOver, for an example if I navigate to the VoiceOver rotor
settings, its announcing as Selected (without role) and if I uncheck
the same, VoiceOver does not announce anything.

Is this an expected behavior? or are there something that I am missing?"


Regards,
Allyssa.

From: Joe Humbert A11y (Android)
Date: Wed, Nov 02 2022 5:30AM
Subject: Re: Controls on iOS Native App
← Previous message | Next message →

Hi Allyssa,


I'm not sure which elements you are talking about so I might need a reply
to provide better guidance.


However, iOS does not have a native checkbox element. Any element you see
that visually looks like a checkbox is just that, a clickable element that
looks like a checkbox. If Voiceover announces a selected state when
"checked" then it has been given an accessibilityTrait of selected. It has
no role because there is no checkbox role in iOS. In my opinion the
developer should add an accessibilityTrait of button. Or better yet, use a
native switch.


As for the toggle button, I'm not sure what you mean. As it could be a lot
of different elements. But similar to the checkbox, there is no native iOS
right button element. So the developer is again using the
accessibilityTrait of selected when it is toggled. This element should
also have an accessibilityTrait of button.


To my Current knowledge, and I'm happy to be corrected, Apple VoiceOver
developers consciously decided to not have most elements announce an
"unselected", "unchecked" state. The exception might be a switch which has
states if off/on.


Hope this helps.

Thankx,
Joe Humbert
Mobile accessibility novice

On November 2, 2022 7:06:30 AM allyssa jessicon < = EMAIL ADDRESS REMOVED = >
wrote:

> Hello everyone,
>
> Good morning!
>
> "Straight up to the question.
>
> What's the exp]ected behaviour of checkbox and toggle buttons in
> native mobile applications in iOS?
>
> It seems that only the selected state is getting announced by
> VoiceOver, for an example if I navigate to the VoiceOver rotor
> settings, its announcing as Selected (without role) and if I uncheck
> the same, VoiceOver does not announce anything.
>
> Is this an expected behavior? or are there something that I am missing?"
>
>
> Regards,
> Allyssa.
> > > >

From: allyssa jessicon
Date: Wed, Nov 02 2022 5:40AM
Subject: Re: Controls on iOS Native App
← Previous message | Next message →

Thanks for your quick response  Joe,

My question is specific to any native app where checkbox/toggle button
have been used which does not announce the role and unselected state.
is this a WCAG violation in any way?

An example would be, a Remember me checkbox in a login screen (Any 3rd
party iOS native app)


On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Allyssa,
>
>
> I'm not sure which elements you are talking about so I might need a reply
> to provide better guidance.
>
>
> However, iOS does not have a native checkbox element. Any element you see
> that visually looks like a checkbox is just that, a clickable element that
> looks like a checkbox. If Voiceover announces a selected state when
> "checked" then it has been given an accessibilityTrait of selected. It has
> no role because there is no checkbox role in iOS. In my opinion the
> developer should add an accessibilityTrait of button. Or better yet, use a
> native switch.
>
>
> As for the toggle button, I'm not sure what you mean. As it could be a lot
> of different elements. But similar to the checkbox, there is no native iOS
> right button element. So the developer is again using the
> accessibilityTrait of selected when it is toggled. This element should
> also have an accessibilityTrait of button.
>
>
> To my Current knowledge, and I'm happy to be corrected, Apple VoiceOver
> developers consciously decided to not have most elements announce an
> "unselected", "unchecked" state. The exception might be a switch which has
> states if off/on.
>
>
> Hope this helps.
>
> Thankx,
> Joe Humbert
> Mobile accessibility novice
>
> On November 2, 2022 7:06:30 AM allyssa jessicon < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Hello everyone,
>>
>> Good morning!
>>
>> "Straight up to the question.
>>
>> What's the exp]ected behaviour of checkbox and toggle buttons in
>> native mobile applications in iOS?
>>
>> It seems that only the selected state is getting announced by
>> VoiceOver, for an example if I navigate to the VoiceOver rotor
>> settings, its announcing as Selected (without role) and if I uncheck
>> the same, VoiceOver does not announce anything.
>>
>> Is this an expected behavior? or are there something that I am missing?"
>>
>>
>> Regards,
>> Allyssa.
>> >> >> >> >
> > > > >

From: Joe Humbert A11y (Android)
Date: Wed, Nov 02 2022 5:53AM
Subject: Re: Controls on iOS Native App
← Previous message | Next message →

Since iOS does not have a native checkbox and VoiceOver does not announce a
"not selected" State (there isn't one unless it is added to the accessible
name), the only WCAG violation that I can see is WCAG 4.1.2 Name, Role,
Value because the element has no role ( I don't count the "Double-tap to
activate" because it can be disabled by users, but some people do). Again,
here the only available role that somewhat fits is button.

I still think it should be a switch instead of a checkbox.

Thankx,

Joe

On November 2, 2022 7:40:45 AM allyssa jessicon < = EMAIL ADDRESS REMOVED = >
wrote:

> Thanks for your quick response Joe,
>
> My question is specific to any native app where checkbox/toggle button
> have been used which does not announce the role and unselected state.
> is this a WCAG violation in any way?
>
> An example would be, a Remember me checkbox in a login screen (Any 3rd
> party iOS native app)
>
>
> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>> Hi Allyssa,
>>
>>
>> I'm not sure which elements you are talking about so I might need a reply
>> to provide better guidance.
>>
>>
>> However, iOS does not have a native checkbox element. Any element you see
>> that visually looks like a checkbox is just that, a clickable element that
>> looks like a checkbox. If Voiceover announces a selected state when
>> "checked" then it has been given an accessibilityTrait of selected. It has
>> no role because there is no checkbox role in iOS. In my opinion the
>> developer should add an accessibilityTrait of button. Or better yet, use a
>> native switch.
>>
>>
>> As for the toggle button, I'm not sure what you mean. As it could be a lot
>> of different elements. But similar to the checkbox, there is no native iOS
>> right button element. So the developer is again using the
>> accessibilityTrait of selected when it is toggled. This element should
>> also have an accessibilityTrait of button.
>>
>>
>> To my Current knowledge, and I'm happy to be corrected, Apple VoiceOver
>> developers consciously decided to not have most elements announce an
>> "unselected", "unchecked" state. The exception might be a switch which has
>> states if off/on.
>>
>>
>> Hope this helps.
>>
>> Thankx,
>> Joe Humbert
>> Mobile accessibility novice
>>
>> On November 2, 2022 7:06:30 AM allyssa jessicon < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> Hello everyone,
>>>
>>> Good morning!
>>>
>>> "Straight up to the question.
>>>
>>> What's the exp]ected behaviour of checkbox and toggle buttons in
>>> native mobile applications in iOS?
>>>
>>> It seems that only the selected state is getting announced by
>>> VoiceOver, for an example if I navigate to the VoiceOver rotor
>>> settings, its announcing as Selected (without role) and if I uncheck
>>> the same, VoiceOver does not announce anything.
>>>
>>> Is this an expected behavior? or are there something that I am missing?"
>>>
>>>
>>> Regards,
>>> Allyssa.
>>> >>> >>> >>> >>
>> >> >> >> > > > >

From: allyssa jessicon
Date: Wed, Nov 02 2022 5:58AM
Subject: Re: Controls on iOS Native App
← Previous message | Next message →

Don't you think that not selected state also fails WCAG 4.1.2 Name,
Role, Value? and if both fails, there will have a lot failures in apps
wherever they have used checkboxes (visually)

On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
> Since iOS does not have a native checkbox and VoiceOver does not announce a
> "not selected" State (there isn't one unless it is added to the accessible
> name), the only WCAG violation that I can see is WCAG 4.1.2 Name, Role,
> Value because the element has no role ( I don't count the "Double-tap to
> activate" because it can be disabled by users, but some people do). Again,
> here the only available role that somewhat fits is button.
>
> I still think it should be a switch instead of a checkbox.
>
> Thankx,
>
> Joe
>
> On November 2, 2022 7:40:45 AM allyssa jessicon < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Thanks for your quick response Joe,
>>
>> My question is specific to any native app where checkbox/toggle button
>> have been used which does not announce the role and unselected state.
>> is this a WCAG violation in any way?
>>
>> An example would be, a Remember me checkbox in a login screen (Any 3rd
>> party iOS native app)
>>
>>
>> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>>> Hi Allyssa,
>>>
>>>
>>> I'm not sure which elements you are talking about so I might need a reply
>>> to provide better guidance.
>>>
>>>
>>> However, iOS does not have a native checkbox element. Any element you
>>> see
>>> that visually looks like a checkbox is just that, a clickable element
>>> that
>>> looks like a checkbox. If Voiceover announces a selected state when
>>> "checked" then it has been given an accessibilityTrait of selected. It
>>> has
>>> no role because there is no checkbox role in iOS. In my opinion the
>>> developer should add an accessibilityTrait of button. Or better yet, use
>>> a
>>> native switch.
>>>
>>>
>>> As for the toggle button, I'm not sure what you mean. As it could be a
>>> lot
>>> of different elements. But similar to the checkbox, there is no native
>>> iOS
>>> right button element. So the developer is again using the
>>> accessibilityTrait of selected when it is toggled. This element should
>>> also have an accessibilityTrait of button.
>>>
>>>
>>> To my Current knowledge, and I'm happy to be corrected, Apple VoiceOver
>>> developers consciously decided to not have most elements announce an
>>> "unselected", "unchecked" state. The exception might be a switch which
>>> has
>>> states if off/on.
>>>
>>>
>>> Hope this helps.
>>>
>>> Thankx,
>>> Joe Humbert
>>> Mobile accessibility novice
>>>
>>> On November 2, 2022 7:06:30 AM allyssa jessicon
>>> < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> Good morning!
>>>>
>>>> "Straight up to the question.
>>>>
>>>> What's the exp]ected behaviour of checkbox and toggle buttons in
>>>> native mobile applications in iOS?
>>>>
>>>> It seems that only the selected state is getting announced by
>>>> VoiceOver, for an example if I navigate to the VoiceOver rotor
>>>> settings, its announcing as Selected (without role) and if I uncheck
>>>> the same, VoiceOver does not announce anything.
>>>>
>>>> Is this an expected behavior? or are there something that I am missing?"
>>>>
>>>>
>>>> Regards,
>>>> Allyssa.
>>>> >>>> >>>> >>>> >>>
>>> >>> >>> >>> >> >> >> >> >
> > > > >

From: Joe Humbert A11y (Android)
Date: Wed, Nov 02 2022 6:19AM
Subject: Re: Controls on iOS Native App
← Previous message | Next message →

You cannot fail something for a state that is not supported by the OS or
the assistive tech.

In addition, developers using custom non-native elements when their is a
native element that supports all necessary roles and states (switch) is
just bad user experience. We are on iOS 16 and Apple has yet to add a
native checkbox.

Heck developers can make it look like a checkbox, but act like a switch.
But again bad user experience for a Visual VoiceOver user.

Thankx,
Joe

On November 2, 2022 7:59:18 AM allyssa jessicon < = EMAIL ADDRESS REMOVED = >
wrote:

> Don't you think that not selected state also fails WCAG 4.1.2 Name,
> Role, Value? and if both fails, there will have a lot failures in apps
> wherever they have used checkboxes (visually)
>
> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>> Since iOS does not have a native checkbox and VoiceOver does not announce a
>> "not selected" State (there isn't one unless it is added to the accessible
>> name), the only WCAG violation that I can see is WCAG 4.1.2 Name, Role,
>> Value because the element has no role ( I don't count the "Double-tap to
>> activate" because it can be disabled by users, but some people do). Again,
>> here the only available role that somewhat fits is button.
>>
>> I still think it should be a switch instead of a checkbox.
>>
>> Thankx,
>>
>> Joe
>>
>> On November 2, 2022 7:40:45 AM allyssa jessicon < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> Thanks for your quick response Joe,
>>>
>>> My question is specific to any native app where checkbox/toggle button
>>> have been used which does not announce the role and unselected state.
>>> is this a WCAG violation in any way?
>>>
>>> An example would be, a Remember me checkbox in a login screen (Any 3rd
>>> party iOS native app)
>>>
>>>
>>> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>>>> Hi Allyssa,
>>>>
>>>>
>>>> I'm not sure which elements you are talking about so I might need a reply
>>>> to provide better guidance.
>>>>
>>>>
>>>> However, iOS does not have a native checkbox element. Any element you
>>>> see
>>>> that visually looks like a checkbox is just that, a clickable element
>>>> that
>>>> looks like a checkbox. If Voiceover announces a selected state when
>>>> "checked" then it has been given an accessibilityTrait of selected. It
>>>> has
>>>> no role because there is no checkbox role in iOS. In my opinion the
>>>> developer should add an accessibilityTrait of button. Or better yet, use
>>>> a
>>>> native switch.
>>>>
>>>>
>>>> As for the toggle button, I'm not sure what you mean. As it could be a
>>>> lot
>>>> of different elements. But similar to the checkbox, there is no native
>>>> iOS
>>>> right button element. So the developer is again using the
>>>> accessibilityTrait of selected when it is toggled. This element should
>>>> also have an accessibilityTrait of button.
>>>>
>>>>
>>>> To my Current knowledge, and I'm happy to be corrected, Apple VoiceOver
>>>> developers consciously decided to not have most elements announce an
>>>> "unselected", "unchecked" state. The exception might be a switch which
>>>> has
>>>> states if off/on.
>>>>
>>>>
>>>> Hope this helps.
>>>>
>>>> Thankx,
>>>> Joe Humbert
>>>> Mobile accessibility novice
>>>>
>>>> On November 2, 2022 7:06:30 AM allyssa jessicon
>>>> < = EMAIL ADDRESS REMOVED = >
>>>> wrote:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> Good morning!
>>>>>
>>>>> "Straight up to the question.
>>>>>
>>>>> What's the exp]ected behaviour of checkbox and toggle buttons in
>>>>> native mobile applications in iOS?
>>>>>
>>>>> It seems that only the selected state is getting announced by
>>>>> VoiceOver, for an example if I navigate to the VoiceOver rotor
>>>>> settings, its announcing as Selected (without role) and if I uncheck
>>>>> the same, VoiceOver does not announce anything.
>>>>>
>>>>> Is this an expected behavior? or are there something that I am missing?"
>>>>>
>>>>>
>>>>> Regards,
>>>>> Allyssa.
>>>>> >>>>> >>>>> >>>>> >>>>
>>>> >>>> >>>> >>>> >>> >>> >>> >>> >>
>> >> >> >> >>
> > > >

From: allyssa jessicon
Date: Wed, Nov 02 2022 6:27AM
Subject: Re: Controls on iOS Native App
← Previous message | Next message →

If dev are using a switch and making it look like a checkbox but the
checkbox (actual switch) does not work as expected (role and state is
missing or not acting as expected( then can it be failed against WCAG
4.1.2 Name, Role, Value?

There are situations like Remember me checkbox in a login screen where
the most appropriate role would be a checkbox and if the dev are using
a switch ther instead it will completely misslead the VO user, what do
you say?

On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
> You cannot fail something for a state that is not supported by the OS or
> the assistive tech.
>
> In addition, developers using custom non-native elements when their is a
> native element that supports all necessary roles and states (switch) is
> just bad user experience. We are on iOS 16 and Apple has yet to add a
> native checkbox.
>
> Heck developers can make it look like a checkbox, but act like a switch.
> But again bad user experience for a Visual VoiceOver user.
>
> Thankx,
> Joe
>
> On November 2, 2022 7:59:18 AM allyssa jessicon < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Don't you think that not selected state also fails WCAG 4.1.2 Name,
>> Role, Value? and if both fails, there will have a lot failures in apps
>> wherever they have used checkboxes (visually)
>>
>> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>>> Since iOS does not have a native checkbox and VoiceOver does not announce
>>> a
>>> "not selected" State (there isn't one unless it is added to the
>>> accessible
>>> name), the only WCAG violation that I can see is WCAG 4.1.2 Name, Role,
>>> Value because the element has no role ( I don't count the "Double-tap to
>>> activate" because it can be disabled by users, but some people do).
>>> Again,
>>> here the only available role that somewhat fits is button.
>>>
>>> I still think it should be a switch instead of a checkbox.
>>>
>>> Thankx,
>>>
>>> Joe
>>>
>>> On November 2, 2022 7:40:45 AM allyssa jessicon
>>> < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>> Thanks for your quick response Joe,
>>>>
>>>> My question is specific to any native app where checkbox/toggle button
>>>> have been used which does not announce the role and unselected state.
>>>> is this a WCAG violation in any way?
>>>>
>>>> An example would be, a Remember me checkbox in a login screen (Any 3rd
>>>> party iOS native app)
>>>>
>>>>
>>>> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> Hi Allyssa,
>>>>>
>>>>>
>>>>> I'm not sure which elements you are talking about so I might need a
>>>>> reply
>>>>> to provide better guidance.
>>>>>
>>>>>
>>>>> However, iOS does not have a native checkbox element. Any element you
>>>>> see
>>>>> that visually looks like a checkbox is just that, a clickable element
>>>>> that
>>>>> looks like a checkbox. If Voiceover announces a selected state when
>>>>> "checked" then it has been given an accessibilityTrait of selected. It
>>>>> has
>>>>> no role because there is no checkbox role in iOS. In my opinion the
>>>>> developer should add an accessibilityTrait of button. Or better yet,
>>>>> use
>>>>> a
>>>>> native switch.
>>>>>
>>>>>
>>>>> As for the toggle button, I'm not sure what you mean. As it could be a
>>>>> lot
>>>>> of different elements. But similar to the checkbox, there is no native
>>>>> iOS
>>>>> right button element. So the developer is again using the
>>>>> accessibilityTrait of selected when it is toggled. This element should
>>>>> also have an accessibilityTrait of button.
>>>>>
>>>>>
>>>>> To my Current knowledge, and I'm happy to be corrected, Apple VoiceOver
>>>>> developers consciously decided to not have most elements announce an
>>>>> "unselected", "unchecked" state. The exception might be a switch which
>>>>> has
>>>>> states if off/on.
>>>>>
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>> Thankx,
>>>>> Joe Humbert
>>>>> Mobile accessibility novice
>>>>>
>>>>> On November 2, 2022 7:06:30 AM allyssa jessicon
>>>>> < = EMAIL ADDRESS REMOVED = >
>>>>> wrote:
>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> Good morning!
>>>>>>
>>>>>> "Straight up to the question.
>>>>>>
>>>>>> What's the exp]ected behaviour of checkbox and toggle buttons in
>>>>>> native mobile applications in iOS?
>>>>>>
>>>>>> It seems that only the selected state is getting announced by
>>>>>> VoiceOver, for an example if I navigate to the VoiceOver rotor
>>>>>> settings, its announcing as Selected (without role) and if I uncheck
>>>>>> the same, VoiceOver does not announce anything.
>>>>>>
>>>>>> Is this an expected behavior? or are there something that I am
>>>>>> missing?"
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Allyssa.
>>>>>> >>>>>> >>>>>> >>>>>> >>>>>
>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>
>>> >>> >>> >>> >>>
>> >> >> >> >
> > > > >

From: joe@a11yeval.com
Date: Wed, Nov 02 2022 7:17AM
Subject: Re: Controls on iOS Native App
← Previous message | Next message →

I think I'm going to tap out after this email.

I have stated my opinions and it seems like you are looking for reasons to fail something for WCAG, that is your choice, WCAG for native mobile is definitely super open to interpretation because none of the guidelines are specifically written for native mobile. Plus accessibility is a living, changing thing and new interpretations are constantly proposed, discussed and sometimes agreed upon.

>> If dev are using a switch and making it look like a checkbox but the checkbox (actual switch) does not work as expected (role and state is missing or not acting as expected( then can it be failed against WCAG
4.1.2 Name, Role, Value?

Probably not, because if they were using a native switch, it would automatically have a role and states. Now the accessible name may be missing, but that is a different situation, plus I said I don't recommend this approach. Something for you to think about, How do you know they are using a switch if it is not reporting the correct information?

>> There are situations like Remember me checkbox in a login screen where the most appropriate role would be a checkbox and if the dev are using a switch ther instead it will completely misslead the VO user, what do you say?

Well, they are misleading all user by using a checkbox in the first place because there is no native checkbox on iOS. Also, WCAG 4.1.2 states "For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set..." this does not explicitly say the roles and states have to match the visuals. That potential issue fails under WCAG 1.3.1 Info and Relationships. WCAG 4.1.2 just says the that these attributes "can be programmatically determined" and "can be programmatically set". On iOS there is no way that I know of to provide a programmatic state of "unselected" or "unchecked" except in the accessibilityLabel which is a string and the name, not the role or state.

Checkboxes are a HTML control (and also on Android). Native mobile apps don't always have to follow HTML patterns. That being said, if a checkbox is really necessary, use a webview for the login and a properly coded accessible HTML checkbox.

Good luck and keep asking questions.

Thankx,
Joe

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of allyssa jessicon
Sent: Wednesday, November 2, 2022 8:27 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Controls on iOS Native App

If dev are using a switch and making it look like a checkbox but the checkbox (actual switch) does not work as expected (role and state is missing or not acting as expected( then can it be failed against WCAG
4.1.2 Name, Role, Value?

There are situations like Remember me checkbox in a login screen where the most appropriate role would be a checkbox and if the dev are using a switch ther instead it will completely misslead the VO user, what do you say?

On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
> You cannot fail something for a state that is not supported by the OS
> or the assistive tech.
>
> In addition, developers using custom non-native elements when their is
> a native element that supports all necessary roles and states (switch)
> is just bad user experience. We are on iOS 16 and Apple has yet to add
> a native checkbox.
>
> Heck developers can make it look like a checkbox, but act like a switch.
> But again bad user experience for a Visual VoiceOver user.
>
> Thankx,
> Joe
>
> On November 2, 2022 7:59:18 AM allyssa jessicon
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Don't you think that not selected state also fails WCAG 4.1.2 Name,
>> Role, Value? and if both fails, there will have a lot failures in
>> apps wherever they have used checkboxes (visually)
>>
>> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>>> Since iOS does not have a native checkbox and VoiceOver does not
>>> announce a "not selected" State (there isn't one unless it is added
>>> to the accessible name), the only WCAG violation that I can see is
>>> WCAG 4.1.2 Name, Role, Value because the element has no role ( I
>>> don't count the "Double-tap to activate" because it can be disabled
>>> by users, but some people do).
>>> Again,
>>> here the only available role that somewhat fits is button.
>>>
>>> I still think it should be a switch instead of a checkbox.
>>>
>>> Thankx,
>>>
>>> Joe
>>>
>>> On November 2, 2022 7:40:45 AM allyssa jessicon
>>> < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>> Thanks for your quick response Joe,
>>>>
>>>> My question is specific to any native app where checkbox/toggle
>>>> button have been used which does not announce the role and unselected state.
>>>> is this a WCAG violation in any way?
>>>>
>>>> An example would be, a Remember me checkbox in a login screen (Any
>>>> 3rd party iOS native app)
>>>>
>>>>
>>>> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> Hi Allyssa,
>>>>>
>>>>>
>>>>> I'm not sure which elements you are talking about so I might need
>>>>> a reply to provide better guidance.
>>>>>
>>>>>
>>>>> However, iOS does not have a native checkbox element. Any element
>>>>> you see that visually looks like a checkbox is just that, a
>>>>> clickable element that looks like a checkbox. If Voiceover
>>>>> announces a selected state when "checked" then it has been given
>>>>> an accessibilityTrait of selected. It has no role because there is
>>>>> no checkbox role in iOS. In my opinion the developer should add an
>>>>> accessibilityTrait of button. Or better yet, use a native switch.
>>>>>
>>>>>
>>>>> As for the toggle button, I'm not sure what you mean. As it could
>>>>> be a lot of different elements. But similar to the checkbox,
>>>>> there is no native iOS right button element. So the developer is
>>>>> again using the accessibilityTrait of selected when it is toggled.
>>>>> This element should also have an accessibilityTrait of button.
>>>>>
>>>>>
>>>>> To my Current knowledge, and I'm happy to be corrected, Apple
>>>>> VoiceOver developers consciously decided to not have most elements
>>>>> announce an "unselected", "unchecked" state. The exception might
>>>>> be a switch which has states if off/on.
>>>>>
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>> Thankx,
>>>>> Joe Humbert
>>>>> Mobile accessibility novice
>>>>>
>>>>> On November 2, 2022 7:06:30 AM allyssa jessicon
>>>>> < = EMAIL ADDRESS REMOVED = >
>>>>> wrote:
>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> Good morning!
>>>>>>
>>>>>> "Straight up to the question.
>>>>>>
>>>>>> What's the exp]ected behaviour of checkbox and toggle buttons in
>>>>>> native mobile applications in iOS?
>>>>>>
>>>>>> It seems that only the selected state is getting announced by
>>>>>> VoiceOver, for an example if I navigate to the VoiceOver rotor
>>>>>> settings, its announcing as Selected (without role) and if I
>>>>>> uncheck the same, VoiceOver does not announce anything.
>>>>>>
>>>>>> Is this an expected behavior? or are there something that I am
>>>>>> missing?"
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Allyssa.
>>>>>> >>>>>> >>>>>> archives at http://webaim.org/discussion/archives
>>>>>> >>>>>
>>>>> >>>>> >>>>> archives at http://webaim.org/discussion/archives
>>>>> >>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >
> > > archives at http://webaim.org/discussion/archives
> >

From: Andrews, David B (DEED)
Date: Wed, Nov 02 2022 7:19AM
Subject: Re: Controls on iOS Native App
← Previous message | Next message →

The question is, can a disabled person use it. I use VoiceOver, and if I change the control, does it tell me.

You guys can get all hung up on your numbers, but they are not the end, they are to get us to us4eable web sites and apps.

Dave



-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Wednesday, November 2, 2022 8:17 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Controls on iOS Native App

This message may be from an external email source.
Do not select links or open attachments unless verified. Report all suspicious emails to Minnesota IT Services Security Operations Center.

I think I'm going to tap out after this email.

I have stated my opinions and it seems like you are looking for reasons to fail something for WCAG, that is your choice, WCAG for native mobile is definitely super open to interpretation because none of the guidelines are specifically written for native mobile. Plus accessibility is a living, changing thing and new interpretations are constantly proposed, discussed and sometimes agreed upon.

>> If dev are using a switch and making it look like a checkbox but the
>> checkbox (actual switch) does not work as expected (role and state is
>> missing or not acting as expected( then can it be failed against WCAG
4.1.2 Name, Role, Value?

Probably not, because if they were using a native switch, it would automatically have a role and states. Now the accessible name may be missing, but that is a different situation, plus I said I don't recommend this approach. Something for you to think about, How do you know they are using a switch if it is not reporting the correct information?

>> There are situations like Remember me checkbox in a login screen where the most appropriate role would be a checkbox and if the dev are using a switch ther instead it will completely misslead the VO user, what do you say?

Well, they are misleading all user by using a checkbox in the first place because there is no native checkbox on iOS. Also, WCAG 4.1.2 states "For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set..." this does not explicitly say the roles and states have to match the visuals. That potential issue fails under WCAG 1.3.1 Info and Relationships. WCAG 4.1.2 just says the that these attributes "can be programmatically determined" and "can be programmatically set". On iOS there is no way that I know of to provide a programmatic state of "unselected" or "unchecked" except in the accessibilityLabel which is a string and the name, not the role or state.

Checkboxes are a HTML control (and also on Android). Native mobile apps don't always have to follow HTML patterns. That being said, if a checkbox is really necessary, use a webview for the login and a properly coded accessible HTML checkbox.

Good luck and keep asking questions.

Thankx,
Joe

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of allyssa jessicon
Sent: Wednesday, November 2, 2022 8:27 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Controls on iOS Native App

If dev are using a switch and making it look like a checkbox but the checkbox (actual switch) does not work as expected (role and state is missing or not acting as expected( then can it be failed against WCAG
4.1.2 Name, Role, Value?

There are situations like Remember me checkbox in a login screen where the most appropriate role would be a checkbox and if the dev are using a switch ther instead it will completely misslead the VO user, what do you say?

On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
> You cannot fail something for a state that is not supported by the OS
> or the assistive tech.
>
> In addition, developers using custom non-native elements when their is
> a native element that supports all necessary roles and states (switch)
> is just bad user experience. We are on iOS 16 and Apple has yet to add
> a native checkbox.
>
> Heck developers can make it look like a checkbox, but act like a switch.
> But again bad user experience for a Visual VoiceOver user.
>
> Thankx,
> Joe
>
> On November 2, 2022 7:59:18 AM allyssa jessicon
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Don't you think that not selected state also fails WCAG 4.1.2 Name,
>> Role, Value? and if both fails, there will have a lot failures in
>> apps wherever they have used checkboxes (visually)
>>
>> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>>> Since iOS does not have a native checkbox and VoiceOver does not
>>> announce a "not selected" State (there isn't one unless it is added
>>> to the accessible name), the only WCAG violation that I can see is
>>> WCAG 4.1.2 Name, Role, Value because the element has no role ( I
>>> don't count the "Double-tap to activate" because it can be disabled
>>> by users, but some people do).
>>> Again,
>>> here the only available role that somewhat fits is button.
>>>
>>> I still think it should be a switch instead of a checkbox.
>>>
>>> Thankx,
>>>
>>> Joe
>>>
>>> On November 2, 2022 7:40:45 AM allyssa jessicon
>>> < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>> Thanks for your quick response Joe,
>>>>
>>>> My question is specific to any native app where checkbox/toggle
>>>> button have been used which does not announce the role and unselected state.
>>>> is this a WCAG violation in any way?
>>>>
>>>> An example would be, a Remember me checkbox in a login screen (Any
>>>> 3rd party iOS native app)
>>>>
>>>>
>>>> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> Hi Allyssa,
>>>>>
>>>>>
>>>>> I'm not sure which elements you are talking about so I might need
>>>>> a reply to provide better guidance.
>>>>>
>>>>>
>>>>> However, iOS does not have a native checkbox element. Any element
>>>>> you see that visually looks like a checkbox is just that, a
>>>>> clickable element that looks like a checkbox. If Voiceover
>>>>> announces a selected state when "checked" then it has been given
>>>>> an accessibilityTrait of selected. It has no role because there is
>>>>> no checkbox role in iOS. In my opinion the developer should add an
>>>>> accessibilityTrait of button. Or better yet, use a native switch.
>>>>>
>>>>>
>>>>> As for the toggle button, I'm not sure what you mean. As it could
>>>>> be a lot of different elements. But similar to the checkbox,
>>>>> there is no native iOS right button element. So the developer is
>>>>> again using the accessibilityTrait of selected when it is toggled.
>>>>> This element should also have an accessibilityTrait of button.
>>>>>
>>>>>
>>>>> To my Current knowledge, and I'm happy to be corrected, Apple
>>>>> VoiceOver developers consciously decided to not have most elements
>>>>> announce an "unselected", "unchecked" state. The exception might
>>>>> be a switch which has states if off/on.
>>>>>
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>> Thankx,
>>>>> Joe Humbert
>>>>> Mobile accessibility novice
>>>>>
>>>>> On November 2, 2022 7:06:30 AM allyssa jessicon
>>>>> < = EMAIL ADDRESS REMOVED = >
>>>>> wrote:
>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> Good morning!
>>>>>>
>>>>>> "Straight up to the question.
>>>>>>
>>>>>> What's the exp]ected behaviour of checkbox and toggle buttons in
>>>>>> native mobile applications in iOS?
>>>>>>
>>>>>> It seems that only the selected state is getting announced by
>>>>>> VoiceOver, for an example if I navigate to the VoiceOver rotor
>>>>>> settings, its announcing as Selected (without role) and if I
>>>>>> uncheck the same, VoiceOver does not announce anything.
>>>>>>
>>>>>> Is this an expected behavior? or are there something that I am
>>>>>> missing?"
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Allyssa.
>>>>>> >>>>>> >>>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F
>>>>>> list.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.
>>>>>> us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2
>>>>>> 159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJW
>>>>>> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
>>>>>> 3000%7C%7C%7C&amp;sdata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa7
>>>>>> 04Jk%3D&amp;reserved=0 List archives at
>>>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F
>>>>>> webaim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.and
>>>>>> rews%40state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b0462
>>>>>> 4c445198f26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7C
>>>>>> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
>>>>>> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FB
>>>>>> XN5DCPoUYYHM%2BRJPYAks%3D&amp;reserved=0
>>>>>> >>>>>
>>>>> >>>>> >>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fl
>>>>> ist.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us
>>>>> %7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159
>>>>> 828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>>>>> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
>>>>> 7C%7C%7C&amp;sdata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3
>>>>> D&amp;reserved=0 List archives at
>>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
>>>>> ebaim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andre
>>>>> ws%40state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c4
>>>>> 45198f26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFp
>>>>> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
>>>>> I6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCP
>>>>> oUYYHM%2BRJPYAks%3D&amp;reserved=0
>>>>> >>>> >>>> >>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fli
>>>> st.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7
>>>> Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828
>>>> c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>>>> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
>>>> %7C&amp;sdata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3D&amp;
>>>> reserved=0 List archives at
>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwe
>>>> baim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews
>>>> %40state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c4451
>>>> 98f26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZs
>>>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>>>> %3D%7C3000%7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCPoUYYHM
>>>> %2BRJPYAks%3D&amp;reserved=0 >>>> = EMAIL ADDRESS REMOVED =
>>>
>>> >>> >>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flis
>>> t.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7Cb
>>> b648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828c%7
>>> C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
>>> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&a
>>> mp;sdata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3D&amp;reserv
>>> ed=0 List archives at
>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fweb
>>> aim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%4
>>> 0state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f
>>> 26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8
>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
>>> C3000%7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCPoUYYHM%2BRJP
>>> YAks%3D&amp;reserved=0 >>> = EMAIL ADDRESS REMOVED =
>>>
>> >> >> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
>> .webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7Cbb6
>> 48ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828c%7C0%
>> 7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sd
>> ata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3D&amp;reserved=0
>> List archives at
>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fweba
>> im.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40s
>> tate.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b
>> 89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJW
>> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
>> %7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCPoUYYHM%2BRJPYAks%3
>> D&amp;reserved=0 >> = EMAIL ADDRESS REMOVED =
>
> > > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.
> webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7Cbb648
> ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0
> %7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=K
> eWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3D&amp;reserved=0 List
> archives at
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebai
> m.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40sta
> te.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c
> 2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCPoUYYHM%2BRJPYAks%3D&amp;
> reserved=0 >

From: allyssa jessicon
Date: Wed, Nov 02 2022 7:33AM
Subject: Re: Controls on iOS Native App
← Previous message | No next message

Thanks Joe for your detailed response. I appreciate it!

On 11/2/22, Andrews, David B (DEED) via WebAIM-Forum
< = EMAIL ADDRESS REMOVED = > wrote:
> The question is, can a disabled person use it. I use VoiceOver, and if I
> change the control, does it tell me.
>
> You guys can get all hung up on your numbers, but they are not the end, they
> are to get us to us4eable web sites and apps.
>
> Dave
>
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Wednesday, November 2, 2022 8:17 AM
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Controls on iOS Native App
>
> This message may be from an external email source.
> Do not select links or open attachments unless verified. Report all
> suspicious emails to Minnesota IT Services Security Operations Center.
>
> >
> I think I'm going to tap out after this email.
>
> I have stated my opinions and it seems like you are looking for reasons to
> fail something for WCAG, that is your choice, WCAG for native mobile is
> definitely super open to interpretation because none of the guidelines are
> specifically written for native mobile. Plus accessibility is a living,
> changing thing and new interpretations are constantly proposed, discussed
> and sometimes agreed upon.
>
>>> If dev are using a switch and making it look like a checkbox but the
>>> checkbox (actual switch) does not work as expected (role and state is
>>> missing or not acting as expected( then can it be failed against WCAG
> 4.1.2 Name, Role, Value?
>
> Probably not, because if they were using a native switch, it would
> automatically have a role and states. Now the accessible name may be
> missing, but that is a different situation, plus I said I don't recommend
> this approach. Something for you to think about, How do you know they are
> using a switch if it is not reporting the correct information?
>
>>> There are situations like Remember me checkbox in a login screen where
>>> the most appropriate role would be a checkbox and if the dev are using a
>>> switch ther instead it will completely misslead the VO user, what do you
>>> say?
>
> Well, they are misleading all user by using a checkbox in the first place
> because there is no native checkbox on iOS. Also, WCAG 4.1.2 states "For all
> user interface components (including but not limited to: form elements,
> links and components generated by scripts), the name and role can be
> programmatically determined; states, properties, and values that can be set
> by the user can be programmatically set..." this does not explicitly say
> the roles and states have to match the visuals. That potential issue fails
> under WCAG 1.3.1 Info and Relationships. WCAG 4.1.2 just says the that
> these attributes "can be programmatically determined" and "can be
> programmatically set". On iOS there is no way that I know of to provide a
> programmatic state of "unselected" or "unchecked" except in the
> accessibilityLabel which is a string and the name, not the role or state.
>
> Checkboxes are a HTML control (and also on Android). Native mobile apps
> don't always have to follow HTML patterns. That being said, if a checkbox is
> really necessary, use a webview for the login and a properly coded
> accessible HTML checkbox.
>
> Good luck and keep asking questions.
>
> Thankx,
> Joe
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> allyssa jessicon
> Sent: Wednesday, November 2, 2022 8:27 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Controls on iOS Native App
>
> If dev are using a switch and making it look like a checkbox but the
> checkbox (actual switch) does not work as expected (role and state is
> missing or not acting as expected( then can it be failed against WCAG
> 4.1.2 Name, Role, Value?
>
> There are situations like Remember me checkbox in a login screen where the
> most appropriate role would be a checkbox and if the dev are using a switch
> ther instead it will completely misslead the VO user, what do you say?
>
> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>> You cannot fail something for a state that is not supported by the OS
>> or the assistive tech.
>>
>> In addition, developers using custom non-native elements when their is
>> a native element that supports all necessary roles and states (switch)
>> is just bad user experience. We are on iOS 16 and Apple has yet to add
>> a native checkbox.
>>
>> Heck developers can make it look like a checkbox, but act like a switch.
>> But again bad user experience for a Visual VoiceOver user.
>>
>> Thankx,
>> Joe
>>
>> On November 2, 2022 7:59:18 AM allyssa jessicon
>> < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> Don't you think that not selected state also fails WCAG 4.1.2 Name,
>>> Role, Value? and if both fails, there will have a lot failures in
>>> apps wherever they have used checkboxes (visually)
>>>
>>> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>>>> Since iOS does not have a native checkbox and VoiceOver does not
>>>> announce a "not selected" State (there isn't one unless it is added
>>>> to the accessible name), the only WCAG violation that I can see is
>>>> WCAG 4.1.2 Name, Role, Value because the element has no role ( I
>>>> don't count the "Double-tap to activate" because it can be disabled
>>>> by users, but some people do).
>>>> Again,
>>>> here the only available role that somewhat fits is button.
>>>>
>>>> I still think it should be a switch instead of a checkbox.
>>>>
>>>> Thankx,
>>>>
>>>> Joe
>>>>
>>>> On November 2, 2022 7:40:45 AM allyssa jessicon
>>>> < = EMAIL ADDRESS REMOVED = >
>>>> wrote:
>>>>
>>>>> Thanks for your quick response Joe,
>>>>>
>>>>> My question is specific to any native app where checkbox/toggle
>>>>> button have been used which does not announce the role and unselected
>>>>> state.
>>>>> is this a WCAG violation in any way?
>>>>>
>>>>> An example would be, a Remember me checkbox in a login screen (Any
>>>>> 3rd party iOS native app)
>>>>>
>>>>>
>>>>> On 11/2/22, Joe Humbert A11y (Android) < = EMAIL ADDRESS REMOVED = > wrote:
>>>>>> Hi Allyssa,
>>>>>>
>>>>>>
>>>>>> I'm not sure which elements you are talking about so I might need
>>>>>> a reply to provide better guidance.
>>>>>>
>>>>>>
>>>>>> However, iOS does not have a native checkbox element. Any element
>>>>>> you see that visually looks like a checkbox is just that, a
>>>>>> clickable element that looks like a checkbox. If Voiceover
>>>>>> announces a selected state when "checked" then it has been given
>>>>>> an accessibilityTrait of selected. It has no role because there is
>>>>>> no checkbox role in iOS. In my opinion the developer should add an
>>>>>> accessibilityTrait of button. Or better yet, use a native switch.
>>>>>>
>>>>>>
>>>>>> As for the toggle button, I'm not sure what you mean. As it could
>>>>>> be a lot of different elements. But similar to the checkbox,
>>>>>> there is no native iOS right button element. So the developer is
>>>>>> again using the accessibilityTrait of selected when it is toggled.
>>>>>> This element should also have an accessibilityTrait of button.
>>>>>>
>>>>>>
>>>>>> To my Current knowledge, and I'm happy to be corrected, Apple
>>>>>> VoiceOver developers consciously decided to not have most elements
>>>>>> announce an "unselected", "unchecked" state. The exception might
>>>>>> be a switch which has states if off/on.
>>>>>>
>>>>>>
>>>>>> Hope this helps.
>>>>>>
>>>>>> Thankx,
>>>>>> Joe Humbert
>>>>>> Mobile accessibility novice
>>>>>>
>>>>>> On November 2, 2022 7:06:30 AM allyssa jessicon
>>>>>> < = EMAIL ADDRESS REMOVED = >
>>>>>> wrote:
>>>>>>
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> Good morning!
>>>>>>>
>>>>>>> "Straight up to the question.
>>>>>>>
>>>>>>> What's the exp]ected behaviour of checkbox and toggle buttons in
>>>>>>> native mobile applications in iOS?
>>>>>>>
>>>>>>> It seems that only the selected state is getting announced by
>>>>>>> VoiceOver, for an example if I navigate to the VoiceOver rotor
>>>>>>> settings, its announcing as Selected (without role) and if I
>>>>>>> uncheck the same, VoiceOver does not announce anything.
>>>>>>>
>>>>>>> Is this an expected behavior? or are there something that I am
>>>>>>> missing?"
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Allyssa.
>>>>>>> >>>>>>> >>>>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F
>>>>>>> list.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.
>>>>>>> us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2
>>>>>>> 159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJW
>>>>>>> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
>>>>>>> 3000%7C%7C%7C&amp;sdata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa7
>>>>>>> 04Jk%3D&amp;reserved=0 List archives at
>>>>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F
>>>>>>> webaim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.and
>>>>>>> rews%40state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b0462
>>>>>>> 4c445198f26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7C
>>>>>>> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
>>>>>>> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FB
>>>>>>> XN5DCPoUYYHM%2BRJPYAks%3D&amp;reserved=0
>>>>>>> >>>>>>
>>>>>> >>>>>> >>>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fl
>>>>>> ist.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us
>>>>>> %7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159
>>>>>> 828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>>>>>> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
>>>>>> 7C%7C%7C&amp;sdata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3
>>>>>> D&amp;reserved=0 List archives at
>>>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
>>>>>> ebaim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andre
>>>>>> ws%40state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c4
>>>>>> 45198f26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFp
>>>>>> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
>>>>>> I6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCP
>>>>>> oUYYHM%2BRJPYAks%3D&amp;reserved=0
>>>>>> >>>>> >>>>> >>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fli
>>>>> st.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7
>>>>> Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828
>>>>> c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>>>>> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
>>>>> %7C&amp;sdata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3D&amp;
>>>>> reserved=0 List archives at
>>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwe
>>>>> baim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews
>>>>> %40state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c4451
>>>>> 98f26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZs
>>>>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>>>>> %3D%7C3000%7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCPoUYYHM
>>>>> %2BRJPYAks%3D&amp;reserved=0 >>>>> = EMAIL ADDRESS REMOVED =
>>>>
>>>> >>>> >>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flis
>>>> t.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7Cb
>>>> b648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828c%7
>>>> C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
>>>> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&a
>>>> mp;sdata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3D&amp;reserv
>>>> ed=0 List archives at
>>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fweb
>>>> aim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%4
>>>> 0state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f
>>>> 26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8
>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
>>>> C3000%7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCPoUYYHM%2BRJP
>>>> YAks%3D&amp;reserved=0 >>>> = EMAIL ADDRESS REMOVED =
>>>>
>>> >>> >>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
>>> .webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7Cbb6
>>> 48ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828c%7C0%
>>> 7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sd
>>> ata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3D&amp;reserved=0
>>> List archives at
>>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fweba
>>> im.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40s
>>> tate.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b
>>> 89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJW
>>> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
>>> %7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCPoUYYHM%2BRJPYAks%3
>>> D&amp;reserved=0 >>> = EMAIL ADDRESS REMOVED =
>>
>> >> >> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.
>> webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7Cbb648
>> ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0
>> %7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
>> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=K
>> eWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3D&amp;reserved=0 List
>> archives at
>> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebai
>> m.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40sta
>> te.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c
>> 2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
>> C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCPoUYYHM%2BRJPYAks%3D&amp;
>> reserved=0 >>
> > > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3D&amp;reserved=0
> List archives at
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCPoUYYHM%2BRJPYAks%3D&amp;reserved=0
> >
> > > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=KeWZHwfStkssUIDXoxOv2yP2wuisObo%2FaAKlLa704Jk%3D&amp;reserved=0
> List archives at
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7Cbb648ab0a1ea481c581808dabcd49638%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C638029918503576746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=H8cOub0P5nVVCRKwmb5NM%2FBXN5DCPoUYYHM%2BRJPYAks%3D&amp;reserved=0
> > > > > >