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

Hover state for disabled RadioCardGroup items doesn't meet color contrast minimum #777

Open
anastasialanz opened this issue Sep 16, 2022 · 6 comments
Assignees
Labels
accessibility low low priority wontfix This will not be worked on

Comments

@anastasialanz
Copy link
Contributor

anastasialanz commented Sep 16, 2022

When viewing Cauldron with the dark theme, in the RadioCardGroup demo, the hover state color contrast for the middle, disabled card doesn't meet the color contrast minimum.

"No" text: #ffffff
Background color: #e0e0e0

Screenshot from Chrome Dev Tools:
Screen Shot 2022-09-16 at 1 41 28 PM

https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html

Related issue

@anastasialanz anastasialanz changed the title Hover for RadioCardGroup Hover state for RadioCardGroup doesn't meet color contrast minimum Sep 16, 2022
@schne324
Copy link
Member

@awpearlm what is the expected color here?

@schne324 schne324 changed the title Hover state for RadioCardGroup doesn't meet color contrast minimum Hover state for disabled RadioCardGroup items doesn't meet color contrast minimum Sep 16, 2022
@schne324
Copy link
Member

Important to note that this is just the :hover state for disabled radio card group items (I've updated the title accordingly)

@anastasialanz
Copy link
Contributor Author

anastasialanz commented Sep 16, 2022

Why does only the disabled one have a hover state? Oh I see, the dark theme doesn't have a hover state for non-disabled items.

Screen Shot 2022-09-16 at 4 32 27 PM

Screen.Recording.2022-09-16.at.4.35.10.PM.mov

@anastasialanz
Copy link
Contributor Author

@scurker Can we close this since RadioCardGroup is deprecated now?

@scurker
Copy link
Member

scurker commented Feb 14, 2025

It is a valid accessibility issue that is still present so I don't think we want to lose site of it until the pattern has been removed and we have a replacement pattern. It's still on our todo list to do both.

@anastasialanz
Copy link
Contributor Author

anastasialanz commented Feb 14, 2025

@scurker I linked the new replacement component in the description in case this doesn't get fixed before the replacement happens.

@scurker scurker added wontfix This will not be worked on and removed info needed labels Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility low low priority wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

4 participants