Accordion Example: Correct color contrast (Issue #1132) #1200
Conversation
There was a problem hiding this comment.
This looks good! There are just two places I found contrast (or high contrast mode) issues:
- the
.Accordion.focusborder color (line 15 of accordion.css) is only 2.28:1 - no focus outlines are visible in Windows High Contrast Mode (there's an
outline:none.Accordion-triggerstyle in there, and it could be fixed by switching it to.Accordion-trigger:focus { outline: 4px solid transparent; }).
I also don't see a focus outline on the form fields in Firefox on Windows, so I'm guessing something in the styles is obscuring the native faint dashed outline. Might be beyond the scope of this PR though, depending on how much you feel like changing :)
|
Thanks for the comment and feedback! I’ll change the two (high) contrast things you mentioned. I kinda want to redo the example at some point. So I’ll leave the Firefox specific thing for another time/person. |
There was a problem hiding this comment.
This looks great!
Since this is the first time I'm really digging into this issue, I am a bit uncertain about why the button border contrast was a violation (and by extension, the overall accordion's border). My understanding of 1.4.11 is that borders do not need to be 3:1 if some other indicator meets the appropriate requirement, which is what 1.4.11 Understanding says about buttons. I would assume that applies here as well since the primary controls are buttons. In other words, the text contrast should be sufficient to cover 1.4.11: Non-text Contrast because the button text's contrast ratio is 16.1:1.
On that same note, don't the input borders actually fail 1.4.11? They should be 3:1, but they're currently 2.68:1.
Let me know if I'm terribly misunderstanding the requirement here!
|
@sh0ji I think you might be reading the text of the requirement correctly, though in this case it seems like a grey area because the divide between the button and the accordion content could be meaningful. Even if the button borders aren't a technical 1.4.11 failure, it still seems like better practice to meet at least 3:1. My beyond-AA rule of thumb is to check how usable something is if the borders were removed entirely. In this case it doesn't seem all that wonderful a user experience, so as long as color contrast is being updated, might as well update it for everything. +1 to the input borders getting better contrast too :) |
|
Great point, @smhigley. I don't have any qualms with going above and beyond AA of course (seems like there should be a AAA for this) and am not recommending we change this back. I just want to make sure I understand the requirement well so that we know when to address this type of thing in the future. I had a similar thought about the button borders in the context of the accordion, but the fact that the details/summary elements don't have a border in any browser made me question that. I do think it's good UX to include a visual indicator of the boundaries of clickable regions when it extends beyond the text box. There's a WCAG SC for target size, but not one for target perceivability, so that doesn't seem like an accessibility requirement. |
|
Fixed the |
Resolves a part of #1132