Switch Pattern: probably not exactly "interchangable" with checkboxes

[craigkovatch]

The Switch Pattern authoring guideline essentially considers switches to be functionally identical to checkboxes. I think this is insufficient, in that the design system I support does differentiate between them. Checkboxes are considered "delayed action", i.e. they work like the traditional HTML form control, where a button must be activated in order for the changes to a checkbox to have effect (or be submitted, etc.). Toggle switches, on the other hand, are used when the toggle action has immediate effect, e.g. toggling a "dark mode" toggle switch would immediately refresh the UI color theme upon activation.

While this behavioral difference may not be universal, I think it is common and perhaps even the majority case. We should have a way to differentiate this difference to assistive tech (beyond "last resort" patterns like explaining via aria-describedby).

Please let me know if what I'm suggesting is already covered and I'm just missing something :)

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Switch Pattern: probably not exactly "interchangable" with checkboxes.

The full IRC log of that discussion

<jugglinmike> subtopic: Switch Pattern: probably not exactly "interchangable" with checkboxes
<jugglinmike> github: https://github.com//issues/2647
<jugglinmike> Matt_King: We've talked about this before. Basically, whether or not the APG should say anything about this kind of common idea that switches take effect immediately while checkboxes imply some separate "submission" action will cause change to take place
<jugglinmike> Matt_King: Is it the place of APG to talk about this kind of difference?
<jugglinmike> MarkMcCarthy: This feels more like a design thing to me
<jugglinmike> Matt_King: For every single widget, we talk about its common use in the opening paragraph of the pattern
<Jem> https://deploy-preview-207--aria-practices.netlify.app/aria/apg/patterns/switch/
<Jem> A switch is an input widget that allows users to choose one of two values: on or off. Switches are similar to checkboxes and toggle buttons, which can also serve as binary inputs.
<jugglinmike> Matt_King: Would anyone ever make a decision about which role to use based on whether or not there's an accompanying "submit" button? Or are they going to make the decision based on the appearance
<jugglinmike> siri: A checkbox is used in different ways. It's not always used in a form that needs to be submitted
<jugglinmike> Matt_King: I think the second paragraph is sort of talking about this.
<Jem> "One difference, however, is that switches can only be used for binary input while checkboxes and toggle buttons allow implementations the option of supporting a third middle state. Checkboxes can be checked or not checked and can optionally also allow for a partially checked state. Toggle buttons can be pressed or not pressed and can optionally allow for a partially pressed state."
<jugglinmike> Matt_King: It's saying what is the accessibility reason for choosing the role
<jugglinmike> Matt_King: our goal is to help people choose the best ARIA role
<jugglinmike> jugglinmike: This feels somewhat like the "link versus button" design decision. That's a lot more prevalent that this one, but they both get at the UI concept of "feed forward"
<jugglinmike> Matt_King: Let's see if the reporter is satisfied by that second paragraph
<jugglinmike> zakim, end the meeting

[craigkovatch]

Hi, thanks for the quick discussion! Couple thoughts:

I don’t think toggles/switches having a “partial state” and checkboxes not is accurate. Checkbox input elements (in)famously have “indeterminate” state supported.

And I don’t think that’s directly relevant to the issue I raised here, which is just that buttons and switches are expected to have immediate effect, whereas checkboxes usually (tho maybe not universally) do not.

So I don’t think APG should describe them as interchangeable. Re: MKing’s comments, perhaps APG doesn’t need to take an opinion about the behavioral difference, but it should recognize that they’re not actually the same UI paradigm. Otherwise web authors and/or AT could err in exposing them identically and thus hampering equal access/perceivability.

[mcking65]

@craigkovatch wrote:

Hi, thanks for the quick discussion! Couple thoughts:

I don’t think toggles/switches having a “partial state” and checkboxes not is accurate.

Agreed. As stated in the pattern, switch is strictly binary. toggle and checkbox support 3 states.

And I don’t think that’s directly relevant to the issue I raised here, which is just that buttons and switches are expected to have immediate effect, whereas checkboxes usually (tho maybe not universally) do not.

Agreed. The two-state vs 3-state differences between switch and checkbox is not related to differences in conventions for activation effect triggers. The state discussion is related to the types of accessibility considerations that are important when choosing an ARIA role.

So I don’t think APG should describe them as interchangeable.

The APG language is:

Since switch, checkbox, and toggle button all offer binary input, they are often functionally interchangeable. Choose the role that best matches both the visual design and semantics of the user interface.

This recognizes that, in practice the functions are often, not always, the same. So, authors need to choose a role not based on functionality but based on presentation and semantics.

Re: MKing’s comments, perhaps APG doesn’t need to take an opinion about the behavioral difference,

My statement here is that it is not the role of the APG to tell authors whether they need to add or remove a related submit button; that is a design decision that is independent of accessibility. In some UI, a checkbox with immediate effect may be appropriate. In some UI, a switch that does not take immediate effect may be appropriate. We try to be careful to scope guidance to the factors that effect the accessibility of an experience.

but it should recognize that they’re not actually the same UI paradigm. Otherwise web authors and/or AT could err in exposing them identically and thus hampering equal access/perceivability.

We agree with this. The APG guidance is attempting to describe the factors relevant to accessibility that web authors should consider so they do not make that error and thereby hamper perceivability. As far as we can tell, the most relevant factors are 1) visual design and 2) UI semantics.

The task force has a concern (raised by Jon during the call but unfortunatley not captured in the minutes) that adding another decision factor related to activation effect timing or triggers would introduce complexity. Adding a third factor, that is not necessarily relevant to accessibility, could create confusion and reduce the effectiveness of the guidance.

Consider a design that includes an "Apply" button but where the visual design and semantics of the UI make switch the most appropriate role. How would we help authors understand the presence of the "Apply" button is not important in that situation?

If we were going to add the lack of a submit button as one factor that sometimes distinguishes switches from toggles or checkboxes, we would need some way of describing the situations where that is an important consideration. Can you suggest:

• What might some of those scenarios be?
• How do we distinguish those scenarios from scenarios where visual presentation and semantics trump the presence of a submitt button?

[craigkovatch]

I really appreciate the engagement here. Thanks for the discussion and the shared effort at clarity 🙏

Adding a third factor, that is not necessarily relevant to accessibility, could create confusion and reduce the effectiveness of the guidance

I’m skeptical that this is “not related to accessibility”. If we can’t make a clear statement about how ”switch” is different from “button” or “checkbox”, then why does the role exist at all? This is why the “functionally identical” language bothers me; I don’t think it’s true. We can always find exceptions to “guidelines” about functionality, but I think a baseline expectation of how a particular role functions (especially vs another similar role) is a fundamental question of accessibility, not a side note.

Consider a design that includes an "Apply" button but where the visual design and semantics of the UI make switch the most appropriate role.

It’s hard for me to consider this because it sounds like a contradiction in terms. “Consider a traffic light in which green is the most appropriate role for STOP” 😅🤔 (I actually don’t think I’ve ever seen a switch-based UI use a confirmation button, and I would consider it a poor and confusing presentation if I did)

I would suggest that it’s not about “a submit button per se is present” but “switches are generally expected to have an immediate effect, checkboxes generally are not (ymmv)”

I seem to recall other places the ARIA specs/APG makes statements like this, ie “generally expected” but not “universally required”, so this doesn’t feel like a big leap to me. (SHOULD vs MUST semantics)

I definitely appreciate the concerns the task force is raising but wonder if it might be making perfect the enemy of good?

[craigkovatch]

Aaaand of course as soon as I say I’ve never seen it, I immediately encounter an example in the wild. Everyone’s favorite UI too…cookie permission pop ups 😅

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Switch Pattern: probably not exactly "interchangable" with checkboxes.

The full IRC log of that discussion

<jugglinmike> Subtopic: Switch Pattern: probably not exactly "interchangable" with checkboxes
<jugglinmike> github: https://github.com/w3c/aria-practices/issues?q=is%3Aissue+is%3Aopen+created%3A%3E2021-08-15+no%3Alabel++sort%3Aupdated-desc
<jugglinmike> github: https://github.com//issues/2647
<jugglinmike> Matt_King: I don't want to muddy the waters in the first paragraph which describes how to choose a role. But maybe we could address this difference in how they may be conventionally applied in the second paragraph
<jugglinmike> jamesn: It seems like you should use switch only if activating it takes effect immediately
<jugglinmike> jugglinmike: So does that mean switches shouldn't be used in forms which aren't powered with JavaScript?
<jugglinmike> jamesn: I don't think they should be used in that case
<jugglinmike> Matt_King: We might have some other places where we use accessibility to say, "change your visual design because it doesn't reflect the accessibility semantics", but we've worked pretty hard to avoid doing that. I might be forgetting something, but it somehow feels like crossing a line.
<jugglinmike> Matt_King: I guess there are some places were we say, "for accessibility reasons, don't create massive radio button groups--use something like a typeahead, instead"
<jugglinmike> MarkMcCarthy: It only says "they are often functionally interchangeable". It doesn't say "always", but maybe we could say "sometimes"
<jugglinmike> MarkMcCarthy: I think this is a non-issue, though. I can see that they aren't exactly interchangeable, but APG isn't saying that they're exactly interchangeable.
<jugglinmike> RRSAgent, publish minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/04/18-aria-apg-minutes.html jugglinmike