[switch]: Should author defined content be allowed on tracks or thumb?

gfellerph commented 11 months ago

I'm working on the switch proposal pull request. @scottaohara raised multiple concerns with author defined content inside the different parts of the proposed <switch> element.

Question

Should authors be able to add text content to either the track or the thumb elements?

Research

About a third of analyzed Design Systems use this feature (Design System Analysis section in the pull request).

30% display content on the track
18% display content on the thumb

Example: https://ant.design/components/switch

Accessibility concerns

Content mapping will be difficult since it's a new concept
The switch is already described by its label and content should be ignored

_Relevant comment: https://github.com/openui/open-ui/pull/785#discussion_r1396420527_

Layout issues

Custom content can have various layout issues.

The content on both sides cannot be wider than the thumb. Otherwise, the thumb is no longer capable of hiding the content of the inactive track content.
It’s unclear how to style the track and slider if the track content can be of arbitrary length

Live example on codepen using ant design system

Possible solutions

Allow for author defined text/content and find solutions to the above issues
Don't allow for author defined text and risk not adressing all existing use cases
Only allow decorative images or svg content, which covers most use cases and avoids the above issues mostly
...?

lukewarlow commented 11 months ago

My initial reaction is I think we should allow content(image/SVG is probably enough but enforcing this seems difficult?) in the thumbs (but this should be hidden from screen readers) I'm less sure on use cases for tracks.

css-meeting-bot commented 11 months ago

The Open UI Community Group just discussed [switch]: Should author defined content be allowed on tracks or thumb?.

The full IRC log of that discussion

<gregwhitworth> q+
<hdv> Philipp: I analysed a couple of design systems… some put content on the track or thumb parts (30% of the ones I analysed on the track and 20% on the thumb)
<hdv> Philipp: it's usually a checkmark… in Ant design system they even put text in there
<hdv> Philipp: I also put a Codepen together
<Philipp_Gfeller> https://codepen.io/tuelsch/pen/dyajRZe?editors=1010
<masonf> q+
<brecht_dr> q+
<hdv> Philipp_Gfeller: question is, should this be a allowed or not?
<scotto_> q+
<hdv> gregwhitworth: this doesn't only relate to switch, also to slider
<gregwhitworth> https://open-ui.org/components/slider.research/
<hdv> gregwhitworth: there are all sorts of scenarios where you'd want complex content
<hdv> gregwhitworth: maybe you would put it absolutely position it relative to the inside, for instance
<hdv> gregwhitworth: not sure how that would work for a switch
<hdv> gregwhitworth: even with checkbox you could get the same question as for switch
<hdv> gregwhitworth: so I'd say yes… would go back to selectlist discusion: do we limit interactive content to be placed inside of that?
<hdv> gregwhitworth: otherwise I feel you should put whatever you want in that
<gregwhitworth> ack gregwhitworth
<bkardell_> q+
<bkardell_> q-
<gregwhitworth> ack masonf
<hdv> masonf: there's the allow anything or the pseudo element approach … when you did your research, how many times would you not be able to do what you wanted with just the pseudo element?
<gregwhitworth> q+
<hdv> masonf: elephant in the room for this, there is a PR to HTML right now that introduces a switch element using just the input element, we should also consider that
<hdv> Philipp_Gfeller: I didn't differentiate between cases that would be possible with input checkbox switch and not
<hdv> masonf: but in most of your examples it seems mostly text?
<hdv> gregwhitworth: the night and day, with complex animations between sun and moon, they could be complex svgs?
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr: when it comes to textual content, Ant handle that well
<hdv> brecht_dr: personally, I created switches like that, with content inside of the track, it happens quite often
<hdv> brecht_dr: when it comes to images/svgs, I worry it has accesibility concerns, like you would need a description for that image, we shouldn't forget that
<gregwhitworth> ack scotto_
<bkardell_> +1
<hdv> scotto_: I have the exact opposite opinion… I haven't seen one where the text content on the track does anything more than repeat the accessible state… if it's doing just that it's generally fine
<bkardell_> sorry my +1 was to scotto_
<hdv> scotto_: it probably should not be included in the name computation for the switch… if the text says 'on' or 'off that's great but if someone puts in gobblygook but the text means something different, we run in a weird situation, where that isn't supposed to be the name of the item (supposed to be a label for the switch altogether, would not go on the track)
<hdv> scotto_: to Greg's example, night / day time thingy, the label of that should be 'Enable night mode', the night icon might represent the off state and the day the on state… if you put extra information there, we would not have a way right now to expose that in terms of accessibility
<hdv> scotto_: so show me an example where people do this and have done it acessibly (as in the content inside of it isn't lost, or used inappropriately as a label)
<bkardell_> q+
<hdv> scotto_: lots of potential WCAG issues
<hdv> gregwhitworth: I view input type switch pretty similar to selectlist and select
<bkardell_> q-
<hdv> gregwhitworth or the PR with pseudo els that are interoperable across progress etc…it's good but will have limitations , there is a graceful onramp here
<hdv> gregwhitworth: that would probably not violate the 'consistency of the platform' principle of whatwg
<hdv> masonf: my concern would be… there seems to be generally concerns around having two elements that do the same thing on the platform
<hdv> gregwhitworth: seems like a discourse we should have
<bkardell_> I just wanted to say other had said "this happens quite often" and I would like to see the examples to discuss what scotto_ said. I was in the queue at the beginning but I knew scott was probably going to say the same thing, only better. I agree with what scott said, but I would be really interested to see if you really think there are use cases that can't be done, but can be done accessibly somehow
<hdv> masonf: there are some real use cases and things design systems can do that are not possible with that specific proposal, I think they should be raised on that issue
<masonf> The issue is here: https://github.com/whatwg/html/issues/4180
<hdv> gregwhitworth: in response to scotto_… I think it may need updates to the name computation specification for the switch element… you should be able to have two different states that could also be the label without them actually being the label… not sure if day and night would be very good labels, but there should be ways to make that go to accessible name
<hdv> gregwhitworth: though we don't want to fall in the pit of success
<gregwhitworth> ack gregwhitworth
<hdv> scotto_: sure… alternative would be for us to define something (just saying relying on the current name/description computation isn't going to yield accessible results)
<hdv> gregwhitworth: I would like that to work
<hdv> scotto_: it would be a new feature
<hdv> gregwhitworth: sure
<una> q+
<hdv> scotto_: I do worry we would not be setting devs up for success
<gregwhitworth> ack una
<hdv> una: this may be controversial… I don't think I've seen examples where text on the track improves the user experience
<Philipp_Gfeller> +q
<gregwhitworth> +1 to una from an ROI perspective
<hdv> una: would probably say it's not a best practice to put text in tracks… and feel like it probably doesn't need to be part of our MVP, especially thinking of what kind of problems it solves
<Luke> q+
<hdv> [scott hands out more cookies]
<gregwhitworth> ack Philipp_Gfeller
<hdv> Philipp_Gfeller: personal opinion… I don't think the way Ant does it is particularly helpful, it's quite fiddly and complex to get it right
<brecht_dr> q+
<gregwhitworth> ack Luke
<hdv> Philipp_Gfeller: also for colour blind folks discerning is harder if there is only colour
<hdv> Luke: re text or content in a track, I agree with una, probably doesn't make sense
<hdv> Luke: inside of a thumb, there probably are some use cases, like there's a setting in my OS to prefer shapes
<gregwhitworth> q+
<hdv> Luke: for the thumb you probably would get the same issue re accessible name
<gregwhitworth> ack brecht_dr
<gregwhitworth> ack gregwhitworth
<Luke> q+
<hdv> brecht_dr: isn't it a UX affordance, when the thumb is on the right side it means on and left side it's off?
<gregwhitworth> ack Luke
<hdv> Luke: I have seen switches that are the wrong way around
<Philipp_Gfeller> +q
<gregwhitworth> q+
<gregwhitworth> ack Philipp_Gfeller
<hdv> Philipp_Gfeller: the minority of the design systems implemented a vertical writing mode
<una> q+
<gregwhitworth> ack una
<hdv> una: Adam has some nice demos: https://gui-challenges.web.app/switch/dist/
<Luke> q+
<hdv> una: in one example there is also a indeterminate state, may be tricky if we put content in off or on state
<hdv> gregwhitworth: we're focusing on text content used as some kind of label, but it could maybe also be text content for other reasons? can't think of an example now but it feels odd to not allow for it at all
<una> +1 thumb instead of track
<gregwhitworth> ack gregwhitworth
<hdv> gregwhitworth: in terms of visual changes, are you saying additive?
<hdv> s/gregwhitworth/una
<hdv> gregwhitworth: set aside the content to be related to state… we would recommend folks not to put text in there that would really be a label… but maybe people want to put things in their for aesthetics?
<keithamus> q+
<gregwhitworth> ack Luke
<hdv> gregwhitworth: or maybe some interactivity on a canvas? would we want to prohibit all of that?
<hdv> Luke: I don't know if switches have indeterminates? as far as I am aware switches are meant to be binary, which is what differentiates them from checkboxes
<hdv> Luke: was also thinking…if you wanted to do more complex content, could you not just have that as siblings that you style?
<hdv> gregwhitworth: I meant on the thumb… for the thumb on the range slider, maybe you'd add like a tooltip that shows you which percentage you are?
<hdv> gregwhitworth: just thinking we shouldn't prohibit… maybe instead have a console warning to explain what not to do?
<dbaron> as a user, I often have trouble telling whether labels on switch-like controls are telling me (a) the current state or (b) what I get if I press it
<hdv> gregwhitworth: maybe even only allow a subset of elements?
<hdv> una: was thinking of that…but maybe that's unexpected?
<hdv> gregwhitworth: we're hitting a friction between accessible by default and extensibility
<scotto_> q+
<hdv> gregwhitworth: the old school polymer buttons come to mind, the ones with a ripple effect
<hdv> gregwhitworth: what if there's an effect like that that I couldn't achieve in just CSS
<keithamus> https://primer.style/components/toggle-switch
<gregwhitworth> ack keithamus
<hdv> keithamus: Primer, the design system I work on… we put symbols in the track, stylised I and O when it is off
<gregwhitworth> ack scotto_
<hdv> keithamus: from engineering, I'd like to make these switches use the new toggle switch, but what if I can't, what can I do?
<bkardell_> q+
<hdv> scotto_: to be fair… I don't want to restrict everything… sure put in svgs there… but people shouldn't put long texts in there that shouldn't be in there
<gregwhitworth> q+
<hdv> scotto_: manybe we could allow just svgs
<gregwhitworth> ack gregwhitworth
<hdv> scotto_: even if people could still put text in svg
<gregwhitworth> q+
<hdv> [scott gives them a cookie too]
<hdv> scotto_: but I think it'd be valuable to say people can't put arbitrary text in there
<gregwhitworth> ack bkardell_
<hdv> scotto_: if we allow for arbitrary content, we can't just do that without also thinking about what we should do when people do put arbitrary content, because currently there is no way to expose the accessibility info
<hdv> bkardell_: +1 to everything scott ha sbeen saying
<hdv> s/h asbeen/has been
<hdv> bkardell_: this is a lot like with generated content… you're only supposed to put things there that are decorative, but people do put stuff in there that is not decorative, and then we have to deal with it
<hdv> q+
<gregwhitworth> hdv: I agree with that point on generated content
<gregwhitworth> hdv: its decorative and now it has to be in the accname because they put what they want in there
<gregwhitworth> bkardell_: if I can add to that, it's worse than that
<gregwhitworth> bkardell_: where there are experts parroting two conflicting things
<gregwhitworth> bkardell_: they'll say only things that are decorative but it's not because it won't be exposed because they are now
<hdv> gregwhitworth: I feel there was a lot of good discussion on this today, looks like no resolution
<hdv> gregwhitworth: Philipp_Gfeller could you please split the issues into one for track and one for thumb so we can resolve them separately
<gregwhitworth> q?
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack hdv

brechtDR commented 11 months ago

After the Telecon, i did found another example where a switch could mean something else than on/off in a codepen. how about am/pm? (Yes, i was fishing for cookies)

https://codepen.io/bnthor/pen/WQBNxO

scottaohara commented 11 months ago

@brechtDR that's really more of a radio button then that has been restyled to look like a switch (or per your example, it's a control that visually is clear, but is nonsensical in as far as how it is programmatically exposed. e.g., "AM PM, checkbox. checked (or not checked)" what the heck does a checked "am pm" control mean? AM and PM are the states someone wants instead of 'checked' or 'not checked')

i see stuff like this a lot as well, where people "want" the visual design of one type of control, but they style it to resemble a different control type - or they use the control they want in a way that distorts its intended use.

brechtDR commented 11 months ago

@scottaohara i agree with this. My question is rather if people won't be looking to use it for those purposes. It's a hard path in this case: design vs function. But maybe I don't really understand the big need for this and am just biased as I've been styling these things with checkboxes too much. Maybe I'm a bit "scared" that the use case and need is too specific or limited. But that is subjective and thus a personal opinion of course. I can understand other people want this in its purest on/off-but not a checkbox way.

lukewarlow commented 11 months ago

https://twitter.com/jh3yy/status/1733296190244979015?t=f_lc95VlAVjp20jZBTXpNg&s=19

Maybe a benchmark of crazy design to see if any proposal can manage 😅

gfellerph commented 10 months ago

@brechtDR another example like this, from the Swiss railways (https://www.sbb.ch/) for the departure/arrival control (at least this one is a radiogroup, but looks like a switch).

@lukewarlow awesome example, I was looking for this to reference in the proposal but could not find it anymore.

I'm wondering if this would be something that could be made easier for devs by adding accessibility bindings to a switch which allows content on the track.

<label for="timetable">Show timetable for</label>
<switch id="timetable">
  <track>
    <trackstart><abbr title="Departure">Dep</abbr></trackstart>
    <trackend><abbr title="Arrival">Arr</abbr></trackend>
  </track>
</switch>

Which could read something like "Departure, selected, switch, 1 of 2". @scottaohara, would this even make sense?

This, however, would strongly contradict the idea that the switch is a binary state of a single value.

lukewarlow commented 10 months ago

https://github.com/whatwg/html/pull/9546#issuecomment-1865357407 - The HTML proposal from Apple has an implementation to try which might be useful. Currently it supports content attribute on tracks and thumbs

github-actions[bot] commented 2 months ago

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

openui / open-ui