Re: { quick question } visual focus

Thanks Patrick and everyone for your quick response.

I was given a small window of time to research this one so I appreciate all
the food for thought.

So often the focus is attached to the word 'keyboard' and then the 'what
if...' crept in.



On Thu, Apr 8, 2021, 7:45 PM Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 08/04/2021 23:05, caroline wrote:
> > Hi All,
> > I was asked if 'we should be managing visual focus everywhere so that it
> > only appears for a keyboard user.'
> >
> > Looking at other sites focus is not appearing unless I use my keyboard.
> > But i started to wonder if there's other technology that I should
> > consider apart from a keyboard.
>
> Opinions will vary on this. For some, focus indication should always be
> visible regardless of the input device of the user.
>
> For others, it's acceptable to say that only once a user navigates with
> the keyboard a focus indicator becomes visible.
>
> Of course, for form elements, an indication of which form control
> currently has focus should be shown regardless (as even if a user
> focused an element with mouse or touch, they need to know that is it
> indeed ready to take their input).
>
> As for inputs other than keyboards, these generally either simulate an
> actual keyboard input (so they will move focus, and therefore any
> solution that tries to work out if the user is navigating/operating the
> page via keyboard should pick these up too - though there can be some
> false negatives in certain cases*), or they will behave more like a
> mouse/touch/pointer and provide their own way of indicating what the
> current "point of interest" is that the user can interact with.
>
> In general, I'd say the CSS :focus-visible pseudoclass would be a good
> choice, though it's still not implemented in all browsers (see
> https://www.tpgi.com/focus-visible-and-backwards-compatibility/).
>
> Solutions like whatinput.js can be the ones leading to false negatives
> in certain scenarios (for instance, when navigating using a keyboard and
> a screen reader, the fact that screen readers generally send "faked"
> mouse events can confuse whatinput and make it think the user is
> navigating with a mouse) ... so I'd be cautious using this approach.
>
> (Also throwing in this for good measure
>
> https://css-tricks.com/interaction-media-features-and-their-potential-for-incorrect-assumptions/
> )
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>