Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[switch] Should the switch element support swipe actions? #1045

Open
gfellerph opened this issue Apr 26, 2024 · 7 comments
Open

[switch] Should the switch element support swipe actions? #1045

gfellerph opened this issue Apr 26, 2024 · 7 comments
Labels
needs edits This is ready for edits to be made WHATWG This change impacts a WHATWG spec

Comments

@gfellerph
Copy link
Contributor

A question that came up while doing research on the switch element. In the Material 3 Switch Accessibility documentation, it's stated that a dragging movement should toggle the switch. This feature is rarely implemented in other Design Systems. What should the explainer recommend?

@scottaohara
Copy link
Collaborator

without rational as to why dragging was included as a way to toggle, it seems unnecessary/out of place, imo. the hit area of a switch is generally so small, that i question how often someone would even want to drag - especially if the control needs to also support click/tap. dragging is more effort (for implementation and as a user)... why even do that?

@gregwhitworth gregwhitworth added the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Apr 30, 2024
@gregwhitworth
Copy link
Member

@scottaohara is the original "Swipe to Unlock" paradigm a switch, button, other?
image

Visually it represents a switch and I would denote that it is a bool that has an indeterminate state akin to "not lifting" on the invoking input (eg: spacebar up, mouse button up) remove focus/hit testing. That said, I don't think that the events are actually bound to that but the usecase above has either "Locked" or "Unlocked" and is using a switch to handle this.

@scottaohara
Copy link
Collaborator

I wouldn’t consider that a switch. I cant recall ever seeing one of those implemented as a switch.

A button or some sort of custom slider is typically what I remember seeing these implemented as. Even thr “good” ones often had a11y issues in not providing someone an alternative to sliding/dragging to activate.

@brechtDR
Copy link
Collaborator

brechtDR commented May 2, 2024

This feature is rarely implemented in other Design Systems. What should the explainer recommend?

@gfellerph As you stated... it's something so rare. I personally never had the intention to swipe these kind of controls. I haven't seen it as well. I think it's safe to say that most authors won't have a need for it and those that do, will probably want to create such a custom action that it requires some extra scripting anyway.

@css-meeting-bot
Copy link

The Open UI Community Group just discussed [switch] Should the switch element support swipe actions?, and agreed to the following:

  • RESOLVED: Switch should support gesture support akin to the range control; normative text to be defined at a later point
The full IRC log of that discussion <bkardell_> Proposed Resolution: no
<brecht_dr> gregwhitworth: Should the toggle support gestures?
<brecht_dr> q+
<masonf> q+
<bkardell_> s/Proposed Resolution: no/I think no
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: I commented on that, I've personally never seen this behavior and I think it's special and I don't think it's something that should be standardized
<gregwhitworth> brecht_dr: if someone desires this they'll implement it themselves already
<gregwhitworth> q+
<gregwhitworth> ack masonf
<keithamus> q+
<brecht_dr> masonf: My soft opinion, is i agree with that. The one example I wonder about was the example of the iPhone unlock, but the question is if this is actually a switch to begin with.
<brecht_dr> gregwhitworth: I used that example because that during the switch conversations, we had a bunch of "range discussions". Because these are pretty similar
<flackr> q+
<brecht_dr> gregwhitworth: On switch, i'm not super passionate about it, one way or the other. But for a "range" example, i think it should support gestures
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack keithamus
<brecht_dr> keithamus: I just tried this out on iOs and you can drag it, or even hold it
<brecht_dr> keithamus: Might not be default UX, but seems to work there
<scotto> q+
<gregwhitworth> ack flackr
<brecht_dr> gregwhitworth: Not on android, there it is just click
<gregwhitworth> nm, I'm incorrect. Androis OS does, I had tested a different app that used it's own toggle that didn't
<masonf> q+
<gregwhitworth> s/Adrois/Android
<bkardell_> just because we don't specify it doesn't mean browsers can't implement it, right?
<brecht_dr> flackr: I know there are concerns about gesture, we expose some things on a higher level. I don't think there will be a problem with a higher level thing. There are many examples with universal gestures such as long press for context info
<gregwhitworth> ack scotto
<brecht_dr> scotto Thanks for pointing that out, keithamus. I'm not a fan of the interaction. But after holding it just goes to the next state, which seems odd, you can't undo it.
<gregwhitworth> ack masonf
<brecht_dr> masonf: You can drag continiously back and forth on IOs, it makes it feel more like a range. So maybe the right way should be to treat it as a range?
<brecht_dr> gregwhitworth: The issue is about dragging movement, are we talking about dragging in HTML
<scotto> q+
<brecht_dr> flackr: dragging in HTML is something completely different.
<gregwhitworth> ack scotto
<flackr> q+
<brecht_dr> scotto: It was in the accessibiliyt secion of material 3, I don't really understand what the reason for that is. There are some specific accessiility rules about dragging
<gregwhitworth> ack flackr
<masonf> +1 to click and keyboard activation needing to also work.
<brecht_dr> scotto: It feels more like a gimmick than a feature, and we need to be careful about that
<gregwhitworth> Proposed Resolution: Switch should support gesture support akin to the range control; normative text to be defined at a later point
<brecht_dr> flackr: It could be like "panning" on a switch. This is a gesture we have a term for
<bkardell_> q+
<gregwhitworth> ack bkardell_
<gregwhitworth> q+
<gregwhitworth> ack gregwhitworth
<brecht_dr> bkardell_: Because switch is going to be part of input and by default, input uses platform conventions (based on the OS). Wouldn't it take the convention of the platform (such as focus, colours, etc)
<masonf> q+
<brecht_dr> bkardell_: Can we even specify that?
<gregwhitworth> ack masonf
<brecht_dr> masonf: one question is " what is in the spec", and you're right, absolutely nothing, it's based on the OS as you stated
<brecht_dr> masonf: But, I'm hoping we can break out of that, so that users know what to expect
<gregwhitworth> q?
<gregwhitworth> Proposed Resolution: Switch should support gesture support akin to the range control; normative text to be defined at a later point
<brecht_dr> masonf: Because we're making new tings
<masonf> I'm always trying to make new tings.
<masonf> +1
<keithamus> +1
<brecht_dr> +1
<Travis_> +1
<gregwhitworth> RESOLVED: Switch should support gesture support akin to the range control; normative text to be defined at a later point
<brecht_dr> masonf: Correction: Because we're making new things*

@gregwhitworth gregwhitworth added needs edits This is ready for edits to be made WHATWG This change impacts a WHATWG spec and removed agenda+ Use this label if you'd like the topic to be added to the meeting agenda labels May 8, 2024
@yisibl
Copy link

yisibl commented May 17, 2024

The Switch in iOS is draggable, which I think is a very desirable interaction.

@lukewarlow
Copy link
Collaborator

Fwiw the switch on android is draggable too. I think it feels semi natural for a touch input. I'd probably find it odd if it was with a mouse though?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs edits This is ready for edits to be made WHATWG This change impacts a WHATWG spec
Projects
None yet
Development

No branches or pull requests

7 participants