W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2022

Focus appearance and definition of user-interface controls

From: Alastair Campbell <acampbell@nomensa.com>
Date: Thu, 10 Feb 2022 18:08:00 +0000
To: WCAG list <w3c-wai-gl@w3.org>
Message-ID: <F49C2F71-9E46-456B-90B4-E47BA0472914@nomensa.com>
Hi Everyone,

I was adding another question and noticed the current responses Q3 had a few comments along the lines of: We should use “user-interface controls” rather than any of the suggestions.

This question came about due to our look at target-size as the metric for working out the size of a control.

Whilst noting there is no perfect answer to this, the problem with basing it on user-interface controls / components were:

  *   Being “perceived by users as a single control for a distinct function” does not lead you to one size. For example:
     *   A menu is a control for the function of navigation, but actually you want the items to have focus.
     *   Similarly, active descendants like grid cells<https://www.w3.org/TR/wai-aria-practices-1.2/examples/grid/dataGrids.html> or drop-down options<https://www.w3.org/TR/wai-aria-practices-1.2/examples/combobox/combobox-select-only.html> would not be in scope.
     *   Ambiguous components like “Cards<https://codepen.io/alastc/full/eYGoKyP>” could easily lead to different results.
  *   What is ‘perceived’ as part of the control would mean things like drop-shadow or other effects that go outside of the HTML element would add to the perceived size. Things you assume would pass (e.g. a contrasting 1px outline) then fail.

If we want to scope as closely as possible to “the thing the user thinks has keyboard focus”, we can’t use UIC.

Received on Thursday, 10 February 2022 18:08:19 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:43 UTC