-
Notifications
You must be signed in to change notification settings - Fork 1
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
Improved focus states for components #69
Conversation
Can you explain this PR a little bit? I kinda get it, but I want to hear it from you.. |
The default Webkit outline for focus states is pretty ugly. If a hover state looks distinct enough from a component's default state, I've changed the focus state to match. |
So I'm not really sure this is the best idea. Is there any instance in which the user will see
|
That's what designing for accessibility means!
Hover and focus states can be identical. You're navigating with a keyboard because you cannot or don't want to use the mouse, so you'll never see a hover state.
We already have custom hover and active states for most components... not sure why this is different. |
Right, but isn't this less accessible, since we're making the
What I mean is that these new focus states have the potential to be too subtle compared to the normal state of the element. And this all brings us back to my first bullet as well. Can you provide some kind of reference point for this being a good practice? Neither ZURB Foundation nor Bootstrap appear to style their |
Here's the A11Y Project... I'm proposing solution 2. Generally, I don't think it's a matter of good / bad practice so much as attention to detail, empathy and consistent branding. It's about paying attention to that audience... not many do. We're fine with styling focus states on our inputs, so that fully-abled users don't have to see the focus ring. Why should other elements be any different? Defining focus states ourselves also lets us avoid weird visual bugs with the browser's default focus ring. |
Thanks for the thoughtful reply, this helps clarify a bit. I still stand by my concern that we might be making our site less accessible by making the focus states more subtle. I want a focus state to look like what a user expects a focus state to look like. How about this for a rule:
I think this helps us achieve "attention to detail, empathy and consistent branding", while allaying my concern above. |
So, basing an argument on anecdotal experience is obnoxious, but I'm going to do it anyway. 😞 Everything I've read about accessibility advises that you need to clearly indicate focus states. It doesn't prescribe how they should be styled. This is why browser default focus states differ from each other... Internet Explorer, for instance, is much lower-contrast and harder to discern. Sometimes when you custom style, you're actually doing users a favor . Anecdotally, I've heard many users complain that they can't tell what's currently in focus. That's always because the focus styles have been removed, or they're way too subtle. I've never heard anyone complain that a focus state isn't styled in the way they expect. They're the ones tabbing through the page, so they know they're looking for some kind of change in state. Here's my test to ensure that a focus state isn't too subtle:
That's it. I conducted that test before opening this PR. |
Alright, I'm OK merging this. I'm still not convinced that this is super-necessary, but it sounds like you've thought about it so I'm alright to just let it go. Sorry for making you go through all of that just to get these changes merged! |
Improved focus states for components
No description provided.