"Links with identical accessible names and context serve equivalent purpose" [fd3a94]: Definition of context is still not good enough

[Jym77]

As pointed in #1864 (comment),

<p>
    <span>For more details about your order <a href="page1.htm">contact us</a>.</span>
    <span>For more details about how to return products <a href="page2.htm">contact us</a>.</span>
</p>

This two links have the same name, the same programatically determined context, and different destination. Therefore they fail Links with identical accessible names and context serve equivalent purpose. But they probably don't fail 2.4.4 since the sentences make it clear where they go…

[giacomo-petri]

Thanks Jym for opening the issue.

I was thinking about my request, also comparing it with the existing passed and failed examples, and I made some broader considerations:

Rule title: Links with identical accessible names and context serve equivalent purpose (reworded in "Links with identical accessible names and same context serve equivalent purpose" in #1864)

Assuming applicability points are met, is it always an accessibility failure or more in general a usability one?
In my opinion, links with identical accessible names and same context that point to different resources are ambiguous to users in general (unless CSS is visually adding something relevant, not conveyed by alternatives, but it's covered by SC 1.1.1).
For example, Failed Example 1 results in an unpredictable behaviour for everyone. All users are forced to activate these links to understand which is the destination, unless you hover the link, looking at the src via browsers functionality, but this can be rendered also by assistive technologies (for example pressing ctrl+opt+shift+U using VoiceOver). Of course, this will impact more users affected by specific disabilities, but the SC 2.4.4 clearly states:

except where the purpose of the link would be ambiguous to users in general.

The inability to determine which is the link purpose that makes the 2.4.4 SC failing (assuming it's not ambiguous in general), here is not determined by the identical accessible name within the same context, but from the context itself.

Should the title be something like "Links that serve equivalent purpose within the same context have identical accessible names"?
At first glance, the two propositions seem the same but the new one changes completely requirements, techniques, etc. Focus is no longer on the label and context, but it's on the link purpose first (as per WCAG).

That said, based on SC 2.4.4 and SC 3.2.4, I'm still not sure it's strictly an accessibility failure:

It is a best practice for links with the same destination to have consistent text (and this is a requirement per Success Criterion 3.2.4 for pages in a set). It is also a best practice for links with different purposes and destinations to have different link text.

per 2.4.4 it's a best practice

While it is desirable and best practice always to be consistent within a single web page, 3.2.4 only addresses consistency within a set of web pages where something is repeated on more than one page in the set.

per 3.2.4 it's a requirement but only in a set of pages (single page is not covered by 3.2.4)

Conclusions:
As accessibility expert, I would for sure suggest to improve the usability of these ambiguous links, resulting in an accessibility improvement too, but I'm not sure they are failing WCAG 2.1 AA, as is right now.
If the intent is to make these items failing, I think that WCAG 2.1 AA should be updated accordingly.

What are your thoughts?

[carlosapaduarte]

Summary from CG discussion:

• the rule assumes that links with the same accessible name and context are not ambiguous to users in general. But how often if that the case?

[giacomo-petri]

Failures provided are ambiguous to users in general, in my opinion.

Two links with identical accessible name and with the same programmatically determined context, but with different CSS backgrounds (that visually convey information) is the only example that comes to mind, assuming that our definition of context does not include visual properties not included within the accessibility tree.

See attachment for more details: example.zip

[Jym77]

Been crunching some numbers on our data. Around one third of the pages we test are Applicable for this rule 🤔
(that's much more than I assumed…)

[carlosapaduarte]

From CG meeting: we need to update the definition of programmatically determined context

[dan-tripp-siteimprove]

WCAG's definition of "programmatically determined link context" seems to mention two new ideas:

1. a paragraph as defined by the English language (not just a <p> element).
2. the current sentence, as delimited by punctuation (presumably English punctuation).

ACT's definition of "programmatically determined link context" doesn't mention those two things. (Even though it says that it is "based on the WCAG definition", I take this to mean "loosely based").

If we changed the ACT definition to include sentences (like WCAG does), what would happen?

[mitchellevan]

WCAG's definition of "programmatically determined link context" seems to mention two new ideas

1. a paragraph as defined by the English language (not just a <p> element).
2. the current sentence, as delimited by punctuation (presumably English punctuation).

What's more, WCAG has this sufficient technique for SC 2.4.4: G53: Identifying the purpose of a link using link text combined with the text of the enclosing sentence. G53 does not require semantic markup, only sentence punctuation.

The discrepancy causes false positives in two ACT rules based on programmatically determined link context.