Consider accessible description in the rules that use link context (5effbb, fd3a94)

[carlosapaduarte]

Update rules that use link context to consider the title attribute. Although the original resolution in #1766 requested the changes to be made on the "Programmatically Determined Link Context" definition, given that this specifies a set of elements, it does not seem doable. As an alternative, I've added the accessible description to the expectation of "Link in context is descriptive" and to the applicability of "Links with identical accessible names and context serve equivalent purpose"

Closes issue(s):

• closes Should rules about link's name (b20e66, 5effbb, aizyf1, fd3a94) consider the title attribute? #1766

Need for Call for Review:
This will require a 2 weeks Call for Review

---

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.

[Jym77]

I feel it would be cleaner to remove aria-describedby from "Programmatically determined link context". Since the rules now explicitly mention the accessible description, that already includes aria-describedby references (and actually a few more things such as children of aria-describedby references, if I get the accessible name computation correctly).

So, the PDLC would be some set of elements defined by some DOM tree relationship, and rules about context would look at PDLC + accessible description.
(it would also means that aria-describedby="foo bar" and aria-describedby="bar foo" would be considered as different accessible descriptions while they are currently the same PDLC, which sounds bad)

[kengdoj]

Minor suggestions made.

[kengdoj]

Would be helpful to say "same non-empty accessible name, empty accessible description..."?

[kengdoj]

I added it in a couple other spots.

[WilcoFiers]

I like Kathy's suggestions on these, would like to see them made.

[carlosapaduarte]

I feel it would be cleaner to remove aria-describedby from "Programmatically determined link context". Since the rules now explicitly mention the accessible description, that already includes aria-describedby references (and actually a few more things such as children of aria-describedby references, if I get the accessible name computation correctly).

So, the PDLC would be some set of elements defined by some DOM tree relationship, and rules about context would look at PDLC + accessible description. (it would also means that aria-describedby="foo bar" and aria-describedby="bar foo" would be considered as different accessible descriptions while they are currently the same PDLC, which sounds bad)

Good suggestion. I'm updating the definition accordingly.

updates made

[Jym77]

Should we have our own def of it (like for accessible name?), I'm notably thinking we should link it to the "accessible name and description computation" document.

[carlosapaduarte]

Added a definition of accessible description

[dan-tripp-siteimprove]

One tip to improve the workflow: you can propose changes when reviewing by activating the icon with a plus and a minus sign. That will copy the line to the comment window, and if you change that line, then a change proposal is displayed. That is easier for the reviewer, that does not need to copy paste content, but also for the author that can approve the proposal to include it the pull request.

I figured there must be an easier way. Thank you, I've noted it for next time.

[kengdoj]

Editorial changes for consistency

Updates made

[WilcoFiers]

I'm not sure this is obviously correct. The SC talks about link text and programmatically determined context. Its probably worth putting in the assumption that we're using "link text" from WCAG to mean accessible name and description. Links that fail label in name could have visible text that isn't considered "link text" in this rule. I think that should be in the assumption.

Assumption added

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Carlos Duarte seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}