Explain :focus-visible intent, add examples and UA guidance

[alice]

@tabatkins Following up on #2481, trying to more clearly explain the intent of this pseudo-class and provide better author and UA guidance.

Thanks to @patrickhlauke and @AmeliaBR for inspiration for the second example (not sure how to credit you in the spec).

cc @robdodson @bkardell

[AmeliaBR]

I'm concerned about the phrase "element which does not support user input".

Technically, every focusable element supports user input. That input may only be activation, though. Maybe make it "text input" explicitly?

[robdodson]

"not not" match?

[alice]

@AmeliaBR Yeah, I hesitated over that text, but I wasn't sure about "text input" because it's also numeric, date/time etc so I hedged.

How about this?

Any element which supports keyboard input (such as an <input> element, or any other element
which may trigger a virtual keyboard to be shown on focus if a physical keyboard is not present)

[alice]

(Added a bullet point regarding user preferences at the top of the heuristics list.)

[bkardell]

Yeah, we discussed this many times... it is wonky to define in terms we have - even 'virtual keyboard' is potentially a little confusing if you think of it as the qwerty thing, really it's pretty much any means of inputting text of some kind into some kind of control. I think the text here is pretty good

[dbaron]

@tabatkins @fantasai curious about the state of this PR. (See link to TAG issue above; we keep pushing it forward on the TAG agenda.)

[robdodson]

friendly ping, @tabatkins or @fantasai do y'all have any thoughts?

[slightlyoff]

Per w3ctag/design-reviews#233, consider this a friendly ping @tabatkins

[tabatkins]

Just did some very minor cleanup of markup, and tweaked some 2119 term usage. Otherwise this looks great, thanks so much @alice!

[FremyCompany]

Travis Leithead from Microsoft realized there were a couple of typos in the code example;
I fixed them in afbffa4.