E-mail List Archives
Re: Controls on iOS Native App
From: joe
Date: Nov 2, 2022 7:17AM
- Next message: Andrews, David B (DEED): "Re: Controls on iOS Native App"
- Previous message: allyssa jessicon: "Re: Controls on iOS Native App"
- Next message in Thread: Andrews, David B (DEED): "Re: Controls on iOS Native App"
- Previous message in Thread: allyssa jessicon: "Re: Controls on iOS Native App"
- View all messages in this Thread
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
- Next message: Andrews, David B (DEED): "Re: Controls on iOS Native App"
- Previous message: allyssa jessicon: "Re: Controls on iOS Native App"
- Next message in Thread: Andrews, David B (DEED): "Re: Controls on iOS Native App"
- Previous message in Thread: allyssa jessicon: "Re: Controls on iOS Native App"
- View all messages in this Thread