w3c
Switch examples should show how state is saved, and how users can understand this behavior
When a control has a role of switch, and a user changes its on/off state, will users expect this state change to be saved immediately, or will users expect that a state change may be safely abandoned without it being saved and persisted? This question is important in creating a good experience for users who do not see the whole form at the same time, such as non-sighted screen reader users, or some low vision users.
It's logical that the answer will depend on how much the individual user has previously experienced switch controls on mobile devices.
In mobile apps, switch controls are currently more common than they are on the web. In a mobile context, usually a flip of the switch is either saved immediately without additional confirmation, or a dialog is presented to confirm the save. In either of those scenarios, mobile app switch controls typically do not present a traditional form submit button for users to save their changes, nor a separate confirmation message after changes are saved.
On the web today, switch controls tend to behave like the mobile precedents, but sometimes authors make the save behaviors more like checkboxes in traditional web forms. Are both patterns equally good for accessibility on the web? The answer will not be obvious for web authors, so the ARIA switch pattern (issue #162) will need to answer this.
Will users benefit from design and text that make the save behavior predictable? If so, then the ARIA switch pattern should mention or demonstrate an answer to this question too.
@mitchellevan, how is this unique to switch? Why address it specifically in the switch pattern? Isn't this a form or site decision that cuts across all patterns and all types of pages?
I am proposing that switch is unique in the following way. When users encounter an element that's identified visually and programmatically as a switch, they should expect (and do usually expect today) that flipping the switch will make an immediate change without the additional step of form submission. All other kinds of form fields should (and do) cause users to have the opposite expectation, namely that they will need to go find the form submit button before their value changes are committed.
If APG editors agree, then the APG switch pattern should spell out that this is the usual expected implementation of a switch.
@mcking65 you're right there are plenty of sites and apps where other field types self-submit. Facebook's Settings pages are a good example
This mixture of behaviors points to a more general need for users to understand whether their value changes are being submitted, when the submit behavior varies from norm. The specific question remains: Is the norm for role=switch different from the norm for other kinds of fields?
@mitchellevan, I see many examples of state changes being persistent without a submit. For example:
- [ ] If I check off this to-do item, it is persistent without a submit.
So far, switch is unique to mobile because new ARIA 1.1 roles are not yet being used widely. However, I am not yet convinced the switch is unique in the way you suggest because of expectations established on mobile.
The issue of whether or not users have to take an action to make changes persistent is an interesting one. I think it is common to all users, and I don't know whether it is harder for assistive technology users to know if they need to submit or save their changes. It would certainly be relevant in the cognitive space as well.
I am open to the idea of addressing this topic in the practices, but I don't see anything in the ARIA spec, or in broadly accepted practices, that suggest we should tie this topic to the switch role.
@mcking65, Your arguments make sense, and I can't find compelling data to support my prediction of a trend on the web. So let's go with your suggestion to address this topic in the APG in a more general way, not tied to the switch role.
Should I edit this issue, or start a new one?
@mitchellevan I agree with you that a switch should only be used if the change is saved immediately. I’ve already added a line stating this in the WIP code example for switch.
For those interested, this is a good article that backs up this behaviour: When to use a switch or checkbox by Anthony.
Switches always indicate whether a setting is on or off. When users turn a switch to “on”, they expect an instantaneous action as soon as the label appears. This is what “on” implies, not just for UI switches but real-world switches too.
@mitchellevan @mcking65 are there any tasks for this issue? Any steps we should take?
As an enhancement to the current code example we could actually save the state with something like localStorage or something. That’s easy enough to implement :).