"Links with identical accessible names and context serve equivalent purpose" [fd3a94]: precise that the rule only looks for "same" context

[Jym77]

There was a bit of confusion whether the rule was looking for "same" contexts (= same elements) or "identical" ones (= similar content? maybe also similar styling?) Since "identical" content is hard to define, we restrict the rule on "same" context and make it explicit in several places.

Closes issue(s):

• closes "Links with identical accessible names and context serve equivalent purpose" [fd3a94]: "same" or "identical" contexts? #1784

Need for Call for Review:
This will require a 1 week Call for Review (changing title and description to match Applicability)

---

Pull Request Etiquette

When creating PR:

• Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
• Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

• Add yourself (and co-authors) as "Assignees" for PR.
• Add label to indicate if it's a Rule, Definition or Chore.
• Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
• Optionally request feedback from anyone in particular by assigning them as "Reviewers".

When merging a PR:

• Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

• Go to the “Files changed” tab
• Here you will have the option to leave comments on different lines.
• Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.

[giacomo-petri]

In role description, should we better define the word "context", or link it to the Programmatically Determined Link Context definition? So there won't be any ambiguity for this abstract term and how to "calculate" it.

About the Programmatically Determined Link Context definition, last list item states:

being referenced by an aria-describedby attribute of the link.

This is very specific to the aria-describedby attribute but also a title attribute has the same effect; should we replace it with

being described by a valid attribute such as aria-descibedby or title attributes.

?

 

In addition, what do you think about the following example (assuming pages have different purposes)?

<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>

Per definition, the context of both "contact us" links is their ancestor paragraph element (both links have the same context).

From WCAG

In some situations, authors may want to provide part of the description of the link in logically related text that provides the context for the link. In this case the user should be able to identify the purpose of the link without moving focus from the link. In other words, they can arrive on a link and find out more about it without losing their place.

so, apparently, it seems failing because users are not able to understand and distinguish these 2 "contact us" links without moving focus, assuming focus includes assistive technology visual indicator (even if the sequence of the elements and the punctuation might suffice to understand which link is referring to which sentence).
That said, at the same time, the next line states:

This can be achieved by putting the description of the link in the same sentence, paragraph, list item, or table cell as the link, or in the table header cell for a link in a data table, because these are directly associated with the link itself.

Which is what I did in my example.

Last, but not least, based on WCAG success criterion 2.4.4

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.

it's a best practice that links with different purposes and destinations have different link text.

If the goal of WCAG understanding is to make the example I've provided failing, should the WCAG clearly states something like "The same context cannot contain more than one link with identical accessible name and description that resolve to different or non-equivalent resources"?

[Jym77]

@giacomo-petri

In role description, should we better define the word "context", or link it to the Programmatically Determined Link Context definition? So there won't be any ambiguity for this abstract term and how to "calculate" it.

We do not use links in rules' descriptions. But the description itself isn't really normative. The Applicability and Expectation are.

About the Programmatically Determined Link Context definition, last list item states:

being referenced by an aria-describedby attribute of the link.

This is very specific to the aria-describedby attribute but also a title attribute has the same effect; should we replace it with

being described by a valid attribute such as aria-descibedby or title attributes.

This is being handled in #1845 where we accept the full accessible description.

In addition, what do you think about the following example (assuming pages have different purposes)?

<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>

🤔 Good one. That is unrelated to the current change, I'll open an issue for that.

[Jym77]

Call for review ends on June 30th.

[Jym77]

Call for review has ended. Merging.