2.4.6 - Does this only apply to undescriptive accNames derived from the label?

[anevins12]

Hello!

Does 2.4.6 Headings and Labels only apply to accessible names when the name is derived from the visible label or heading? For some examples, I'll list scenarios where I think 2.4.6 is and is not applicable. Are any of these scenarios incorrect?

Applicable to 2.4.6

1. A modal dialog is named by a visible heading inside the dialog via aria-labelledby. The label of the heading, however, is not descriptive.
2. A modal dialog contains a visible heading and paragraph. By mistake, the dialog name references the paragraph via aria-labelledby. The paragraph is descriptive in context, but the accessible name of the dialog is not descriptive.
3. A <button> is named by its visible contents, but the contents are not descriptive.

Not applicable to 2.4.6

4. A <button> control contains a descriptive and visible label as its contents, but is named undescriptive via aria-label. Going slightly further with 2.5.3, the undescriptive name does, however, contain a word from the visible label.
5. A modal dialog contains a visible heading, but it invents an accessible name from aria-label. The accessible name is not descriptive.

[alastc]

Hi Andrew,

This SC isn't focused on the markup, as the understanding doc says:

This Success Criterion also does not require that content acting as a heading or label be correctly marked up or identified - this aspect is covered separately by 1.3.1: Info and Relationships.

It is more a case of: If you have a visible heading or label, does it describe the topic / purpose?

So in your examples, if it is visible and "is not descriptive", then it fails.

If it is the accname only and is not descriptive, then that probably fails 1.3.1 or 4.1.2.

1: fail, 2: not applicable, 3: fail, 4: NA but probably does fail 2.5.3, 5: NA but probably fails 1.3.1/4.1.2.

[patrickhlauke]

x-ref #2134 - the gnarly edges where the "labels are for everybody, and we don't mean accname" part of 2.4.6, and the "4.1.2. says there needs to be an accname, not whether or not it's good/bad/descriptive enough" discussion, collide.

[detlevhfischer]

As argued in #2134 : For us continentals, the typical cases is all the x elements with aria-label="close" (should be "schliessen" or similar in a German site) or the umpteen menu elements labelled "togglemenu" So where is the issue? Is there a name? Yes. Is it descriptive? No. That's why I lean towards including such cases in 2.4.6 (and stick lack of state and role into 4.1.2).

[patrickhlauke]

So where is the issue?

3.1.2 Language of Parts ... ducks

[detlevhfischer]

@patrickhlauke not sure if you are serious - but if you are, I'd have thought 3.1.2 applies to marking up language correctly whatever language you use (which may be difficult for aria attributes, not sure whether they inherit the language of the element they sit on)...

[patrickhlauke]

it was half-joking, but it would currently fail that point already (even more so if it's something that's not even technically feasible) (let's not mention Hawaiian diacritics though...)

[alastc]

I guess you could apply lang="en" on those icons and it would pass language of the page, but still be unusable!

On the more general point, I don't think there's an issue where there is a visible (and descriptive) label and the accname is descriptive. (If they are different that could fail label-in-name, but that's a different matter.)

Where there is no visible text label, I guess you could squint hard and apply the SC to the accname?

Where there is an icon as the visible label, I'd look at the alt-text to be equivalent.

Was that roughly the result of the other thread or am I off base?

[anevins12]

A control that relies on a text alternative can be failed under 1.1.1, but, if we add in aria-label what then? For example, what if a "Close" <button> in a dialog is represented visually only as an icon. The icon contains a descriptive text alternative of "Close", but then aria-label="${something-went-wrong}" is on the <button>. From the answers above, this is a 1.3.1 failure and not 2.4.6. Correct?

Also, hello @alastc !

If it is the accname only and is not descriptive, then that probably fails 1.3.1 or 4.1.2.

Perhaps not 4.1.2, as the accuracy or descriptiveness of accNames is not covered. I'll take 1.3.1!

[patrickhlauke]

The icon contains a descriptive text alternative of "Close", but then aria-label="${something-went-wrong}" is on the

as the aria-label is, in effect, the alternative to the non-text (since it overrides whatever's inside), it's still a 1.1.1 failure

[davidofyork]

Where there is no visible text label, I guess you could squint hard and apply the SC [2.4.6] to the accname?

But as @patrickhlauke refers to above, the Understanding doc for 2.4.6 clearly distinguishes between a label and an accessible name:

Note
A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.

And sure, 4.1.2 is perhaps not ideal (given its focus on the presence, not accuracy of accNames) but as the intent of 4.1.2 is to "gather information about, activate (or set) and keep up to date on the status of user interface controls in the content", could you not argue that a non-descriptive accName prevents that?

[patrickhlauke]

could you not argue that a non-descriptive accName prevents that?

but then what if a control has a visible label that is also the accName, and it's non-descriptive. Do you then want to fail both 2.4.6 and 4.1.2? Or do you then let 4.1.2 pass? That's one of the problems...

[patrickhlauke]

to me, the more sustainable solution would be to look again at 2.4.6 and specifically that note that separates "label for everybody vs. accessible name". Seems this has had some unintended consequences of having borked accNames fall between the cracks.

[davidofyork]

Do you then want to fail both 2.4.6 and 4.1.2?

Yeah, why not? You'd have a non-descriptive label and a non-descriptive accName.

[patrickhlauke]

Yeah, why not?

because then in the normative requirement, as well as the non-normative understanding, for 4.1.2 you'd have to start integrating all the rationale for what is and isn't "descriptive", mirroring 2.4.6 into it effectively. fun times...

[davidofyork]

to me, the more sustainable solution would be to look again at 2.4.6 and specifically that note that separates "label for everybody vs. accessible name". Seems this has had some unintended consequences of having borked accNames fall between the cracks.

For sure, tweak that. But the SC concerns labels, which are different from names.

[patrickhlauke]

For sure, tweak that. But the SC concerns labels, which are different from names.

https://www.w3.org/TR/WCAG21/#dfn-labels

text or other component with a text alternative that is presented to a user to identify a component within Web content

for an AT user, that's the accName. it's only because of the first note in the definition that we're prevented from making a "descriptive enough or not?" judgement when the accName 1) differs from the visible label; 2) is incorrect

[davidofyork]

So what are you suggesting? Make labels and names synonymous? Redefine them? That note (and the corresponding note under name) serve to distinguish the two.

[patrickhlauke]

Of course can't brutally change the definition, as that would then affect other SCs (especially nonsensical for 2.5.3 Label in Name). Which is why this is non-trivial (but nonetheless easier than trying to cram the concept of "sufficiently descriptive" normatively into 4.1.2 Name, Role, Value)

[anevins12]

The only outstanding thing with 2.4.6 is its definition of a "Label":

text or other component with a text alternative that is presented to a user to identify a component within Web content

Which relies on the definition of "Text":

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language

And then the definition of "Programmatically determined":

programmatically determined (programmatically determinable)
determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities
Example 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.
Example 2: Determined from technology-specific data structures in a non-markup language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

I can't see how 2.4.6 doesn't apply to programmatically determined text even if it is invisible.

[patrickhlauke]

@anevins12 but the first note in the definition https://www.w3.org/TR/WCAG21/#dfn-labels makes the point that label is presented to all users, so just the accname is not a label. and the definition of label is also referenced from 2.5.4 Label in Name https://www.w3.org/TR/WCAG21/#label-in-name (so it's not just "2.4.6's definition of Label"). and you'd end up with a weirdly circular SC if you now said that accname (on its own) also counts as a label, as then "Label in Name" would always pass...

though oddly by the same logic, if the visible label and the accname diverge (i.e. fail 2.5.4), you could also argue based on that first note in the definition that there is no label since there's nothing that's presented to all users (since they're being presented with different things)... though AT users would in some cases still be able to "get" to the visible label unless it was being completely overridden by something like aria-label or similar...

anyway, that's the tangled web we weave...

still pondering a slight tweak of 4.1.2 perhaps...qualifying the "needs to have an accessible name" bit to perhaps not introduce the whole concept of "descriptiveness" there (as that would be too much), but some concept of "correct/appropriate" (though that's wooly in its own right as well)