Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create accessible hover state for staging environment footer links #9915

Closed
5 of 6 tasks
Tracked by #9965
EWashb opened this issue Jul 27, 2022 · 10 comments
Closed
5 of 6 tasks
Tracked by #9965

Create accessible hover state for staging environment footer links #9915

EWashb opened this issue Jul 27, 2022 · 10 comments
Assignees
Labels
a11y-defect-1 Critical accessibility issue that should be fixed in the next sprint CMS Team CMS Product team that manages both editor exp and devops

Comments

@EWashb
Copy link
Contributor

EWashb commented Jul 27, 2022

Background

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

Image of defective area:

Screen Shot 2022-07-27 at 12 17 14 PM

Accessibility Standard

WCAG version 2.0 AA, Criterion 1.4.3

Acceptance Criteria

  • Another hover state should be set with a different background color and different text color that is WCAG accessible
  • Define a set of link and hover state colors that are accessible and consistent across the system.
  • Review changes with Accessibility Lead
  • Document changes in CMS DS and changelog
  • tech feasibility review for desired fixes
  • change management is consulted
@EWashb EWashb added CMS Team CMS Product team that manages both editor exp and devops a11y-defect-1 Critical accessibility issue that should be fixed in the next sprint labels Jul 27, 2022
@EWashb
Copy link
Contributor Author

EWashb commented Jul 27, 2022

Class for hover may not be specified in the CSS

@EWashb
Copy link
Contributor Author

EWashb commented Jul 28, 2022

Hey team! Please add your planning poker estimate with ZenHub @cjterdi @laflannery

@EWashb
Copy link
Contributor Author

EWashb commented Aug 1, 2022

@laflannery is going to double-check the FE standard for links to help inform our path forward

@laflannery
Copy link
Contributor

@EWashb @cjterdi There isn't a clear consensus on if the hover state falls within the 3:1 requirements. Based on research I did, some specialists definitely say yes whereas even on the WebAIM site they use a background color hover state that does not meet this ratio.

Another issue that may sway the decision on this - Taking the point about not making this too "busy" and trying to find a background hover color as light as possible within the 3:1 ratio I'm not sure will be possible if we also want a 7:1 ratio with the link text on top of it. I think we will need to choose which ratio we want to make a priority.

Some points to help make this decision:

  • The 7.1 ratio is a 2.0 AAA criterion and the 3.1 ratio is a 2.1 AA criterion.
  • There is no requirement that there must be a background color on hover/focus
  • Having a link on standard links and then removing this underline on hover/focus is a more importantly indicator of links and link status

@EWashb
Copy link
Contributor Author

EWashb commented Aug 2, 2022

Thank you for the insight @laflannery! I'm inclined to say if we are changing it anyway, we should probably aim for AAA. I'm of the mind to follow your suggestion about hover states as they relate to underline (from your third bullet)

@cjterdi
Copy link

cjterdi commented Aug 2, 2022

I think the 7.1 ratio for the link color should be the priority. The current hover state color is only 1.24 contrast compared to a white background. But because it is combined another visual changes, in this case an underline for links, we should still be in compliance, correct? I have an additional concern over increasing the contrast for hover states is at this point because are so many nested hover states that seem to create more distraction. I think this is an accessibility review, but may be slightly off subject.

@laflannery
Copy link
Contributor

I agree, I think if we use the darker blue color with underline and no underline on hover/focus that should work for all standard instances (at least that I have come across so far). There would be exceptions of course - the footer links as mentioned in this issue would remain white. I am also leaning towards removing the background hover color entirely - as you said it is very light, does it add any value the way it is now? And by removing that color, it would resolve the issue on the footer links hover.

@EWashb
Copy link
Contributor Author

EWashb commented Aug 2, 2022

@laflannery I think you're on the right track here. I would agree with your last comment. If we do roll this out and we find a case where it introduced a worse experience, we can roll back or rethink those specific use cases. That's ok.

@laflannery
Copy link
Contributor

laflannery commented Aug 2, 2022

Notes from meeting with Cindy:

  • 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)
  • 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

Let us know if you have questions!

@EWashb
Copy link
Contributor Author

EWashb commented Aug 2, 2022

This sounds great! I think these decisions will affect other tickets as well. If these decisions will be the solutions for the other assigned tickets, just please note them there.

I think the next steps are to have @cjterdi create the prototypes for these and then we will sync with a dev to go over tech feasibility/implementation, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y-defect-1 Critical accessibility issue that should be fixed in the next sprint CMS Team CMS Product team that manages both editor exp and devops
Projects
None yet
Development

No branches or pull requests

3 participants