Re: [csswg-drafts] [css-forms-1] Switch input might need a state indicator (#11873)

The CSS Working Group just discussed `[css-forms-1] Switch input might need a state indicator`.

<details><summary>The full IRC log of that discussion</summary>
&lt;bramus> lwarlow: based on the previous changes, we have a switch input that looks fairly consistent with what you would expect<br>
&lt;bramus> … the main discussion point is on mobile (iOS and Android) they can sometimes ahve indicators on them to specificy which state they are in<br>
&lt;bramus> … part of this is because the WCAG req: color should not be only signifier for state<br>
&lt;emilio> q+<br>
&lt;bramus> … they just don’t have color though, but also position of the thumb<br>
&lt;bramus> … conditional on the writing mode<br>
&lt;bramus> … some people just put them the wrong way around<br>
&lt;bramus> … currently not necessarily meeting the WCAG req<br>
&lt;bramus> … mobile platforms have some ????<br>
&lt;bramus> … and other custom designs we found at Open UI: text on the track, symbol on the thumb, …<br>
&lt;bramus> … so Q is: do we need a state indicator? by default? can authors add on things?<br>
&lt;astearns> s/????/state indicator/<br>
&lt;bramus> … fantasai mentioned that potentially we might ask for feedback on the existing design<br>
&lt;bramus> … one thought: can have the checkmark pseudo generated on the thumb as the indicator<br>
&lt;astearns> ack emilio<br>
&lt;bramus> emilio: dont mind that, but think that if we have this bc its important for a11y we should have it by default<br>
&lt;miriam> q+<br>
&lt;lwarlow> q+<br>
&lt;astearns> Zakim, close queue<br>
&lt;Zakim> ok, astearns, the speaker queue is closed<br>
&lt;masonf> very strong +1 to emilio's comment. If this is an a11y issue, it should be on by default.<br>
&lt;bramus> … the value is much less generating the whole new pseudo – …  does a website have the context of when the should use the indicator? might need more work: what sort of MQ do we need to trigger it (when it’s not always there) and then we can see if we want to expose it, and if so we can add it by default<br>
&lt;masonf> Also +1 to just re-using the `::checkmark` pseudo for this purpose, on the thumb.<br>
&lt;bramus> … just generating a new pseudo that doesnt get any content by default is not discoverable and doesn’t do anything unless the website adds it. as an author i dont know which MQ to use to style this pseudo right now<br>
&lt;bramus> astearns: gonna have to take this back to the issue<br>
&lt;bramus> fantasai: wanted to point out that most pseudos accept the content property directly, so we might not need to add anything, although ::checkmark seems weird<br>
&lt;astearns> ack miriam<br>
&lt;fantasai> s/although/also<br>
&lt;astearns> ack fantasai<br>
&lt;masonf> ...by "on by default" I mean the UA stylesheet should have `content: something`<br>
&lt;bramus> miriam: agree that this should prolly be the default. switches without an indicator are very confusing. want this to be discoverable. ::checkmark is what I would expect, same sort of styling from a checkbox<br>
&lt;fantasai> I would expect the `::checkmark` to *be* the thumb, if it were to exist.<br>
&lt;astearns> ack lwarlow<br>
&lt;bramus> lwarlow: styling wise it could be content on the ::thumb, the styling would prolly be a tick<br>
&lt;bramus> … re default or not and which MQ<br>
&lt;bramus> …  prefers-contrast-more is a slightly indirerct one<br>
&lt;bramus> … also see issue 7406<br>
&lt;fantasai> Like if we wanted to style switches using ::checkmark instead of the slider pseudos, I'd understand. But adding ::checkmark on *top* of the slider pseudos... seems weird.<br>
&lt;bramus> … given the privacy problems that might not happen<br>
&lt;masonf> For customizable select, we decided not to include media queries (e.g. touch) in the UA stylesheet. I think we should follow that decision.<br>
&lt;bramus> … need to decide if we want it by default, or conditional<br>
&lt;bramus> astearns: that’s it for forms for today<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11873#issuecomment-3921999380 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 18 February 2026 17:01:50 UTC