Foundation-sites: Losing Visual Focus

[michaelwayneharris87]

I'm losing visual focus in a couple of ways:

On the slider and dropdown menu, I'm losing visual focus after tabbing to a slider handle and then moving my mouse. The visual focus indicator returns when keyboarding left or right. I expect the visual focus to remain at all times, such as in http://oaa-accessibility.org/example/32/. I've confirmed this both on Chrome 51.0, Firefox 45.2, and Safari 9.1.1.

In Safari, these items occasionally get visual focus only for a moment, and then visual focus disappears entirely, even without mouse movement.

[Owlbertz]

I think that this occurs is related to the what-input plugin that is used. This applies different styles to elements depending on the input type, such as mouse, keyboard or touch.
What is causing this for the slider is

[data-whatinput='mouse'] .slider-handle {
    outline: 0;
}

I guess this is done because (unfortunately) many developers do not care too much about a11y and therefore find the outline disturbing because it "adds an ugly blue border" or what ever. Using what-input seems like a good compromise between a11y for keyboard users and design aspects for mouse users.

If you want to change the behavior for your site you could create the necessary CSS rules for your own or customize the SASS (not sure how exactly to do that...).

[michaelwayneharris87]

I appreciate your identifying what rule to look for. I was able to use your idea of creating a new CSS style. Thank you!

I hope this gets resolved in the default distribution — it's better to opt out of accessibility than opt into it. But until that happens, this workaround helps us.

[sethkane]

I took a quick look at this and here is my $0.02 but before I go into that I tested this on:

Mac: Chrome, Safari and Firefox
PC: IE 11

I was able to see the default browser focus ring and it never goes away until I move the mouse. Not ideal but not really a huge issues because the item never actually loose focus.

So with that being said here is my take on this. I don't think this is full out defect, I do however think this is a sub par experience for someone that uses the keyboard and the mouse on a regular basis or needed basis.

From a pure accessibility point of view the focus ring is an absolute requirement (sorry Devs and Designers). I work with designers and user experience people everyday and most of them HATE the default focus ring (especially the blue Chrome one). So regardless of their likes and dislikes the minute you remove the focus ring the site becomes in-accessible to people requiring keyboard ONLY access.

Now you have options in solving this and making everyone happy and what I would recommend is building a custom focus ring into the CORE of foundation. I would recommend removing the "data-whatinput" or what ever it is that removes the outline when the mouse is moving (I did not research the cause) and replace it with a custom focus ring controlled by the SCSS settings.

I like using the-selector:focus{outline: 0; border: 1px dotted #000}. It really can be anything as long as it is clear that the object is in fact in focus.

So in conclusion:

• I agree, this is a problem.
• I highly agree with @michaelwayneharris87 that the focus ring should not be disabled by default rather it should be an option to hide the focus ring if the developer decides to ignore what is in the best interest of everyone.
• I also think maybe there should be a custom configurable focus ring so from browser to browser they all look the same (nice to have)

I hope this help and let me know if you want help digging into finding the source of the issue.

[Owlbertz]

Thank @sethkane for that detailed write up.
I purpose the following changes:

• Make focus ring (never actually used that term...) changeable via SASS.
• Ideally the focus ring would come in two ways, one for light and one for dark elements. E.g. when using Ubuntu, the ring is dark gray, making it hard to see on a dark navigation.
• Find a way to disable/enable the focus ring by developer' choice. Maybe this can be done using a JS statement or applying a class to the html element? Something that either always displays the ring, always hides it or makes use of the current behavior (with what-input).

Any feedback on this?

[michaelwayneharris87]

That solution seems great. It would definitely work for me.

[Owlbertz]

I thought of something like the following:

////
/// @group accessibility
////

.disable-focus-ring *:focus {
  outline: 0;
}

*:focus {
  outline: $focus-ring;
}

/// Removes the focus ring around an element when a mouse input is detected.
@mixin disable-mouse-outline {
  [data-whatinput='mouse']:not(.enable-focus-ring) & {
    outline: 0;
  }
}

Maybe someone from @zurb/yetinauts can give some feedback to this whole thing?

[markadrake]

If you don't mind me weighing in on this conversation.

Heck yes:

• By all means please remove any css properties from the framework that reduce accessibility. Awesome catch @Owlbertz and @michaelwayneharris87.
• You should probably search the entire framework for more rules removing the outline.

But slow down maybe:

• I avoid the * selector like the plague. It may sound trivial but applying styles so broadly always contributes to cascading nightmares.
• I don't grasp the need for the Foundation framework to define or accommodate extra styles, mixins, etc for the focus state.

Whether you are trying to remove outlines or you want to apply further styling to outlines it's a pretty trivial task:

a,
button {

     // remove an outline
     outline: 0;

     // OR style an outline
     outline: 2px solid;
     outline-color: #0000FF;

}

I hope I don't offend, that's not my intention to do so. I just think we should restore accessibility in the framework by removing the culprits and that's there's very little perceived value on having a globally defined focus state for all elements.

What I think about the focus state anyways

From an accessibility standpoint the outline is barely enough anyways. We do more as designers and developers to style mouse hovers than we do focused elements and that trend itself should change. If something has focus - highlight it. Or go all out - apply a subtle animation to the focused element for some real effect.

[Owlbertz]

@markadrake I totally agree that we should not do anything to reduce accessibility.

But as I mentioned above many people just don't care about accessibility and thus want to get rid of everything that gets added automatically by the browser (i.e. outline of focused elements). I think that making outlines customizable so that they fit the overall style of the page is a first step on making people not completely remove the outlines - hence my suggestion in https://github.com/zurb/foundation-sites/issues/9017#issuecomment-234590418.

[andycochran]

I proposed a solution in #8977.

(Much thanks all you a11y allies! Accessibility is one of the most important pieces of Foundation.)

[brettsmason]

@Owlbertz Seeing as you were heavily involved in this discussion, do you think its something that should be addressed in V6 or considered for V7?

[Owlbertz]

I guess what I wrote in https://github.com/zurb/foundation-sites/issues/9017#issuecomment-247533819 still applies and that we should consider having a customizing option for the outline to make it fit the overall page style.

[JeremyEnglert]

There's a lot we can do to improve here. Andy nailed it in his comment. However, this would be a pretty big change in the platform.

"The purpose of this success criterion is to help a person know which element has the keyboard focus."

Isn't that what we're doing? It may not be ideal to hide focus for mouse users, but we're not breaking any WCAG rules by doing so. Users can switch between a keyboard and a mouse and What-Input properly detects that.