dobtco / dvl-core

Base styles for the DOBT View Layer.
https://design.dobt.co/
1 stars 1 forks source link

Improved focus states for components #69

Closed jrubenoff closed 9 years ago

ajb commented 9 years ago

Can you explain this PR a little bit? I kinda get it, but I want to hear it from you..

jrubenoff commented 9 years ago

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.

ajb commented 9 years ago

So I'm not really sure this is the best idea. Is there any instance in which the user will see focus states of these components, except when they're tabbing to them? Other concerns:

  1. I can't find another website that overrides the default focus styles on a per-component basis. (Although since I'm using GitHub.com as my reference, I will admit that the outline on the buttons below this text box looks custom...)
  2. I'm afraid that our custom-defined focus states will cause accessibility issues, because they aren't distinct enough from the non-focus states.
  3. Even if 1 & 2 are allayed, I'm worried that we'll be playing whack-a-mole with keeping track of our focus states for our components. We already have enough to do, this seems pretty extraneous if it's only something that keyboard-navigators are going to see.
jrubenoff commented 9 years ago

this seems pretty extraneous if it's only something that keyboard-navigators are going to see

That's what designing for accessibility means!

they aren't distinct enough from the non-focus states

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'll be playing whack-a-mole with keeping track of our focus states for our components

We already have custom hover and active states for most components... not sure why this is different.

ajb commented 9 years ago

That's what designing for accessibility means!

Right, but isn't this less accessible, since we're making the :focus states more subtle? See below...

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.

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 focus states.

jrubenoff commented 9 years ago

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?

screen shot 2015-04-07 at 6 19 19 pm

Defining focus states ourselves also lets us avoid weird visual bugs with the browser's default focus ring.

screen shot 2015-04-07 at 6 16 25 pm

ajb commented 9 years ago

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.

jrubenoff commented 9 years ago

So, basing an argument on anecdotal experience is obnoxious, but I'm going to do it anyway. :disappointed:

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.

ajb commented 9 years ago

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!