After looking into this some more and discussing with @AnneT, I agree that it does not make sense to add the label as a required prop to the ToggleSwitch or any of the other binary input elements. We should be doing as much as possible to ensure Codex users are conforming to accessibility standards, but turning the label into a prop would be too restrictive. There are also multiple ways to assign a semantic label to an input in HTML.

Closing as duplicate because IMO this work is already captured in T333144: Create MVP version of "Codex as Wikimedia Design System" and T324228: [EPIC] Codex as Design System for Wikimedia more generally.

I also agree it would make sense to just re-implement it in Codex. That would ensure it is consistent with Wikimedia's design language generally.

@Sarai-WMDE maybe we merge this with T338598: Update Typography guidelines in Codex Style guide instead and then close this?

I think we can do it as part of T338598: Update Typography guidelines in Codex Style guide. Maybe we can move the content from T309158: Update Wikimedia Design Style Guide with typeface choices there and then close it?

Given that this is already unsupported in OOUI, I would lean towards declining this task for now. I couldn't find anything on why it isn't supported by Apple, but I'd guess it might have something to do with the fact that even when used on a supported mobile browsers, interfacing with a textarea grabber is unintuitive and I don't see it as a pattern we would actively encourage when the anticipated input method is touch. In my opinion, we should add a warning to the docs and provide guidelines that highlights not relying on the user manually resizing the textarea when optimizing for mobile experiences.

Hey @stjn, not all of the messages have been overriden locally by admins in the projects. As you can see for https://ru.wikipedia.org/wiki/MediaWiki:Wikimedia-copyrightwarning, there is no edit history, meaning the copyright messages are actually configured from the translation strings in the WikimediaMessages extension. We've updates all the messages there to 4.0 as well, but it will take time for it to roll out to everyone on all projects (see the linked patches above).

I'm wondering if this might be something worth looking into, because in my mind it appears to be a bug:

I am going to decline this task as-is. We will likely still support the Wikistats migration to Codex, but this task is stale and may not be representative of the approach we will take.

I'm going to resolve this task for now. It is a massive task and bulk of the work has been completed. The remaining work is captured in follow up subtasks that are on the Design Systems Product Roadmap board or the team backlog.

Moving this to "Following" for now since DST isn't actively working on this ticket, even though we were working on some of the related tasks. We may put this on another board in the future (potentially a "DST Roadmap" or "Collaborations" board).

I agree we should leave it to a follow up task. We should also consider whether or not CSS-only components should be considered part of an MVP component, or if they should be "planned component updates" that are created at time of MVP component implementation. Is there a task for this already? If not I can create one!

Thanks @AnneT! Yeah let's keep this ticket as written and hold off on the "full support" until there is a clear need.

For me, this isn't a legitimate use, but instead it's an example of exactly the problem I am trying to point out! The "Skip all" button looks almost the same as the nearby text. It's only identifiable due to its placement (although imagine the mockup being in Arabic rather than English, with right-to-left text direction: I'm sure none of us who don't speak the language could confidently identify which is the title and which is the button in that case). It's not terrible, but if the button was instead an "x" icon, or if it had a button frame, it would be better. The text-only quiet button is always the worse option.

Is a functional CSS-only implementation possible for this component, or the expand/collapse behavior entirely JS-based?

In T336676#8866558, @Xover wrote:

Ignoring implementation details, does it really make sense to consider that control a "button"?

@bmartinezcalvo I think this task should focus on the button specifically, and can include work to add the Figma spec for it.

Hey @matmarex, thanks again for reporting this. Was there an underlying issue you ran into that prompted this, or was it just a general observation when going through the docs?