Weird behavior when the mouse is moved outside the window and then in again

[FezVrasta]

1. Open the demo at http://s.codepen.io/FezVrasta/debug/VepyPV
2. press TAB and the text will become red (correct!)
3. move the mouse outside of the window, the text is still red (correct!)
4. move the mouse inside the window, the text is not red anymore (not correct!)

I would expect the text to stay red till I actually use the mouse to click somewhere.

[ten1seven]

This is an issue that I've juuuuuust been debating about changing. Right now mouse detection happens on click and on mouseenter. I hesitate using mousemove to keep the performance impact minimal. So what you're seeing is "correct", but a bit inconsistent.

Do you think mousemove should be used? So any mouse movement (heavily debounced) would remove the red from your text? Or only clicking with the mouse would remove the red? I suspect most people are wanting more sensitive detection and would prefer mousemove.

Thanks for using it!

[FezVrasta]

I don't think mouse move should be used at all, this script is used to change the style of the :focus state of the elements when an user switch the input method.

If you press tab and then move the mouse, you don't want the button to lose its "focus state", you want it to lose its "focus state" only if you CLICK on an element (doing so, you would see the focus state assigned to the keyboard input, so you change it to mouse because IS needed).

I hope you get my point.

[ten1seven]

I built it to do more than styling focus states (though that's how it originated). The API allows you to hook into it for scripting for multiple input types. For example, I've used it when building hover-triggered menus to script alternate interactions for touch and keyboard.

Some people have reported "bugs" when a keyboard focus state persists when switching to a mouse.

It sounds like, in your instance, would it be preferable to use the same focus style even if a mouse is detected?

[FezVrasta]

No, sorry.

I mean, right now this is the behavior:

• click on a button, apply mouse style (you have clicked the mouse!)
• press tab, apply keyboard style (you have pressed a button!)
• move the mouse, apply mouse style (you have moved the mouse)
• move the fingers over the keyboard without touching any key, apply keyboard style (you have hovered your keyboard? umh)

As you can see, you are script should know if you are hovering your fingers on the keyboard to behave consistently.

This is not possible, so you should be consistent in the other way:

• click on a button, apply mouse style (you have clicked the mouse!)
• press tab, apply keyboard style (you have pressed a button!)
• move the mouse, do nothing (you have moved the mouse but you will not say "ahg! why this button has a blue outline? because you know it got the outline when you pressed tab)

Hope it's more clear now.

[luisfarzati]

I think this is too subjective. @ten1seven you might want to leave this decision to the developer. Wouldn't make sense to expose an API to set the events to be listened?

Default would be the way it is now; and @FezVrasta would be able to call something like .detectionEvents(['click']) and others could do .detectionEvents(['click','mousemove','mouseenter']), etc.

Or at least, maybe provide some kind of configurable threshold for each input: hover > action > none. hover being basically the most "sensible" detection (includes actions as well), action being what @FezVrasta expects, and none is I don't want to detect this input type at all.

[FezVrasta]

It could be a solution. but I think that the solution I propose is just what the user expects.

[ten1seven]

@FezVrasta @luisfarzati thanks for your comments and suggested solutions on this. I'm still puzzling through the best direction. At this point I'm hesitant to change the behavior that people (developers) now expect.

mousemove detection was only recently added as a way to detect mouse usage as soon as possible to minimize the time of ambiguity after the page loads.

When typing in form elements, the input method of keyboard isn't triggered if someone was using a mouse. However, currently the tab key will still trigger a switch from mouse to keyboard. @FezVrasta is this the main use case you're thinking of -- tabbing within a form?

I'm wondering if adding tab to the list of ignored keys when interacting with a form for a previously-detected mouse user would make the most sense? I want to keep quick detection of input switching in place because What Input is also useful for scripting multi-input interface elements.

[FezVrasta]

No the main problem is just that if I've an input focused (because I used the keyboard) and I accidentally move the mouse out and then inside the window, I don't want to lose the focus effect I've applied.

[ten1seven]

Not sure how I feel about doing this all the time, but your concern is valid and seems to be focused around form inputs -- when a mouse user is using the keyboard. Check out the form-input-switching branch with a solution that locks in the input type when interacting with form elements. This goes both ways for mouse and keyboard users. I haven't updated the demo so you'll need to pull it down and run it locally or drop it in your project.

Let me know what you think.

[joe-watkins]

@ten1seven Why do you think a "mouse user" or "touch user" wouldn't want a focus ring or outline? There are many users who could use all 3 of these combinations (keyboard, touch, mouse) at the same time and could appreciate knowing which element is currently focused in the UI.

For users with cognitive disabilities, low vision, and/or mobility disabilities could find it very confusing to have focus state removed from them while bouncing from one input method to another.

If used to remove outline when the mouse is used it could fail WCAG 2.0 AA 2.4.7 Focus Visible

[ten1seven]

@joe-watkins thanks for commenting! You have a valid point and one that I thought through a bunch when considering this request. Forms are so tricky in that they're the one place where mouse users become keyboard users. Here's my thinking on it -- though I"m happy to debate in the name of making the web better 😄

• In the instance of interacting with a form, I'm hoping that good focus indication is being used for everyone.
• Sometimes elements that accept and hold focus, like buttons, are used in the interface where allowing mouse users to see a focus state might look like a bug.
• Default focus styles are inconsistent. In fact, Firefox's are pretty terrible and difficult to see. What Input helps developers make those styles more consistent and visible while satisfying designers and clients who (almost always in my part of the industry) don't want to see them ("hey, what's that blue fuzzy outline all about?" -- actual question from a designer once).
• I added the ability to turn off this behavior if you need via <body data-whatinput-formswitching>.
• What Input was built to help get accessibility (better focus indicators) into sites where it normally would get left out.

What do you think? Have you used this script and don't like the feature change? Or do you object to the idea of trying override the browser's focus behavior at all?

[joe-watkins]

@ten1seven It's very obvious accessibility is on your mind here and I don't wish to harsh on the hard work you've put in here but I do feel it's worth chatting about since your project is very visible to the dev community.. Foundation even uses it.

I'm very much in the camp of don't mess with outlines unless you are enhancing/styling them.

Designers Modern/Professional web designers have embraced accessibility & the focus states. They've learned to accept them as a design challenge. If your designer isn't including that state with hover states in their creative deliverable they might need to be educated the importance of them.

Clients The same goes with the client... this is a perfect opportunity to educate the client. If the browser's native focus ring feels like a bug the designer/client should be educated that it is a browser feature for people. These focus rings can be styled to match brand guidelines.

You can point the client here to get them onboard w/Accessibility if they lack empathy. List of Web Accessibility-Related Litigation and Settlements

Focus States While some browsers handle focus state a bit differently they all allow you to style them so there is consistency across the board.

a:hover, a:focus {
  outline: none;
  border: 1px solid red;
}

Inputs Take a peek at some of these alternative input mechanisms: http://www.orin.com/access/sip_puff/ http://www.bltt.org/hardware/joysticks.htm http://www.bltt.org/hardware/keyboards.htm http://www.bltt.org/hardware/switches.htm

A user could be leveraging inputs like those in the links above along with a keyboard, mouse, eye tracking software,touchpad and more on a touch device. How can we assume what input they will use or depending on what input they've chosen they DON'T want/need a focus state??

This very basic accessibility feature is baked into the web for free.. why are we trying to remove it under certain circumstances based heavily on assumptions?

I do see how understanding more about the user's inputs could help here and there but outline:none; is at epidemic levels and is the #1 reason why I fail websites when performing accessibility audits.

I want to understand why a user's dependency on a focus state would change based on what input device they are using? If an element can receive focus and the author has defined a focus state it is my belief that should be universal and available to all users and again is a WCAG 2.0 AA guideline recommendation.

This is worthy of it's own issue and appreciate your open mind :) Would you consider adding a note to the README about possible accessibility concerns near the Styling Example?

[ten1seven]

Oh man, if everyone was that educated and understanding this script wouldn't be necessary and I'd be fine with that 😄

Thanks for the thorough response! It sounds like the usage you're suggesting is:

• Links don't hold focus like form controls when you click on them (like a button will) so leave the focus state on these alone or only enhance the styling but otherwise don't use What Input to style them because the browser does just fine.
• Form inputs should always have some kind of focus indicator, but What Input could be used to enhance it if desired.
• Since buttons used as UI elements outside the context of a form will still take and hold focus when clicked (ex. a button used as a hamburger menu toggle), this can be viewed as a visual bug by mouse users. This is the exact case where What Input was created and, I think, is an acceptable compromise to maintain a focus style for keyboard users while using the best semantic element for the job and not introducing a "buggy" experience for mouse users.

Every time I hear about What Input being used, it's to solve this last point. You've definitely got me re-thinking the feature the thread was based on and maybe some clearer documentation on usage would help as well. Does that cover your concerns?

[joe-watkins]

@ten1seven :) Tnx for responding.. The last one is the bugger. Here is a great example of focus state being part of the design..it doesn't have to feel like a bug. If your plugin was running here I'd lose that handy state when navigating through the side nav and moving mouse..that'd be a bummer.

Video Screencast of University of Washington's offscreen nav

Test Site

My concern would be addressed by adding to the documentation somewhere (ideally next to the code chunk where you suggest removing outlines) that if you remove outlines and don't provide a backup you harm accessibility and which could make you fail WCAG 2.0 AA 2.4.7.

I'd be happy to create a PR for this.

[ten1seven]

Ah, I see a little more how you're viewing it. In my work I use it to add really visible focus indicators to existing focus/hover styes. Here's an example: http://d.pr/v/19FZ6

However a well-intentioned tool used incorrectly will still result in poor outcome.

I'd love to get your edits on the documentation on how to more accurately use it!

[joe-watkins]

@ten1seven That demo is slick! I surely see how when used properly it could add to the experience. Those are some spiffy underlines on those links as well!

I'll fire up a PR for your review on this topic.