[4b1c6c]: CG Discuss: Remove rule "Iframe elements with identical accessible names have equivalent purpose "

[tombrunet]

Copying over conversation with Jean-Yves:

From Tom:

This is related to https://www.w3.org/WAI/standards-guidelines/act/rules/4b1c6c/proposed/.

On the task force call, discussion landed that we believe that this rule is not supported by WCAG, but rather falls into best practices. As such, we believe this rule should be removed, since it has not yet made it past the proposal stage. A little more background….

We initially were circling a little bit on the discussion of what defines an ‘equivalent resource’. However, in trying to define that, it seemed to us that there really isn’t a WCAG SC that requires this. The SC noted by the rule is 4.1.2. That SC, however, only says that the name is programmatically determinable. We think that it’s a reasonable assumption that 4.1.2 implies that that name should be descriptive / correct, but we can’t find any evidence in the SCs that says that frame names must be unique. Perhaps not a real example, but for illustrative purposes, if you had two frames that were named “about trains”, and one was about locomotives and the other is about wedding dress trains, each of those satisfies 4.1.2 by providing a programmatic name. While we agree that there may be a better user experience to provide disambiguation, we don’t believe that this is a requirement of WCAG.

Can you discuss this with the community group and provide your thoughts?

From Jean-Yves:

Hi Tom, good points…

The rule has an assumption to cover this case: “This rule assumes that, within the context of the test subject, the description provided by the accessible name of an iframe can only accurately describe one resource (notably, homonyms alone are not used as iframe names). Thus, if two or more iframe elements have the same accessible name but embed different resources, at least one of them does not describe its purpose.” But it might be too broad an assumption…

There was also quite some discussions on the topic back when we wrote the rules (and assumptions): https://github.com/act-rules/act-rules.github.io/issues/968 (sadly some of it seems to have happen offline in the WAI-tools project discussions). These are mostly focused on links names, though.

Thus said, situation may have change, and we may need to reconsider these choices. Additionally, links are governed by 2.4.4/2.4.9 and iframes by 4.1.2, so the situation may be different.

I guess the best is to open an issue that we can take in a CG call and see what people think about it.

From Tom:

Looks like there’s some more in https://github.com/act-rules/act-rules.github.io/issues/1008 and a fairly length unresolved discussion in https://github.com/w3c/wcag/issues/929 . But, it seems as it stands now, there seems to be agreement that 4.1.2 does not require anything other than a programmatically determined name as currently written, it’s arguable if it’s implied that it must be descriptive, but nothing to indicate that 4.1.2 requires uniqueness.

Given the current state of things, I can't identify any normative support in WCAG for this rule - even though many of us agree that it's a good best practice.

[kengdoj]

Not normative, but this PR added "appropriate" to Intent of Understanding 4.1.2.

[Jym77]

CG decision (April 25th): use secondary requirement for 4.1.2 (maybe also for 1.3.1?), and point to the Understanding 4.1.2 justifying that the name should be "accurate".

[tombrunet]

@Jym77 So is the decision to have no success criteria nor w3c standards to support the rule, but still keep it?

[Jym77]

@tombrunet Yes.

Well, not fully, we'll still keep secondary requirements, which show the rule is related to these SC, but acknowledge that we can't guarantee a fail-on-fail relation. Secondary requirements also means that implementation will be considered as consistent no matter whether they fail that SC or not, thus leaving room for tools to be more clever than the rule in detecting cases that actually fail the SC.

[tombrunet]

@Jym77 I don't think that meets the intention of secondary requirements. Secondary requirements are intended to handle situations where a rule is more or less strict than an SC, but is not intended to handle things that may be tangentially related. Two iframes with identical names yet point to different resources have no bearing on the success or failure of 1.3.1 nor 4.1.2.

The problem here is that if the rule passes, you can never assume that you satisfy either SC. And if it fails, it is never an indication that you fail either SC, so you should never flag either of those SCs based on this rule as written.