Change readme to encourage more responsible removal of focus states

[joe-watkins]

@ten1seven As mentioned in #17 Here is a PR that addresses accessibility concerns raised.

Per your demo you do an awesome job of not removing focus state by providing different focus states. There isn't ever an opportunity to have no focus state. While I personally struggle with why a keyboard user needs an alternate visual focus state -- the pattern you offer here is a more responsible way of handling :focus state.

The original readme suggested global removal of outlines in your Example Styling section (sad clown):

[data-whatinput="mouse"] :focus,
[data-whatinput="touch"] :focus {
  outline: none;
}

I understand your code snippet was purely an example, but in a world where more novice developers copy/paste code snippets for production code I feel it is important that these snippets set them up for success! :)

I've taken CSS straight from your demo and altered it just a bit and added it to the readme as it provides a quick visual/code example of what your plugin does without potentially harming accessibility. CodePen demo

/* mouse */
[data-whatinput='mouse'] :focus {
  border-color: red;
}

/* keyboard */
[data-whatinput='keyboard'] :focus {
  border-color: green;
}

/* touch */
[data-whatinput='touch'] :focus {
  border-color: blue;
}

Focus states are such awesome free built-in accessibility features that are worth more than most developers give them credit for. The idea here with this PR is to still prove the functionality of the plugin while maintaining accessibility best practices.

If the author chooses to make a poor decision by removing outlines that is on them. :)

[ten1seven]

This is great, thanks!