Re: Focus indicators for grouped controls

> Il giorno 11 ott 2019, alle ore 15:52, Alastair Campbell <acampbell@nomensa.com> ha scritto:
> 
> Hi Giacomo,
>  
> > - a native dropdown (<select>) keeps the focus indicator on the <select> element, even though the "current" option is highlighted with another visual indicator;
>  
> Is that a good basic example, or do selects inherit from the operating system? They seem to work differently in different browsers.

I didn’t find any reference about that. I tested it on different OS with multiple browsers (iOS mobile - Safari, iOS desktop - Safari Chrome Firefox, Windows - Microsoft Edge). I considered results testing via JS the document.activeElement. Also, considering that there is no way to focus an option of a native dropdown using JS, I assumed that the focus remains on the <select> element (with every combination of OS/browser that I was able to tested, the focus indicator stayed on the dropdown element). 
Would be interesting if someone may help us with that, confirming or refuting above.

> 
> > a grouped controls like the Google docs example you highlighted works very differently; it is visually more similar to a tab panel widget and the entire area is focused.
> 
> Perhaps, but in the ARIA practices tab example the focus follows the arrowing around:
> https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-2/tabs.html <https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-2/tabs.html>
>  
> As do the Office365 equivalent toolbar buttons.

I agree; I was thinking about the possibility of having multiple scenarios with multiple solutions.

> 
> > In my opinion, I wouldn't suggest to force developers following a specific guideline, but I would suggest to be consistent with the native focus indicator.
>  
> Part of the motivation for this new guideline is to ensure focus indicators work across more scenarios. Currently the browser default indicators can be (almost) invisible depending on the browser, background, and context of the focus elements. There is a draft of a guideline for WCAG 2.2 that requires a certain contrast change, size, and separation from adjacent colours for focus indicators.

I totally agree with that; there are combinations of background and default focus indicator colors really hard to be perceived. Considering that developers are able to know exactly which background, foreground, opacity, shadows CSS property will be used, they are also able to customize the focus indicator for that area in order to ensure its visibility.

>  
> The question is whether there is an exception needed if there is some sub-set of keyboard interactions that don’t behave as ‘keyboard focus’.
>  

I think didn’t get the goal of the first message.
Are you referring only to grouped controls or in general?
Moreover, does the “keyboard focus” include also highlighting visually the “active” states of an element or only the focused element? For example, using the Google docs example, with “keyboard focus” are you referring only to the light focus indicator that highlight the entire area (that will be probably the real focus indicator) or also the light background used to highlight the state of the “current” element?
For example, in a combobox widget (for example a predictive search), focus must be kept to the search input otherwise users are not able to proceed entering chars, but using the arrows (“fake focus”) the user is able to choose one of the suggestions.

> 
> > in the Google docs example, if the focus is kept on the entire navigation area and the user is able to choose an option simply moving with the arrow keys, without moving the focus on a specific element, the focus indicator should highlight the entire area; the "current" button will be visually styled differently (and of course implemented semantically correct using all the required aria attributes) to highlight the element state.
>  
> That is a good example of the problem, the focus indicator is so subtle as to be unusable for someone with low-vision. (NB: In this case focus also triggers a very obvious tooltip which would pass this new guideline, but the subtle white/grey background change on it’s own would not.)
>  

Agree

> 
> > Instead, if using the arrows we are also moving the native focus, the corresponding element should be highlighted using the visual focus indicator.
>  
> My question is: what is that native focus, if it is not the keyboard focus?

I was referring, for example, to the predictive example highlighted previously.

>  
> I realise that a screenreader can browse over content without triggering keyboard focus, but if you are just using a keyboard and arrowing around a toolbar, is there some other focus thing?

Is the screenreader indicator a “keyboard focus”? Literally yes, but I wouldn’t totally agree merging the screen reader focus indicator with the browser “native/default” focus indicator; it is the screen reader focus indicator, that as you said, is not strictly related to the focus, considering you are able to “highlight” an element that is not focused.