RE: Focus appearance and definition of user-interface controls

An element in html isn’t necessarily interactive/operable, so I can see why when ISO 9241-161 use the term “user-interface element” it includes  “Note 1 to entry: User-interface elements can be interactive or not.”

However, WCAG applies User interface component to any component that is interactive. The only exception to that would be if the UIC is disabled or in a few cases read-only state.  A non-interactive element would not be considered a UIC.

Mike

From: "Niemann, Gundula" <gundula.niemann@sap.com>
Date: Tuesday, February 15, 2022 at 4:36 AM
To: Alastair Campbell <acampbell@nomensa.com>, WCAG list <w3c-wai-gl@w3.org>
Cc: "Keim, Oliver" <oliver.keim@sap.com>
Subject: [EXTERNAL] RE: Focus appearance and definition of user-interface controls
Resent-From: <w3c-wai-gl@w3.org>
Resent-Date: Tuesday, February 15, 2022 at 4:34 AM

Hello Alastair, hi Everyone,

Oliver (in cc) did some digging into various regulations and guidelines on the term used for ‘the thing the user thinks has keyboard focus’.

The ISO- 9241-161 defines:
user-interface element
user-interface object
entity of the user interface that is presented to the user by the software
EXAMPLE Text, graphic, control.
Note 1 to entry: User-interface elements can be interactive or not.
Note 2 to entry: Both entities relevant to the task and entities of the user interface are regarded as user-interface elements. […]
It can be possible for the user to directly manipulate some of these user-interface elements.
Note 3 to entry: User-interface elements in a graphical user interface include such things as basic objects (such as window title bars, menu items, push buttons, image maps, and editable text fields) or containers (such as windows, grouping boxes, menu bars, menus, groups of mutually-exclusive option buttons, and compound images that are made up of several smaller images). […]

It further defines:
focus cursor
location cursor
indicator showing which user-interface element has keyboard focus

The following guidelines and regulations use the term ‘user interface element’ or shortly ‘element’ with the above mentioned meaning:

  *   Section 508
  *   WAI-ARIA 1.0
  *   IBM CUA 1991
  *   Windows Styleguide
  *   Vista Guidelines “User experience Interaction Guidelines”
  *   Apple Human Interface Guidelines
  *   GNOME Human Interface Guidelines
The list might not be complete.
Interestingly, we did not come over a regulation that used a different term.

(Please find more details in the attached document. It opens with LibreOffice or Word, to name a few options.)

So a user interface element can also be a sub-element of another user interface element, which means that menu items, list items like drop-down options are covered as well as grid cells or elements inside a card.
The term is already defined and widely used, so using it in WCAG is consistent with other regulations.

As the Success Criterion talks about “When the user interface element receives keyboard focus”, there is no issue with some elements not receiving focus. The SC talks about how the focus indicator should look like once it is present.
SC 2.1.1 talks about which elements should receive focus (by saying “All functionality of the content is operable through a keyboard interface“, so no term discussion there).

The term ‘component’ often is understood as being a compound object.
So we (Oliver and me) suggest to use ‘user interface element’.

Best regards,
Gundula
----------
Dr. Gundula Niemann
SAP Inclusive Design
SAP SE


From: Alastair Campbell <acampbell@nomensa.com>
Sent: Donnerstag, 10. Februar 2022 19:08
To: WCAG list <w3c-wai-gl@w3.org>
Subject: Focus appearance and definition of user-interface controls

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.
https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results#xq36<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2002%2F09%2Fwbs%2F35422%2Fwcag22-focus-appearance-enhanced2%2Fresults%23xq36&data=04%7C01%7Cgundula.niemann%40sap.com%7C2739eb8fdbb446a8440808d9ecc06963%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637801134307775890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gPJvaKtxrgUYAp4fZjhBhDVIgj3q5uHWAd17oyRjPts%3D&reserved=0>

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fwai-aria-practices-1.2%2Fexamples%2Fgrid%2FdataGrids.html&data=04%7C01%7Cgundula.niemann%40sap.com%7C2739eb8fdbb446a8440808d9ecc06963%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637801134307775890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=V6%2Bc9hN7WnZUokm7VLYcOEIit2cUqpVapVKW94k9TOc%3D&reserved=0> or drop-down options<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fwai-aria-practices-1.2%2Fexamples%2Fcombobox%2Fcombobox-select-only.html&data=04%7C01%7Cgundula.niemann%40sap.com%7C2739eb8fdbb446a8440808d9ecc06963%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637801134307775890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kghCwuyMos%2FdsLOgmWBjNtI7luFx1hbDkt37432%2Bb5k%3D&reserved=0> would not be in scope.
     *   Ambiguous components like “Cards<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodepen.io%2Falastc%2Ffull%2FeYGoKyP&data=04%7C01%7Cgundula.niemann%40sap.com%7C2739eb8fdbb446a8440808d9ecc06963%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637801134307932109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qwOmoAABMquRe%2FyDepxF%2BQL95XSQ9%2BDOlD6GQo%2Fde1Y%3D&reserved=0>” 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.

-Alastair