Question: Why is WCAG 4.1.2 "name" treated as accessible name, when a description, e.g. aria-describedby, seems to fit WCAG's definition as well?

[kaninchenundente]

I'm trying to understand a gap between the normative WCAG definition of "name" and how the a11y industry actually applies SC 4.1.2.
WCAG's glossary defines name as:
"text by which software can identify a component within web content to the user."

On the other hand, WAI-ARIA defines aria-describedby as:
"Identifies the element (or elements) that describes the object."

ARIA also notes that aria-labelledby and aria-describedby are similar because both reference other elements to calculate a text alternative, but says a label should be concise while a description is intended to be more verbose.

This leaves me with a specific question:
• If WCAG's normative definition of "name" is basically "text software can use to identify the component to the user,"
• and aria-describedby provides programmatically determinable text tied to the component (and could absolutely "identify" it in a user-facing sense, even if it's verbose),
why is the common industry interpretation that 4.1.2 "name" is essentially synonymous with the computed accessible name (and that aria-describedby doesn't count)?

In other words: why is 'name' effectively equated to 'accessible name,' instead of allowing aria-describedby text to count when it can identify the control?

I'm not trying to argue best practice (I get that labels should be concise). I'm trying to understand the spec mapping: why does 4.1.2 'name' effectively mean 'accessible name' in audits/tools, given the normative WCAG definition?

[lilzesh]

This is an interesting and important call out. If you gathered 100 accessibility folks in a room the consensus would be that this section of 4.1.2 is referring to accessible name. It may even be unanimous. A couple examples illustrating this can be found in the wild, e.g., Deque's axe-core library, two of which are their link-name, and button-name rules.

While that may have been the intention of the authors of this success criterion, is that what the published normative text requires? I do not believe this success criterion, as written, requires a user interface component to have an accessible name. While I have, and likely will continue to do so, write up issues where user interface controls are lacking an accessible name, it does seem like a case can be made that this success criterion does not actually require an accessible name?

The broadness of the name definition could lead to some questionable user interface components. For instance:

<span id="text-identifying-a-component"> Name </span>
<input type="text" aria-describedby="text-identifying-a-component">

This component has no accessible name, will fail all automated tests (that I know of), and likely, any manual test. However, it feels very difficult to argue that this text, i.e., Name, is not "text by which software can identify a component within web content to the user," and does not pass the name requirement for 4.1.2.

[mraccess77]

The HTML Accessibility API Mappings 1.0 https://www.w3.org/TR/html-aam-1.0/ defines what can be used for the name and description.

[kaninchenundente]

WCAG 4.1.2 uses "name" as a general concept and doesn't normatively point to HTML‑AAM as the definition of what counts. So citing HTML‑AAM doesn't really resolve the question about what WCAG strictly requires.