WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Controls on iOS Native App

for

From: joe@a11yeval.com
Date: Nov 2, 2022 7:17AM

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 REMOVED> > On Behalf Of allyssa jessicon
Sent: Wednesday, November 2, 2022 8:27 AM
To: WebAIM Discussion List < <EMAIL 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 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 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 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 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 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 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
> >