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? #4957
Replies: 5 comments 10 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@kaninchenundente is your question actually about the difference between accessible name and accessible description? I feel like the difference between accessible name and aria-describedby (as well as the difference between accessible description and aria-described by) has been well addressed by the conversation. |
Beta Was this translation helpful? Give feedback.
-
|
@bruce-usab If I'm interpreting the questions correctly, I think it has more to do with the ambiguous definition of the term "name" in WCAG than about the difference between accessible name and accessible description. If we replace the term with the definition in the SC, the relevant portion of 4.1.2 becomes, "... the text by which software can identify a component within web content to the user ... can be programmatically determined". The argument seems to be that both accessible name and accessible description are "text by which software can identify a component". I don't think this interpretation is correct, and I go into my personal reasoning more in another comment on this thread, but I think the confusion at the core of this discussion comes from the way WCAG has defined name. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
so "hey, what's the name of this component?" "i don't know what the name is, but this other element provides a description for it..." |
Beta Was this translation helpful? Give feedback.
-
This may be true but then why can't that description identify some other user interface component? That is, what is the difference here? <label for="surname">Surname</label>
<input type="text" id="surname">
<span id="surname-desc">A name shared in common to identify the members of a family</span>
<input type="text" aria-describedby="surname-desc">
<!-- or even more explicitly -->
<span id="surname-desc">Surname</span>
<input type="text" aria-describedby="surname-desc"> |
Beta Was this translation helpful? Give feedback.
-
|
not sure what more to tell you other than "because naming something and describing something are two separate concepts"? and they're exposed as different values in the accessibility tree, and treated differently by AT? |
Beta Was this translation helpful? Give feedback.
-
|
I’m not sure it makes a difference that they are treated or exposed differently. So long as they’re exposed, if a user can read the text and recognize a user interface component’s purpose or function then the name portion of 4.1.2 is satisfied. The recognization of purpose and function is identification and can be achieved by accessible name or a description. |
Beta Was this translation helpful? Give feedback.
-
|
well that's ... you opinion. 🤷🏼 |
Beta Was this translation helpful? Give feedback.
-
|
The difference between a name and a description is that a description contains additional information (e.g. the input format). If blind users are familiar with an application, they can disable the screen reader’s output of the description when navigating using the TAB key – but not the output of the name. The output of the description can be distracting, so it is optional.
A name is therefore essential for a control and cannot be replaced by a description. |
Beta Was this translation helpful? Give feedback.
-
|
This is a situation where we have several sets of guidelines and standards written by different groups that don't quite mesh with each other. So we have to do the best we can and, where there is ambiguity, apply a dash of common sense. WCAG is the overall controlling specification in many regulations, and sets its own conformance model. SC 4.1.2, among other things, requires that the "name" for a user interface component can be "programmatically determined":
Because of the programmatically determined requirement, the specific technology used for the content in question absolutely matters for any kind of conformance claim. The WCAG conformance model requires that "Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria." So any technologies used to satisfy the SC must be "supported by users' assistive technologies as well as the accessibility features in browsers and other user agents." If we are talking about an HTML document, the specifications differentiate between accessible name and description. Name is defined as the "the name of a user interface element" and description "provides additional information, related to an interface element". In order to identify the component, as required by WCAG, it seems clear to me that that in HTML this means the name rather than additional information. In order to claim conformance, it matters how user agents and assistive technologies make use of the content. In order to programmatically identify a component, the vast majority (all?) AT look to the accessible name. While some AT may supplement with additional information including role, properties and description, without an accessible name AT cannot reliably, programmatically identify the component and thus the requirements of 4.1.2 would not be satisfied. As mentioned elsewhere in this thread, there are many situations where AT will not provide the accessible description (because it is defined as supplemental information) and so using it as the mechanism to programmatically identify a user interface component is not accessibility supported. To put this another way, it is inappropriate to use aria-describedby to provide the name of the component for the same reasons that it is not appropriate to use aria-details or aria-errormessage for the name, or to use aria-description to for the role. They are, by definition, not the way to programmatically supply name or role in an HTML document. |
Beta Was this translation helpful? Give feedback.
-
|
It begs the question then, why doesn’t the normative text of 4.1.2 explicitly reference accessible name if that is truly the intent? Continuing to use aria-describedby as an example - is it not accessibility supported? It certainly seems like it qualifies both for 1 and 2.1. It also doesn’t seem to state that the method used is logical (I argue a description is in this case, clearly). I also consider a controls’ identity to be interchangeable with its description, similar to how a WCAG term is interchangeable with it’s definition. I can say “a navigational device that consists of four cardinal directions, often used in way-finding.” Could someone not identify what I am referring to based on that description? Isn’t that all name is asking for as defined by the normative definition? |
Beta Was this translation helpful? Give feedback.
-
Because WCAG is a general set of guidelines, and accessible name is a technology-specific concept. The mechanism to programmatically expose the name in HTML is defined in the accessible name computation spec. In PDF it's the Tooltip. In a Swift app it's the accessibilityLabel, etc. If you want to look at intent rather than the normative text, that is quite clear - the term name is used in the understanding doc, the HTML accessibility specs then define how to set the name of components, failure techniques are listed for missing accessible names, and the testing techniques listed on the understanding page require an accessible name.
While aria-describedby itself is of course well supported by AT, it does not follow that using aria-describedby to identify the component is supported. It sets the accessible description for an element, which "provides additional information, related to an interface element". I don't see that as providing text that identifies the component, but rather supplemental information about it. When AT tries to find text that identifies the element, it will look to the accessible name which in your example would be missing, making the name not programmatically determinable. There were already several situations noted in another comment on this thread where placing the name in the accessible description will cause a screen reader not to identify the component to a user. The AT impact is even broader than those instances - e.g. for elements that are not focusable, being unusable by voice control, etc. For those reasons I disagree with the argument that using the accessible description as a component name is accessibility supported. It does not meet requirement 1: "The way that the web content technology is used must be supported by users' assistive technology (AT).".
Of course, but the argument is not about whether a human can parse your description, it's about whether software can determine that the text should identify the component. By placing it in the description, you would explicitly be telling telling the software that it "provides additional information" rather than names it. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions