"Control" is not defined in glossary

[coreymoore]

The first exception for 1.1.1 Non-text Content states:

If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)

The term "control" is both unclear and ambiguous.

Its meaning is unclear to everyone who is not familiar with user interface design. In the context of this SC, it can be understood to be similar to an element that "accepts user input" but that is not in-and-of-itself enough information to understand what this success criteria means by "control."

(Confusingly, "control" and "input/content that accepts user input" are treated as different types of elements in 1.1.1, even though an input is a type of control.)

Its meaning is ambiguous because what constitutes a "control" from a user interface design perspective differs depending on who you ask.

Does it include links, buttons, and form inputs (I think you would get 100% agreement on those)? Groupings of controls such as navigation, breadcrumbs, tabs, and tree panes? Landmarks? Labels? Lists and headings and even text in some SDKs?

Is it supposed to be understood to mean the same thing as user interface component? The exception points to 4.1.2 for "additional requirements for controls and content that accepts user input." Then 4.1.2. states "For all user interface components (including but not limited to: form elements, links and components generated by scripts)...". Which itself would be a cyclical definition because the definition for "user interface components" includes the word "control": a part of the content that is perceived by users as a single control for a distinct function.

Adding a definition for this term in the glossary would make the meaning of this section of 1.1.1 more understandable and less ambiguous and would ensure that controls are being named more consistently.

[mbgower]

Draft Working Group Response
The existing normative wording has existed since 2008, and there does not seem to be evidence that the use of "control" has been a significant area of confusion in 1.1.1 in the 17 years since.

As you point out, the parenthetical information immediately following its use directs the user to 4.1.2, where the term "control" is used frequently. In fact, the definition of User Interface Component reads:

a part of the content that is perceived by users as a single control for a distinct function

The definition also provides notes and examples that give more context.

You ask:

Does it include links, buttons, and form inputs (I think you would get 100% agreement on those)? Groupings of controls such as navigation, breadcrumbs, tabs, and tree panes? Landmarks? Labels? Lists and headings and even text in some SDKs?

Remember that in the context of 1.1.1, "control" is referring specifically to instances of non-text content. So several of the situations you ask above do not seem relevant to images. Further, there is a list of techniques under Situation C that provide clarity.

It may not be optimal that control is undefined; however, the current wording is part of the normative text, as are all definitions, so changing this is non-trivial. If there are changes you would like to see in the informative Understanding document that you feel could address any perceived confusion, the working group would be happy to consider those.

[alastc]

Also, we try not to define things when we're using the (or a) dictionary meaning. In this case:

a switch or other device used to operate a machine such as a vehicle, examples:

• "control panel" The main instruments are in the centre of the control panel.
• "at the controls" of Captain Firth sat at the controls of the aircraft.