Re: Focus indicators for grouped controls

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.

> 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


As do the Office365 equivalent toolbar buttons.

> 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.

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’.


> 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.)


> 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 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?

Cheers,

-Alastair