Update app colors to align with VADS/USWDS

[narin]

Description

On December 4, VADS updated their primary colors to align with USWDS. They updated most of the hex codes and removed primary dark.

On January 8, VADS updated their remaining colors to align with USWDS. They updated most of the hex codes and removed 5 additional colors (orange, coolBlue, coolBlueLight, coolBlueLighter, and coolBlueLightest.

The mobile app design system team created a spreadsheet for these updates.

Acceptance Criteria

In the va-mobile-app repo:

• [ ] Reconcile what to do about the 6 colors being removed
• [ ] Determine whether color tokens are ready to be pulled from va-mobile-library repo, or if we will just update the HEX codes in the this file
• [ ] Update existing colors based on the color changes outlined in this spreadsheet.
• [ ] Notify Brea and Jessica when the updates are complete, so they can update the Figma files.

[narin]

@dumathane This ticket replaces #8476 which you asked for some guidance on. Instead of replacing the hex codes directly in va-mobile-app's VAColors.ts, we recommend adding the mobile-tokens package as a dependency and referencing the colors we have there (instructions in the README). That way, if VADS updates their colors in the future, you can just update to the latest version of mobile-tokens instead of having to worry about hex codes down the line.

[theodur]

I updated the estimate to a 5 because there are a lot of unused colors in the app that need to be parsed through and removed. I figured since we're updating most of the app colors to use the component library tokens, we might as well clean up the colorsSchemes file.

[TKDickson]

OK had a very helpful meeting, here are some notes:

• @brea11y made a quick "before and after" sandbox for visual reference as well. Short version: light mode changes should be imperceptible, by and large, to the naked eye. Dark mode has more changes, but mainly that the grey highlight for many elements (boxes/cards/rows, but not necessarily all of those literal components in the code of course) is a little more grey.
• There are a number of places right now where we're not displaying the correct colors (ex: things that should be the new grey are split between an almost-black color, and a way-too-light grey). @jessicawoodin volunteered to review to add a specific list, for the things she can see/tell, to make it easier to fix those. Thank you!
• The new alert component isn't in yet, so alert component is just looking not right. I'm going to follow up in Slack about what sequencing makes sense for that.
• I also noticed that basically every component we touched during HSP doesn't have an active state. I'm going to follow up on that in Slack as well (to figure out the colors we want to be using, and the best way to do that work - I'm going to guess it'll end up as a separate ticket).

[TKDickson]

Wrote #9302 for the active state colors for HSP components.

[TKDickson]

We should still be OK to move forward with this changes, even without the alert component stuff (#8467 and #8468). Right now it looks like the current build is using either light or lightest yellow, and it should actually be using YellowVivid20/#face00, for the sidebar of the yellow alert. (Design system color reference)

Will send this back for changes, once the list of additional mappings/fixes is ready.

[TKDickson]

@jessicawoodin do you need anything from me (like a build...?) to be able to add the color mapping info to this ticket?

[jessicawoodin]

I pulled the color changes into the original spreadsheet and have several questions. I filtered this tab to only show the questions in column G. I think the darkmodeGrayWarmDark change will resolve at least one of the issues that @TKDickson found so far. Let me know if you have any other questions for me!

[theodur]

@jessicawoodin To answer your questions from the spreadsheet:

• primaryTextColor is currently not used in our dark mode theme, so it doesn't look like we need a dark mode color for that

• I do think the pickerControls color should be uswdsSystemColorGray80 instead, here are the comparisons: Before/after:

  Screenshot

    

• It looks like the menu color should be uswdsSystemColorGray80 instead also, here are the comparisons: Before/after:

  Screenshot

    

• veteranStatusHome, linkRow, and announcementBanner should all definitely be uswdsSystemColorGray80 IMO. These are all rendered on the home screen and here's the before/after: Before/after:

  Screenshot

    

• The nav color isn't used in the app in either light or dark mode

• After looking into the snackbar code, the snackBarText color isn't used in the app at all despite being in our color file. There's another color called snackBarTxt that's actually used for the snackbar text. The light mode color is vadsColorBaseLighter and the dark mode color is vadsColorBaseDarker which seems correct: Light/dark:

  Screenshot

    
  I'm probably going to remove snackBarText since it's not used, and rename snackBarTxt to just snackBar in the app code for consistency.

• statusDescription is also no longer used in the app for either light or dark mode

• closePanel is also no longer used in either light or dark mode

• buttonPrimary and buttonSecondaryDisabled are used in the Pagination component for the buttons that navigate forward/back:

  Screenshot

  

[jessicawoodin]

That all makes sense to me! The gray80 looks much better than gray60.

[theodur]

Awesome, thanks for confirming! Sending this back to QA

[TKDickson]

Much improved! There are a few places that should be greyer rather than blacker in dark mode (not a designer, can you tell?) - the inbox list rows, the prescriptions cards, the message boxes in message details, the disability rating rows, the box in contact VA (and those are the locations I specifically looked at, but the general idea is "all rows, boxes and cards like this in dark mode")

What they look like right now:

My best guess is that they're currently grey90, but are supposed to be grey80 (based on the before and after comparisons in Brea's sandbox). Screenshots from sandbox:

[TKDickson]

Seems like folks are generally on board with my suggestion to do visual QA only (instead of our typical "QA Eng take a look, then UX team does visual QA") on this ticket.

Still TBD who from the UX team would be doing that work, so I'm moving this ticket to blocked for now.

[TKDickson]

Reassigned QA to @rbontrager (part of QA rotation).

A note that the blocker on this is still, afaik, "finding and assigning a UX person to do the VQA (which is the bulk of the testing work on this ticket)". After which point QA can do an extremely quick functional pass if needed, at the discretion of the QA assigned. Every UX person I've talked to about this agreed that plan made sense, and explained to me why they personally were not the right person to do the VQA :). I have no horse in that race, so keeping the UX blocker on.

@ajsarkar28 @drjecker FYI

[htcollier]

I spoke with @jessicawoodin about this work today - based on that conversation, figuring out how to even go about doing this VQA feels like it's going to require some time to think through/plan, and needs its own ticket (it's not straightforward at all). I'm going to spin up a stub ticket based on what I understand so far.