Page MenuHomePhabricator

Update interactive styles of components: phase 1
Closed, ResolvedPublic1 Estimated Story Points

Description

Background

As a result of T341487: TextInput and TextArea: check the color contrast between default border and background we found that many interactive styles across components, mainly form elements, were not utilizing interactive tokens as intended in addition to potentially empty inputs not having enough contrast to meet accessibility criteria. These tokens should be uniformly used across similar interactive components.

Decisions

  • We should add new interactive tokens where they might be missing to make a complete interaction through all potential states of a component, including hover and active.
  • We will focus mainly on form elements in this task, with the addition of Card as it primarily uses interactive border tokens, similarly to form elements.
    • Card should keep it's lighter border color by default, then utilize interactive tokens when interacting. This is an intentional exception since the darker border on cards is not needed by default since there will always be content within a card.
  • We should ensure that error states match the same interactive token patterns where possible.
  • We will not address progressive tokens in this task.
  • We will use this update as an opportunity to update further styles, such as the background color of binary inputs to match the way nonbinary inputs are treated.
  • We should aim to create as much consistency and cohesion between all elements affected in this task.

Considerations

  • The patch for this task does include border-color-interactive--active in places where it is not technically noticeable because of how the focus style is applied on active in some instances. The consideration around changing this behavior will be handled in T377727: Make focus appearance consistent across Codex. Though it is not noticeable in all places based on that functionality, the token is still being applied here for the sake of consistency and in case we change the focus behavior.
Expected changes

Application.json

Token namenew, update, or remove?beforeafteradditional notes
background-color-interactive-subtle--hovernew-gray100
background-color-interactive-subtle--activenew-gray200
background-color-error-subtle--hovernew-red100
background-color-error-subtle--activenew-red200
border-color-interactive--hovernew-gray800
border-color-interactive--activenew-gray900
border-color-error--hoverupdatedred600red800
border-color-error--activeupdatedred700red900
color-error--hovernew-red800
color-error--activenew-red900

Dark.json

Token namenew, update, or remove?beforeafteradditional notes
background-color-interactive-subtle--hovernew-gray800
background-color-interactive-subtle--activenew-gray700
background-color-error-subtle--hovernew-red800
background-color-error-subtle--activenew-red700
border-color-interactiveremoved--This is removed as it should now be the same color in light and dark modes.
border-color-interactive--hovernew-gray300
border-color-interactive--activenew-gray200
border-color-error--hovernew-gray300
border-color-error--activenew-gray200
color-error--hovernew-red300
color-error--activenew-red200

Acceptance criteria

Design

  • Update the tokens and styles within components in Figma

Code

  • Update the tokens and styles within components in Code (patch)

Event Timeline

The patch for this task is https://gerrit.wikimedia.org/r/c/design/codex/+/1082065, though this patch was originally linked to T341487 before this task was created to better capture the changes being made.

Change #1082065 had a related patch set uploaded (by Dtorsani; author: Dtorsani):

[design/codex@main] tokens: Unify interactive styles phase 1

https://gerrit.wikimedia.org/r/1082065

I mentioned this in Gerrit, but I want to raise it here for visibility as well.

The linked patch includes a number of component style changes (larger than the current estimate warrants IMO).

Some of the changes are quite visually noticeable. For example, error states in components like TextInput or ChipInput are much more prominent.

Compare the old version:

Screenshot 2024-10-27 at 1.30.10 PM.png (314×1 px, 26 KB)

With the new version:

Screenshot 2024-10-27 at 1.30.42 PM.png (310×1 px, 25 KB)

If everyone is on board with making our error states visually "louder" then I don't have a problem with that, but I do think we might want to reconsider what we consider an "error" by default in that case (and duplicate text inside a ChipInput might not meet that threshold).

The more prominent an error style is, the more cautious we should be about applying it IMO – otherwise we may be causing the user some unnecessary stress/anxiety.

Fair to say that the changes might warrant a higher estimate for review. We could also separate out the error specific changes, but it will mean some inconsistencies throughout interactive input states until these would be added in. Either way, we could move this task to next sprint for further discussion and code review if we need to.

As far as the style of the error inputs, we [design] believe this is a more helpful change to indicate an error. There are a few things to keep in mind here.

Based on our guidelines, error states should be provided with an error message which provides helpful feedback on how to fix the error. The example of the ChipInput is not doing that, possibly because validation messages are a part of the Field component instead. However, we do provide this validation without a message in the configurable ChipInput, which we might need to reconsider, because we're not telling the full story.

In regards to the stronger visual style of error inputs, the background is there to provide additional affordance, since the contrast between a default or focused border and an error border is less than 1.5:1. For this reason, ultimately, we should not be relying on the visual style of the input itself to convey an error, but the error message below an input, as a part of a field. So, for those who can see this newly proposed error style which gives the input a subtle red background, and changes text and icons within a given input to red as well, it is additional visual guidance that something is wrong and needs to be fixed, especially when scanning a form or page.

When it comes to considering when we show an error state, I believe it should be when something is wrong and needs to be fixed—the user cannot continue until whatever is wrong is fixed. And therefore, we should call as much attention as possible [for those who can see it] to what needs to be fixed, potentially increasing speed to navigating to the thing that needs to be fixed and reducing the frustration with not knowing what is wrong that needs to be fixed.

Change #1082065 merged by jenkins-bot:

[design/codex@main] tokens: Unify interactive styles phase 1

https://gerrit.wikimedia.org/r/1082065

Change #1090947 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[mediawiki/core@master] Update Codex from v1.15.0 to v1.16.0

https://gerrit.wikimedia.org/r/1090947

Test wiki created on Patch demo by ATomasevich (WMF) using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/a2a0917c1b/w/

Change #1090947 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.15.0 to v1.16.0

https://gerrit.wikimedia.org/r/1090947

Test wiki on Patch demo by ATomasevich (WMF) using patch(es) linked to this task was deleted:

http://patchdemo.wmcloud.org/wikis/a2a0917c1b/w/