Upgrade USWDS from v3.4.1 to v3.6.0

[aduth]

Upgrades USWDS to its latest version, from 3.4.1 to 3.6.0.

Release notes:

• https://github.com/uswds/uswds/releases/tag/v3.5.0
• https://github.com/uswds/uswds/releases/tag/v3.6.0

Also updates dependabot.yml to change the dependency name (the npm package was renamed from uswds to @uswds/uswds in v3.0.0), since the purpose of the configuration is to automate these updates.

Blocked: There's a build issue that needs to be sorted out. Also reported upstream at uswds/uswds#5334 . Edit: This is now fixed in USWDS 3.6.0.

[aduth]

Checks aren't triggering 🤔 Will try closing and reopening.

[aduth]

3.6.0 changed some details around disabled colors which is triggering the visual regression failure and inverting the disabled button color. I'll need to investigate.

Before: https://federalist-340d8801-aa16-4df5-ad22-b1e3e731098e.sites.pages.cloud.gov/site/18f/identity-design-system/buttons/
After: https://federalist-340d8801-aa16-4df5-ad22-b1e3e731098e.sites.pages.cloud.gov/preview/18f/identity-design-system/aduth-uswds-3-5-0/buttons/

Before	After

[aduth]

@nickttng When you have a moment, I might want to tag you in here to weigh in on a couple things:

• USWDS has removed text anti-aliasing effect in most places, which is causing the text to appear somewhat bolder in some browsers. Are we okay with this? Do we want to manually restore the anti-aliasing? I know this is a contentious topic, but the extra boldness is pretty jarring in my opinion.
  • Before: https://federalist-340d8801-aa16-4df5-ad22-b1e3e731098e.sites.pages.cloud.gov/site/18f/identity-design-system/buttons/
  • After: https://federalist-340d8801-aa16-4df5-ad22-b1e3e731098e.sites.pages.cloud.gov/preview/18f/identity-design-system/aduth-uswds-3-5-0/buttons/
• USWDS changed the disabled button colors to dark text on gray background, which is different from previous white text on gray background. I assume this is for improved contrast. Our disabled color was already darker and thus had more contrast to begin with, but diverging from the new USWDS default disabled text color will probably cause us some friction, since they automatically assign the default text color as "disabled dark", thus requiring us to set "disabled-dark" as "white" to restore our original colors. This could probably cause issues if the token color were ever used in a situation where a dark color is actually expected.
  • Question: Should we change our disabled button colors to align better? At least with darker text color instead of white?

[nickttng]

@aduth

Anti-aliasing
Did USWDS note a reason(s) why they have removed the anti-aliasing effect? The outcome with the extra boldness is noticeable and jarring in some places. I am okay with restoring the anti-aliasing until we know why it was removed.

Disabled button colors
Aligning to USWDS' change makes sense here. I generally see more disabled button patterns as dark text on a light/gray background. It is distinctive from our current primary/default buttons with a solid dark background.

[nickttng]

@aduth When it's merged, I'll update the disabled buttons in the Figma library.

[aduth]

Did USWDS note a reason(s) why they have removed the anti-aliasing effect?

I traced it back to the work here: uswds/uswds#5250

Related issue: uswds/uswds#5180

They mention one of the reasons is it being unsupported: https://developer.mozilla.org/en-US/docs/Web/CSS/font-smooth

I'm not really compelled by the case, though I also wonder if it's a battle worth fighting, considering that everything seems stacked against the use of this style. I'm also not sure how much effort it'd be to bring back for all the places it may have been removed, so I'll take a look.

[aduth]

Couple updates here:

1. Moved to greater alignment on disabled colors with USWDS (see example)

I tried to approximate this as close as possible with our "grey" color family, but it's somewhat lighter than USWDS. That's because USWDS uses gray-20 as their starting point for "lighter", whereas "lighter" is typically associated with -10 on the color scale, incrementing next to gray-30 as "gray-light". I chose to opt for semantic alignment (i.e. "disabled-lighter" = "grey-lighter"), but this means it's the equivalent of a grey-10. We could opt for darker by bumping up the scale (i.e. "disabled-lighter" = "grey-light" = "grey-30") if we wanted.

@nickttng Any thoughts here? Personally I think it could work as-is.

2. On the point of font-smoothing:

I'm feeling like it's a losing battle to try to keep the font-smoothing:

1. Maintenance overhead of diverging from USWDS
2. It's only supported in specific browsers and operating systems (i.e. Apple operating systems), which could end up being a gap in our awareness for how many of our users experience our sites
3. The general sentiment around it is not positive[1][2], including some compelling arguments toward it altering the intended/ideal representation of fonts
4. Maybe the contrast is especially jarring since we're comparing side-to-side, and it won't be as problematic after we've come to adjust to it

One possible compromise I'm wondering is if we should consider changing some bold font weights to normal. I was actually surprised that button text is bolded by default (from USWDS)? Maybe overriding that to normal font weight could make the change less noticeable.

Bold, with font smoothing (original)	Bold, without font smoothing (current branch)	Normal, without font smoothing (idea)

Obviously this just applies to buttons, but maybe (a) that's the most "problematic", and (b) are there others we could do similar? e.g. navigation current link.

@nickttng Are you okay with dropping the font smoothing? Any interest in the idea above to override font weight for buttons?

[nickttng]

@aduth Thanks for the context

@nickttng Any thoughts here? Personally I think it could work as-is.

Yes, it works as-is

@nickttng Are you okay with dropping the font smoothing? Any interest in the idea above to override font weight for buttons?

Yes, okay with dropping the font smoothing. The normal w/o font smoothing appears to be a better approach than the bold w/o font smoothing. My concern with the normal version for the danger version is that its contrast ratio (4.7:1) is near the edge of inaccessibility (Under 4.5:1) and with the decreased weight, it might be more difficult to read. I wonder if that's one of the reasons USWDS proceeded with the bold(er) approach, visually.

What do you think about proceeding with what USWDS has established? And we would keep an eye out via user feedback / usability studies?

[aduth]

What do you think about proceeding with what USWDS has established? And we would keep an eye out via user feedback / usability studies?

If you mean (1) dropping font smoothing and (2) keeping the default bold text, then yes, I'm okay with that, and it simplifies things to stay in alignment with USWDS 👍

In which case, all of that should be reflected in the current preview branch, so I think we're good to move forward if we're okay with everything there?

https://federalist-340d8801-aa16-4df5-ad22-b1e3e731098e.sites.pages.cloud.gov/preview/18f/identity-design-system/aduth-uswds-3-5-0/buttons/

[nickttng]

In which case, all of that should be reflected in the current preview branch, so I think we're good to move forward if we're okay with everything there?

Yep, with 1) dropping font smoothing and 2) keeping the default bold text. 👍🏼

[aduth]

I may hold off temporarily on publishing a new version, since I believe a new patch release of USWDS should be landing soon. Their monthly newsletter from 10 days ago mentioned a 3.6.1 release on the horizon.