Technique H64 interpreted as 4.1.2 requiring descriptive accessible name?

[patrickhlauke]

The current ACT Rules iframe elements with identical accessible names have equivalent purpose seems to imply that under WCAG 2.1 4.1.2 accessible names must be descriptive/unique. As normatively 4.1.2 doesn't say that, and there's no indication in 4.1.2's understanding documentation about it, I opened https://github.com/act-rules/act-rules.github.io/issues/1008

There, it was pointed out that inspiration was taken from H64 Using the title attribute of the frame and iframe elements.

I would still say that 4.1.2 says nothing specific about the accessible name of an interface component other than the component needs to have one. Whether it's descriptive or not is irrelevant and not defined by the SC (neither normatively in the SC text itself, nor non-normatively in the understanding document). In fact, it's one of those gaps in WCAG (where links need to have link text that makes sense in context (AA) and even out of context (AAA), but no such requirement exists for accessible names under 4.1.2 - though arguably, for controls like <button> elements, you COULD argue that they need to have descriptive labels/accessible names in light of 2.4.6 Headings and Labels).

Can this be clarified?

[awkawk]

I think the way to find out is to get this rule to AG and have them either confirm it or reject it.

@WilcoFiers do you know when the WG will be reviewing the proposed test?

[mraccess77]

A related topic is whether pages inside the iFrame need a title element - I'd say no as the iframe is an embedded part of the page and WCAG's conformance unit does is not designed for embedded content on it's own but pages that may include embedded content.

[yatil]

Hi, can we get a decision on this?

[patrickhlauke]

Hi, can we get a decision on this?

added this to the WCAG 2.x backlog for discussion. can't guarantee that we will, but we'll see...

[yatil]

I mean, even a decision like “this cannot be determined/we leave it to testers” is a decision that I can live with. I have a hard time with questions that are left hanging for a number of years.

[detlevhfischer]

I happened to come across this old issue, saw that there have been requests to resolve this in the AGWG, and in order to move on with it, I have proposed a Working Group answer that reflects the view of a part of the Working Group while not satisfying another part. Nevertheless, it seems important to clarify the normative ask of 4.1.2, which in the end hinges of the understanding of the definition of "name": what it means to "identify a component within Web content to the user" (my emphasis).

Proposed working group answer: The Working Group has been asked to determine whether the normative text of Success Criterion 4.1.2 "Name, Role, Value" implies that an accessible name must not only be present but also descriptive/unique.

This answer brackets out the question whether an accessible name has to be unique, since this seems orthogonal to the question of whether it needs to be not only present (non-empty) but also in some way descriptive.

The issue discussion has shown that there are different positions within the WG on the meaning of the normative text in the light of the the normative definition of name. While the normative text of 4.1.2 "Name, Role, Value" requires that for user interface components

the name and role can be programmatically determined

The normative definition of name is

text by which software can identify a component within Web content to the user

"to the user" indicates that this identification via programmatic determination is not merely one that can be used by some program logic, but that the name can be understood by a user when it is exposed, for example, via a screen reader. If a button with a visible label of "buy now" had a programmatic label of "cancel", the accessible name is misleading, i.e., from a user perspective, the name does not identify the component.

In 4.1.2, there is no requirement that the visual label of a control is identical to (or contained in) the accessible name (this is is the ask of 2.5.3), and if both deviate while identifying the control to the user, that is no failure of 4.1.2. The name for a button initiating a purchase may thus equally be "Buy", "Buy now" or "Purchase now", since all three names would identify the component to the user. If, however, the accessible name of that button would be some code meaningless for the user, such as "F923401", or something that clearly contradicts the function of the User Interface Component, such as "Cancel", it would fail 4.1.2.