RE: Focus-appearance terminology

> We can get to the same place without creating different terms, which is why I am suggesting "keyboard operable user interface control".

That is quite easy to read as user-interface component (I just did, I had to scan back to work out the difference).

It also seems to be two phrases for the same thing, why not just "keyboard operable control"?


> The issue that I'm trying to avoid is creating additional terms to refer to user interface controls. If we need to constrain the SC to not include all UIC then we should use language that we already have in place to do so.

It is the definition of user-interface component that we are trying to avoid because it is based on the perception of the control. That leads to varying sizes being possible depending on what you perceive is part of the control (e.g. drop-shadow, or cards which have several possibilities).

Also consider something which is one "user-interface control" but the element with focus is different, such as a select-only combobox<https://www.w3.org/TR/wai-aria-practices-1.2/examples/combobox/combobox-select-only.html> where you focus on the component, then focus on the selectable items within the component. [1]

On the other hand 2.1.2 uses "component" (without the user-interface part), and 4.1.1 uses "elements". A couple use "controls" without the user-interface part (1.1.1, 4.1.2).

Any of element | component | control are fine with me, something that implies the programmatic size rather than perceived size.


> what are the scenarios where the focus isn't visible that we are allowing in the AA version?

If other content drops-down over it, or if you start with a strong indicator that fades out (like the optional ones in Edge/Chrome).

Cheers,

-Alastair

1] https://www.w3.org/TR/wai-aria-practices-1.2/examples/combobox/combobox-select-only.html