Update Link color across the CMS to meet WCAG 2.0 AAA contrast requirement

[cjterdi]

Description

Reference design tickets:

9916: The standard link style is blue underline with a hover style of a light blue background and no underline. This combination of blue does not pass the WCAG 2.0 AAA contrast requirements.

9917: An accessibility audit found that on all products and all tables, the main content listing has tables that do not pass WCAG accessibility standards for hover states. Table rows currently have a hover state that changes to light blue.

9915: On staging, the footer links have a background color of light blue which introduces an accessibility issue.

See approved link design

The following changes to the links are documented here: CMS DS Changelog

• All standard links will be changed to the dark blue (004795)
• hover/focus state link color will be darker blue (003e73)
• We think having a background color would be beneficial as this would keep it as a similar format as the front end (they have a background color on hover) This is not an accessibility requirement.
• The hover/focus state should be the lighter blue (e4eff9). This is currently the color on some CMS links, not all. It is also different than the VA.gov front end hover color
• Footer links will remain white
• Footer links on hover/focus will keep their current background color (e4eff9) but the text will be darker blue (003e73)
• All links should have underline on default and then no underline on hover/focus

There is an additional condition for links in read-only content. To meet the same requirements we made an adjustment to the grey lighter color to #E5E3E1. See changes are documented here: CMS DS Changelog

Acceptance Criteria

• [ ] Implement the design changes listed above across CMS
• [ ] Design and accessibility review
• [ ] QA

CMS Team

Please check the team(s) that will do this work.

• [ ] Program
• [ ] Platform CMS Team
• [ ] Sitewide Crew
• [x] ⭐️ Sitewide CMS
• [ ] ⭐️ Public Websites
• [ ] ⭐️ Facilities
• [ ] ⭐️ User support

[EWashb]

As Edmund ramps up to the project, this may need to stretch. He is becoming familiar with the code base now and this is a good first task for him to do that.

[EWashb]

This ticket (the implementation) will stretch into sprint 65. however, this was not planned for sprint 64 specifically, just the work began as new dev was being onboarded.

[EWashb]

This could possibly be blocked for sprint 65 as Edmund is out sick

[laflannery]

This needs to be reopened after I was notified of some issues with some of the links. These are issues that Edmund and I had worked through and resolved previously. Examples are (but these are not all of them):

• Edit buttons within the Content Listing tables are now white - they should have remanined the color they were previously (I believe it was #212121)
• The active tab text is white
• The Content dropdown text is white
• Tabs have underlines

Screenshot of the first 3

Screenshot of the underlined tabs

I also happened to see all these issues when I was reviewing the Admin toolbar PR - I feel like it's not related to why this is all appearing now but I also felt like I needed to say it just in case

[EWashb]

@edmund-dunn fixing this will need to take priority over all other work this sprint.

CC: @dawnpruitt

[laflannery]

I think the below updates should fix the issues:

• Add .layout-container a.tabs__link { text-decoration: none; } This is needed to remove underlines from tabs

• Replace .layout-container a.button, .layout-container a.is-active, .layout-container a.feed-icon with .layout-container a.button, .layout-container a.pager__link.is-active, .layout-container a.feed-icon This will target only the active paging link instead of all active links

• Add table a.button, table a.button:not(:focus) { color: var(--button-fg-color) This will change the color of the table buttons back to the standard text color

  • You can't add this to the current declaration for table .button, table .button:not(:focus) that already exists - doing that will make unintended changes to the inputs within the edit nodes

I do think this will resolve the issues we are seeing and I don't think it will cause other interactions but obviously needs to be retested

[laflannery]

@edmund-dunn If you have a min can you take a look at this? This was the issue that got a bit confused and I think got reverted but then maybe we never went back and redid it. I'm not seeing your changes on Prod

[dawnpruitt]

@JayDarnell please reach out to @laflannery; this ticket isn't as clear cut as it first appears and she has the context you'll need. Thank you!

[edmund-dunn]

This was reverted because of regressions.