What is the WCAG definition of "component"?

[jha11y]

The word "component"/"components" is used 92 times in WCAG 2.2, but it does not seemed to be explicitly defined.

This makes the definition of User Interface Component a little unclear, specific note 3 under this term:

What is meant by "component" or "user interface component" here is also sometimes called "user interface element".

Is there a difference between user interface component (interactive control?) vs component (element?)

The word component is used in success criterion that include content that is not interactive such as Success Criterion 1.3.3 Sensory Characteristics:

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.

[jha11y]

related issue: #4234

[mbgower]

** Draft Working Group Response**
First, there is a definition for user interface component, so in any success criterion or paragraph of normative content where that defined term is used and the word "component" occurs within the same context, "component" is clearly intended to be a synonym. For instance:

User Interface Components
Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

Second, although there are 92 occurrences of the word "component" in the specification, not all are used in the sense of a user interface component. Some are meant in the abstract non-technology sense. For example:

• For an overview of how these components of web development and interaction work together, see...
• Required Components of a Conformance Claim

A better way to assess a potential problem space is where the word "component" appears in normative text where it does not appear in association with the defined term "user interface component". There are 5 criteria where this occurs:

• 2.1.2 No Keyboard Trap
• 2.4.3 Focus Order
• 2.4.13 Focus Appearance
• 3.2.4 Consistent Identification
• 1.3.3 Sensory Characteristics

Given that No Keyboard Trap, Focus Order, and Focus Appearance are all about interaction, the context seems very clear, and does not seem to create a problem. The language of Consistent Identification states "Components that have the same functionality, which again makes it clear it is about something that can be operated. So the only one that is potentially unclear is the one you flagged, Sensory Characteristics.

As per your quote of its normative text, Sensory Characteristics covers both "understanding and operating". As well, the examples in the Understanding document cover both operation of buttons and a situation where a user is interpretting the information in a table. If "component" was used strictly in the sense of user interface component, it would actually restrict the scope of this requirement. It would only cover instructions about operation. The first example concerning interpreting colour on a non-operable schedule would no longer be valid.

If you think we should add additional context in this Understanding document to clarify it does not apply only to instructions for user interface components, please confirm. Also, feel free to provide suggestions.

There are also 6 definition where the word occurs without a link to the definition

• label
• minimum bounding box
• name
• role
• synchronized media
• viewport (uses "interface components" without linking to definition)

Almost all of the occurrences of these defined terms happen within the context of user interface components. Label could be considered an exception to this, since it also is used normatively in Headings and Labels, which are typically not operable. If you believe we should add additional context in this Understanding document, and where, please let us know.

.

[electronicwoft]

a further confuision occurs when speaking with developers who commonly use 'component' to mean a named unit of code in the sense of 'widget' or 'module' which may or may not have any bearing on whether someone using the UI perceives such and such as performing a given function.

A standalone button is a component in the mind of a developer as much as a series of buttons at the bottom of a form because this is how a developer may implement these 'user interface components'.

The distinction made on the basis of 'functionality' as in SC3.2.4 doesn't resolve the issue of the inconsistent use of 'component' either given that 'functionality' is normatively defined as "processes and outcomes achievable through user action"

It is not the interactivness of functionality, but the possibility that an outcome may be achieved using something other than a particular component or components in the sense of units of code.

Someone may use the search component on a website to find a particular topic or use the provided navigation, and, in the sense of component as unit of code, they've used two components, but the outcome and therefore the functionality provided by these two units of code is the same.

This also occurs in the definition of a user interface component: "a part of the content that is perceived by users as a single control for a distinct function".

This 'distinct function' is the way that developers might understand how a unit of code is expected to behave and it is similarly not consistent with the normative definition of functionality.

As the search example illustrates, a user might understand two different units of code as performing the same function whereas it is very common for developers to see function in the sense of 'a single control' like a dropdown as something akin to 'activation behaviour' in HTML.

The equating of 'user interface component' with 'single control' in this definition affirms this connotation.

In my experience, this can lead to lengthy and unnecessary back and forth between evaluators who may know nothing about code who describe accessibility issues experientially and developers who may have little or no understanding of a user interface beyond instantiating a component in a front-end library.

Whatever changes are to be made if any (probably too late for 2.x) should take this equivocality into consideration.

[jha11y]

Almost all of the occurrences of these defined terms happen within the context of user interface components. Label could be considered an exception to this, since it also is used normatively in Headings and Labels, which are typically not operable. If you believe we should add additional context in this Understanding document, and where, please let us know.

If in the definition of Label in WCAG (definition included below), the term “component” (used twice) is considered an exception, this seems like there might need to be some guidance in WCAG itself about the term “component”. This might include possibly a note or a separate definition. Shouldn’t a term used in WCAG either be straight forward with no exceptions or well defined including any exceptions?

Label definition
text or other component with a text alternative that is presented to a user to identify a component within web content

There are concerns from the Mobile Accessibility Task Force (MATF) about how the term component fits in with the definition of Label. Particularly when it comes to web links, Do web links have a label? Is a web link considered a “component”? Getting an answer to these questions from the larger Working Group will effect how this task force molds the WCAG success criterion to fit with native mobile content paradigms.

You also mentioned:

Almost all of the occurrences of these defined terms happen within the context of user interface components.

One of those terms was Name (definition included below)

Name definition
text by which software can identify a component within web content to the user

If “component” is synonymous with “use interface component”, does that mean that a Name (Accessible name) is only required for interactive items and not structural or content-based items like landmarks, groupings, tables, etc.?

[mbgower]

Shouldn’t a term used in WCAG either be straight forward with no exceptions or well defined including any exceptions?

Sure, but unfortunately that is not always the reality. The Task Force has to work within the constraints of the existing normative content; it strives to make things closer to what I think we both agree is how things should be. The scrutiny thus far has turned up two situations where I think some context is needed (Sensory Characteristics and Heading and Labels). I think we can provide clarity there. How other people use "component" is obviously outside TF control.

The occurrences of the defined term name seem to be restricted to UIC situations. If you find one that is not, please surface. It is important to note that a word like "name" may be used normatively (and it should always reference the definition in its first use in a normative context) and non-normatively. For instance, the word "name" appears in lots of situations where it is not specifically used to mean the defined term name.

If “component” is synonymous with “use interface component”, does that mean that a Name (Accessible name) is only required for interactive items and not structural or content-based items like landmarks, groupings, tables, etc.?

I think a better way to put that is that defined uses of name lead to 4.1.2, which was added to knit ARIA into the WCAG fabric for UICs beyond the HTML elements available. So from that perspective, I'd answer "yes".

But it's important to emphasize that 1.3.1 Info and Relationships also deals with "Information, structure, and relationships conveyed through presentation". You'll note that "name" doesn't appear in 1.3.1 normative text, although different technologies might use attributes called "name" to achieve 1.3.1. Before ARIA came along, there were still programmatic ways in which you could designate table structure and some kinds of groupings. Landmarks are typically also addressed by 1.3.1, because a region is presentational, not operational (although it can obviously contain UICs).

I'm opening issues to deal with the 2 items I identified so far that require action. If you think others specifically need addressing, please indicate.