-
Notifications
You must be signed in to change notification settings - Fork 69
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
Comments
Class for hover may not be specified in the CSS |
Hey team! Please add your planning poker estimate with ZenHub @cjterdi @laflannery |
@laflannery is going to double-check the FE standard for links to help inform our path forward |
@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:
|
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) |
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. |
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. |
@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. |
Notes from meeting with Cindy:
Let us know if you have questions! |
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. |
Background
On staging, the footer links have a background color of light blue which introduces an accessibility issue.
Image of defective area:
Accessibility Standard
WCAG version 2.0 AA, Criterion 1.4.3
Acceptance Criteria
The text was updated successfully, but these errors were encountered: