New Rule: Links with identical accessible names serve equivalent purpose #220

annethyme · 2018-08-20T14:24:57Z

<< Describe the changes >>

Closes issue: #210

Reviewer checks

Required fields, to be filled out by PR reviewer(s)

Make sure you requesting to pull a issue/feature/bugfix branch (right side) to the master branch (left side).
Make sure the pull request is prefixed with Rule: or Algorithm: or Chore: based on work involved.

How to Review And Approve

Go to the “files changed” tab, there 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” and click “Submit review”.

…e.md #210

…e.md Updated test cases to involve scripted links

Test assets for PR #220

ShadowBB · 2018-08-24T15:41:38Z

This looks very good. I will approve as soon as I can verify the test assets.

jeeyyy · 2018-09-04T08:44:55Z

_rules/SC2-4-9-links-with-identical-accessible-names-have-same-purpose.md

+
+The rule applies to any two or more HTML or SVG elements that have the [semantic role](#semantic-role) of link, are [exposed to assistive technologies](#exposed-to-assistive-technologies) and that have the same [accessible name](#accessible-name).
+
+**Note:** Leading and trailing whitespace and difference in case sensitivity should be ignored when deciding whether the [accessible names](#accessible-name) are the same.


This seems to be implementation detail and may be it is best if it lived within the definition of accessible name?

Put into seperate PR since other rules are also relying on the definition: #254

jeeyyy · 2018-09-04T08:46:45Z

_rules/SC2-4-9-links-with-identical-accessible-names-have-same-purpose.md

+
+### Expectation
+
+For each set of target elements, activating the links resolves, after any redirects, to resources that fulfil the same purpose in relation to the purpose indicated by the [accessible names](#accessible-name) of the link.


activating the links resolves is not simple to understand, also there are multiple breaks in this sentence.

How about:
Each target element resolves to resources .....

I believe resolve inherently tackles redirect

Applicability rewritten and redirect guidance split out into a note.

jeeyyy · 2018-09-04T08:47:43Z

_rules/SC2-4-9-links-with-identical-accessible-names-have-same-purpose.md

+* contain different amounts of information and/or differently worded information
+* are using different layouts.
+
+**Note:** If the same content is presented in different formats, the format itself is often part of the link purpose, e.g. an article as both HTML and PDF.


if the format of the resulting page is different, the links would be ideally different, and can be ignored for the rule itself?

With the direction this rule is taking, it should be evaluated if the purpose is actually the same...

I don't really understand what is the purpose of this note, or how it would help interpret the rule

jeeyyy · 2018-09-04T08:48:25Z

_rules/SC2-4-9-links-with-identical-accessible-names-have-same-purpose.md

+
+## Assumptions
+
+* This rule assumes that the purpose of the links for links with identical link texts would not be ambiguous to users in general, which is the exception mentioned in the success criterion 2.4.9 Link Purpose (Link Only).


A link to SC2.4.9 in the background can be beneficial.

There's already a link in the Background, but now also a link here

jeeyyy · 2018-09-04T08:51:06Z

test-assets/my-university/index.html

@@ -0,0 +1,12 @@
+<!DOCTYPE html>


Ideally these file names are prefixed with the relevant SC, and not with in nested folders.

In this case, it could be

test-assets/SC2-4-9-rule-name-my-test-asset-file.html

@JKODU, can we create some guidance on this? And maybe a clean-up... I just had a look in the folder and tried to copy what I saw.

Thinking further about it, wouldn't it make sense that each rule had it's own folder for test assets, where the folder name is the same as the rule name?

We reached a consensus on this in a previous meeting.

jeeyyy

See comments.

…e.md Addressing Jey's comments

Adding new paragraph on comparing acc names, that has so far been note in these rules: https://auto-wcag.github.io/auto-wcag/rules/SC2-5-3-label-content-name-mismatch.html #220 #251

We still need to discuss test assets, but can you review the rest again?

annethyme · 2018-09-14T19:56:34Z

Test assets still missing, while waiting for decision on test asset folder structure and naming conventions.

Please do review the rest in the meantime.

ShadowBB · 2018-09-18T10:19:43Z

Will you make a separate pull requests of the test assets later? I'll approve this.

jeeyyy · 2018-09-24T09:16:59Z

@nitedog please review

nitedog · 2018-09-24T11:35:50Z

_rules/SC2-4-9-links-with-identical-accessible-names-have-same-purpose.md

+
+**Note:** If the same content is presented in different formats, the format itself is often part of the link purpose, e.g. an article as both HTML and PDF.
+
+**Note:** If the [normalized](#url-normalisation) value of the ´href´ is identical, the resources are identical, thus fulfilling the same purpose. [Relative URLs](https://www.w3.org/TR/WD-html40-970917/htmlweb.html#relative-urls) first need to be resolved to full URLs before doing the comparison.


This is referring to a Working Draft of HTML4. Is there a comparable reference in HTML5?

nitedog · 2018-09-24T11:38:05Z

_rules/SC2-4-9-links-with-identical-accessible-names-have-same-purpose.md

+
+## Assumptions
+
+* This rule assumes that the purpose of the links for links with identical link texts would not be ambiguous to users in general, which is the exception mentioned in [Understanding Success Criterion 2.4.9: Link Purpose (Link Only)](https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-link-only.html).


I recommend removing the second half of the sentence "which is the exception ...". The rule already refers to SC 2.4.9 which spells out this exception. Adding another link to the Understanding document is superfluous and also adds potential maintenance overhead.

Separately from the above, is it usual to have such aspects of the requirement in the assumptions section? Seems a little odd to me. I would expect this to be part of this or another rule rather than as an assumption.

audreymaniez · 2019-04-19T04:59:56Z

_rules/6cbcbe.md

+Links created via scripting with explicit role of link, but leads to the same resource: 
+
+```html
+<span role="link"


I know that is not the point, but can we just add tabindex="0" to every span with role="link" :-)

Otherwise, the test case won't be keyboard usable (and since it's not the point of the test, I think it's a little damaging)

audreymaniez

What a great job, really well documented 👏
I'm just questionning the expectation about the instant redirection.

audreymaniez · 2019-04-19T05:23:11Z

_rules/6cbcbe.md

+### Expectation
+
+When followed, the links in each set of target elements resolve to the [same resource](#same-resource) or to [equivalent resources](#equivalent-purpose).
+Resolving the links includes potential redirects, if the redirects happen instantly.


I'm interesting in understanding how a redirection that is not instant can impact the evaluation of how the ressources are the same or not ?

I see the discussion here, and I think it's fair on a user impact side, but i would failed the redirection itself with SC 3.2.5 not on link purpose.

Continuing from that example, if /foo/b.html redirects to /foo/a.html after 10 seconds, a user would actually get to experience and possibly interact with /foo/b.html before being redirected to /foo/a.html. As such, /foo/b.html is experienced as distinct from /foo/a.html and the two are therefore clearly not the same resource. If, on the other hand, /foo/b.html redirects instantly to /foo/a.html, the two are experienced as the same resource, namely /foo/a.html.

I absolutely agree that such a delayed redirect should fail the WCAG, but that is not the concern of this rule. As you point out, it would also fail this rule which may or may not be appropriate; I don't know enough about the WCAG to have an opinion on that though.

Thank you @kasperisager for the explanation.

@WilcoFiers your comments on putting it as a note means that the redirection is not to be tested within that rule?

DagfinnRomen · 2019-04-23T17:10:00Z

pages/algorithms/equivalent-resource.md

+
+Non-identical resources can still be equivalent by equally complying to the expectation formed by the user when navigating to them, thus serving an equivalent purpose. This would usually involve that the advertised key content is the same.  
+
+Web pages and documents (e.g. PDFs, office formats etc.) may fulfil be equivalent resources, even if the resources:


There may be an extra word in this sentence, "may fulfil be equivalent resources".

carlosapaduarte

Amazing work @annethyme
Just some editorial changes remaining, I believe

carlosapaduarte · 2019-04-24T21:52:20Z

_rules/6cbcbe.md

+
+### Applicability
+
+This rule applies to any set of any two or more HTML or SVG elements that have the [semantic role](#semantic-role) of `link`, or a role that inherits from the `link` role, are [included in the accessibility tree](#included-in-the-accessibility-tree), and that have [matching](#matching-characters) [accessible names](#accessible-name) that does not only consist of [whitespace](#whitespace).


carlosapaduarte · 2019-04-24T22:00:08Z

_rules/6cbcbe.md

+
+## Assumptions
+
+This rule assumes that the purpose of the links with identical names would not be ambiguous to users in general when seen in context on the web page, as users of assistive technologies in this case is not at a disadvantage when viewing the link out of context, e.g. on a list of links in a screen reader.


The second part of the sentence is not easy to read and understand. Since I'm not sure about what you meant, I'm not able to offer a suggestion :-(

EDIT: nvm it is all cleared up now. Approved.

From the Understanding document:

The Success Criterion includes an exception for links for which the purpose of the link cannot be determined from the information on the Web page. In this situation, the person with the disability is not at a disadvantage; there is no additional context available to understand the link purpose. However, whatever amount of context is available on the Web page that can be used to interpret the purpose of the link must be made available in the link text to satisfy the Success Criterion.

(https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html)

I will have another look at the wording asap.

@ShadowBB

However that makes little sense because if they are not ambiguous when seen in context that doesn't mean that they are clear without context right?

I think the point here is that if I created a page with nothing but a link that reads "Click here", it is not an accessibility issue, and thus not a violation of success criterion 2.4.9, because it gives the same (poor) experience to everyone.
And I guess it doesn't just have to be a poor experience, but could also be game-like or artsy.

@carlosapaduarte and @ShadowBB, I gave a shot at a rewrite. Please have a look again.

Oh! I totally interpreted that the other way around.

You new writeup makes this a lot more clear and I agree with it wholeheartedly now! Nice work!

carlosapaduarte · 2019-04-24T22:03:06Z

_rules/6cbcbe.md

+
+#### Passed example 6
+
+Pages contain different amounts of information and/or differently worded information, but fulfils the same purpose in relation to the link:


fulfils > fulfil

carlosapaduarte · 2019-04-24T22:03:55Z

_rules/6cbcbe.md

+
+#### Passed example 8
+
+Links created via scripting with explicit role of link, but leads to the same resource: 


leads > lead

carlosapaduarte · 2019-04-24T22:06:25Z

_rules/6cbcbe.md

+
+#### Failed example 3
+
+Links created via scripting with explicit role of link, but leads to different resources that offer different content: 


leads > lead

Additionally, if you drop the first "different" it might improve readability

carlosapaduarte · 2019-04-24T22:09:24Z

_rules/6cbcbe.md

+
+#### Failed example 5
+
+A set of two SVG `<a>` elements have the same accessible name but links to different resources:


links > link

carlosapaduarte · 2019-04-24T22:16:47Z

_rules/6cbcbe.md

+
+#### Inapplicable example 2
+
+No identical link texts:


What about
Links with different accessible names

ShadowBB

This rule looks good apart from an unclear assumption. I am going to approve it because if the assumption means what I think it means it is technically correct but I would advise making it clearer.

ShadowBB · 2019-04-29T07:27:00Z

_rules/6cbcbe.md

+
+## Assumptions
+
+This rule assumes that the purpose of the links with identical names would not be ambiguous to users in general when seen in context on the web page, as users of assistive technologies in this case is not at a disadvantage when viewing the link out of context, e.g. on a list of links in a screen reader.


EDIT: nvm it is all cleared up now. Approved.

Changes implemented. Please review again.

carlosapaduarte

The assumption is now perfectly clear 👍

annethyme · 2019-04-30T11:36:58Z

Sent out to the ACT Rules Community through public-act-r@w3.org:

This is the FINAL CALL for the new rule "Links with identical accessible names serve equivalent purpose", #220.

The final call for this rule will end on May 14.
If you have any objections to the rule please raise them before this date.

We also encourage proceeding with implementations during the final call phase.

_rules/6cbcbe.md

@@ -0,0 +1,280 @@
+---
+id: b20e66


WilcoFiers · 2019-05-10T10:13:36Z

_rules/6cbcbe.md

+### Expectation
+
+When followed, the links in each set of target elements resolve to the [same resource](#same-resource) or to [equivalent resources](#equivalent-purpose).
+Resolving the links includes potential redirects, if the redirects happen instantly.


This seems like it should be a note. Either add a new line between the two paragraphs, or put them on the same line.

Removed the break between the two paragraphs. Is that enough to satisfy your feedback?

If we move it into a note, it will be informative, and it shouldn't be. It's part of what makes the expectation.

In that case yeah, remove the line break. Either have something on the same line, or have an empty line between.

WilcoFiers · 2019-05-10T10:26:14Z

pages/algorithms/equivalent-resource.md

+* contain different amounts of information and/or differently worded information
+* use different layouts.
+
+If all resources cover the user's expectations created by e.g. the link name equally well, the resources are considered to be equivalent. 


I don't think you can use "e.g." in the middle of a sentence like this. I think this sentence is a little confusing. I've tried to come up with an alternative, but I'm struggling even trying to understand what you are saying here. It sounds like whether or not something is an equivalent resource depends on the link to that resource? I'm not sure that's how it works.

Moved the "e.g. the link name" into a note instead:

Note: The user's expectations for the resource can be formed by different things, e.g. the name of the link leading to the resource, with or without the context around the link. This depends on the accessibility requirement that is tested.

Does this work for you?

Updated

Anne Thyme added 3 commits August 20, 2018 16:23

Create SC2-4-9-links-with-identical-accessible-names-have-same-purpos…

1709582

…e.md #210

Update SC2-4-9-links-with-identical-accessible-names-have-same-purpos…

33b71ec

…e.md Updated test cases to involve scripted links

Create index.html

1a071d1

Test assets for PR #220

annethyme mentioned this pull request Aug 21, 2018

New Rule: SC2-4-9-links-with-identical-accessible-names-have-same-purpose #210

Closed

annethyme self-assigned this Aug 27, 2018

jeeyyy added the reviewer wanted label Sep 4, 2018

jeeyyy reviewed Sep 4, 2018

View reviewed changes

jeeyyy previously requested changes Sep 4, 2018

View reviewed changes

annethyme changed the title ~~Rule: SC2-4-9-links-with-identical-accessible-names-have-same-purpose.md~~ SC2-4-9-links-with-identical-accessible-names-have-same-purpose Sep 10, 2018

annethyme added the Rule Use this label for a new rule that does not exist already label Sep 10, 2018

Brynanders mentioned this pull request Sep 13, 2018

SC1-1-1-placeholder-text-is-valid-accessible-name #251

Closed

Update SC2-4-9-links-with-identical-accessible-names-have-same-purpos…

f849efa

…e.md Addressing Jey's comments

annethyme pushed a commit that referenced this pull request Sep 14, 2018

Update accessible-name.md

09edbd3

Adding new paragraph on comparing acc names, that has so far been note in these rules: https://auto-wcag.github.io/auto-wcag/rules/SC2-5-3-label-content-name-mismatch.html #220 #251

annethyme mentioned this pull request Sep 14, 2018

Update definition of "accessible name" #254

Merged

6 tasks

ShadowBB previously approved these changes Sep 18, 2018

View reviewed changes

WilcoFiers added the september-agenda label Sep 19, 2018

fix: Add new glossary - url normalisation

ab30e98

annethyme requested a review from nitedog September 24, 2018 09:16

jeeyyy mentioned this pull request Sep 24, 2018

URL normalization #211

Closed

nitedog reviewed Sep 24, 2018

View reviewed changes

Update 6cbcbe.md

a945766

jeeyyy changed the base branch from master to develop April 12, 2019 11:39

jeeyyy mentioned this pull request Apr 18, 2019

New Rule: identical-links-same-purpose dequelabs/axe-core#1505

Closed

audreymaniez reviewed Apr 19, 2019

View reviewed changes

audreymaniez approved these changes Apr 19, 2019

View reviewed changes

tabindex="0" added to spans with role=link

92ec5c9

DagfinnRomen approved these changes Apr 23, 2019

View reviewed changes

carlosapaduarte previously requested changes Apr 24, 2019

View reviewed changes

ShadowBB approved these changes Apr 29, 2019

View reviewed changes

Anne Thyme added 4 commits April 29, 2019 13:24

Editorial cleanup

0c92ddf

Test case descr.: "Link text" > "accessible name"

95244c5

Grammar corrections and editorials

0f70f35

Update assumption for readability/understanding

7898973

annethyme requested a review from carlosapaduarte April 29, 2019 14:04

carlosapaduarte approved these changes Apr 30, 2019

View reviewed changes

annethyme requested a review from Brynanders April 30, 2019 11:25

annethyme added the Review call 2 weeks Call for review for new rules and big changes label Apr 30, 2019

Add id to frontmatter of rule

694499b

ShadowBB approved these changes May 2, 2019

View reviewed changes

WilcoFiers previously requested changes May 10, 2019

View reviewed changes

Anne Thyme added 3 commits May 14, 2019 10:41

Update template to match new format

15a1c03

Removed new line in Expectation

4fc8044

Moved example into a note

fbc10f8

jeeyyy requested a review from WilcoFiers May 15, 2019 08:17

annethyme merged commit 277acfd into develop May 15, 2019

annethyme deleted the SC2-4-9-links-with-identical-accessible-names-have-same-purpose branch May 15, 2019 14:45


		The rule applies to any two or more HTML or SVG elements that have the [semantic role](#semantic-role) of link, are [exposed to assistive technologies](#exposed-to-assistive-technologies) and that have the same [accessible name](#accessible-name).

		Note: Leading and trailing whitespace and difference in case sensitivity should be ignored when deciding whether the [accessible names](#accessible-name) are the same.


		### Expectation

		For each set of target elements, activating the links resolves, after any redirects, to resources that fulfil the same purpose in relation to the purpose indicated by the [accessible names](#accessible-name) of the link.


		## Assumptions

		* This rule assumes that the purpose of the links for links with identical link texts would not be ambiguous to users in general, which is the exception mentioned in the success criterion 2.4.9 Link Purpose (Link Only).


		Note: If the same content is presented in different formats, the format itself is often part of the link purpose, e.g. an article as both HTML and PDF.

		Note: If the [normalized](#url-normalisation) value of the ´href´ is identical, the resources are identical, thus fulfilling the same purpose. [Relative URLs](https://www.w3.org/TR/WD-html40-970917/htmlweb.html#relative-urls) first need to be resolved to full URLs before doing the comparison.


		Non-identical resources can still be equivalent by equally complying to the expectation formed by the user when navigating to them, thus serving an equivalent purpose. This would usually involve that the advertised key content is the same.

		Web pages and documents (e.g. PDFs, office formats etc.) may fulfil be equivalent resources, even if the resources:


		### Applicability

		This rule applies to any set of any two or more HTML or SVG elements that have the [semantic role](#semantic-role) of `link`, or a role that inherits from the `link` role, are [included in the accessibility tree](#included-in-the-accessibility-tree), and that have [matching](#matching-characters) [accessible names](#accessible-name) that does not only consist of [whitespace](#whitespace).


		## Assumptions

		This rule assumes that the purpose of the links with identical names would not be ambiguous to users in general when seen in context on the web page, as users of assistive technologies in this case is not at a disadvantage when viewing the link out of context, e.g. on a list of links in a screen reader.


		#### Passed example 6

		Pages contain different amounts of information and/or differently worded information, but fulfils the same purpose in relation to the link:


		#### Passed example 8

		Links created via scripting with explicit role of link, but leads to the same resource:


		#### Failed example 3

		Links created via scripting with explicit role of link, but leads to different resources that offer different content:


		#### Failed example 5

		A set of two SVG `<a>` elements have the same accessible name but links to different resources:

New Rule: Links with identical accessible names serve equivalent purpose #220

New Rule: Links with identical accessible names serve equivalent purpose #220

Uh oh!

Conversation

annethyme commented Aug 20, 2018

Reviewer checks

How to Review And Approve

Uh oh!

ShadowBB commented Aug 24, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jeeyyy left a comment

Choose a reason for hiding this comment

Uh oh!

annethyme commented Sep 14, 2018

Uh oh!

ShadowBB commented Sep 18, 2018

Uh oh!

jeeyyy commented Sep 24, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

audreymaniez left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carlosapaduarte left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShadowBB Apr 29, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ShadowBB Apr 29, 2019 •

edited

Loading

ShadowBB Apr 29, 2019 •

edited

Loading