Update Links with identical accessible names and context serve equivalent purpose rule #2007
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -233,6 +233,7 @@ | |
| - focusability | ||
| - unitless | ||
| - luminance | ||
| - disambiguated | ||
|
|
||
| # Parts of Unicode | ||
| - 000A | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -16,13 +16,18 @@ accessibility_requirements: | |
| failed: not satisfied | ||
| passed: further testing needed | ||
| inapplicable: further testing needed | ||
| wcag20:1.1.1: # Non-text Content (A) | ||
| secondary: This success criterion is mapped as a Secondary requirement because the SC applies only to non-text content. When links have visual information as context, a failed outcome for this rule may result in SC 1.1.1 Non-text Content being not satisfied. | ||
| wcag20:1.3.1: # Info and Relationships (A) | ||
| secondary: This success criterion is mapped as a Secondary requirement because the SC applies to information and relationships conveyed through presentation. When links rely on visual cues for conveying information and/or relationships, and these cues are not programmatically determined or available in text, a failed outcome for this rule may result in SC 1.3.1 Info and Relationships being not satisfied. | ||
|
There was a problem hiding this comment. This should follow the format for secondary requirements. Please have a look at the design doc. |
||
| input_aspects: | ||
| - DOM Tree | ||
| - CSS Styling | ||
| - Language | ||
| acknowledgments: | ||
| authors: | ||
| - Carlos Duarte | ||
| - Giacomo Petri | ||
| previous_authors: | ||
| - Anne Thyme Nørregaard | ||
| funding: | ||
|
|
@@ -42,21 +47,25 @@ This rule applies to any set of two or more [HTML or SVG elements][] for which a | |
| - the elements are in the same [web page (HTML)][]; and | ||
| - the elements are [included in the accessibility tree][included in the accessibility tree]; and | ||
| - the elements have [matching][] [accessible names][accessible name] that are not empty (`""`); and | ||
| - the elements have the same [programmatically determined link context][]. | ||
|
|
||
| **Note:** The test target for this rule is the full set of link elements that share the same [matching][] [accessible name][] and [programmatically determined link context][]. | ||
|
|
||
| ## Expectation | ||
|
|
||
| For each pair of links in each target set, one of the following is true: | ||
|
|
||
| - both links resolve to the [same resource][]; or | ||
| - both links resolve to [equivalent resources][equivalent resource]; or | ||
| - there is no visual information within the content of the page to let users know that both links resolve to [non-equivalent resources][equivalent resource]. | ||
|
There was a problem hiding this comment. I'm not keen on this "content of the page" phrase. At the very least this should link to our web page (HTML) definition. Better would be if we had a definition of "content", but I'm okay opening a separate issue for that and merging this PR. We have that problem in a few other rules too. |
||
|
|
||
| **Note**: Resolving the links includes potential redirects, if the redirects happen instantly. | ||
|
|
||
| ## Assumptions | ||
|
|
||
| - This rule assumes that, within the context of the test subject, the description provided by the [accessible name][] of a link can only accurately describe one resource (notably, homonyms alone are not used as link names). Thus, if two or more links have the same [accessible name][] but resolve to different resources, at least one of them does not accurately describe its purpose. | ||
|
There was a problem hiding this comment. This is pretty difficult to read, would you mind trying to simplify the language of these? There was a problem hiding this comment. I'm happy to make those changes, but the existing content is currently structured this way.
|
||
| - This rule assumes that assistive technologies are exposing all links on the page in the same way no matter which [document tree](https://dom.spec.whatwg.org/#document-trees) they are in. If an assistive technology requires the user to "enter" an `iframe` or a [shadow tree][] before exposing its links, then it is possible for two links to have identical name and context but resolve to different resources without failing [Success Criterion 2.4.4 Link Purpose (In Context)][sc244] (if said links are in separate [documents][document] or [shadow trees][shadow tree]). | ||
| - This rule assumes that reading the URL, such as from the status bar when the link is focused, is not considered part of the context, and therefore, it does not disambiguate links. | ||
|
|
||
| ## Accessibility Support | ||
|
|
||
|
|
@@ -68,10 +77,17 @@ This rule is designed specifically for [2.4.4 Link Purpose (In Context)][sc244], | |
|
|
||
| There is a difference between two contexts being the *same* and being *identical*. This rule specifically targets links within the *same* context. The same context means exactly the same set of DOM nodes. Identical (but not the same) contexts might have a different set of DOM nodes, but those DOM nodes have equivalent content - such as text content, attribute values, and so on. This difference is similar to the difference in some programming languages between pointer equivalence and deep object equivalence. Links with identical name that are in identical (but not the same) contexts also fail [2.4.4 Link Purpose (In Context)][sc244]. However, defining "identical context" unambiguously has been deemed infeasible at this time, and so has been left out of this rule. | ||
|
|
||
| Links that are [ambiguous to users in general](https://www.w3.org/TR/WCAG21/#dfn-ambiguous-to-users-in-general) are covered by the exception mentioned in Success Criterion 2.4.4 Link Purpose (In Context). If the links are ambiguous to users in general, users of assistive technologies are not at a disadvantage when viewing the links, which makes it more of a general user experience concern than an accessibility issue. | ||
giacomo-petri marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Pages with links that are not [ambiguous to users in general][], but are ambiguous to some users are likely to fail [success criterion 1.3.1 Info and Relationships][sc131] if the disambiguation information is conveyed through presentation, but not semantically. Moreover, when this information is non-text content, such a page is likely to fail [success criterion 1.1.1 Non-text Content][sc111]. Therefore, both these success criteria are secondary requirement for this rule. | ||
|
|
||
| ### Bibliography | ||
|
|
||
| - [Understanding Success Criterion 2.4.4: Link Purpose (In Context)](https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-in-context.html) | ||
| - [HTML Specification - URL parsing](https://html.spec.whatwg.org/#resolving-urls) | ||
| - [Ambiguous to users in general](https://www.w3.org/TR/WCAG21/#dfn-ambiguous-to-users-in-general) | ||
giacomo-petri marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - [Understanding Success Criterion 1.1.1: Non-text Content](https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html) (secondary requirement) | ||
giacomo-petri marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - [Understanding Success Criterion 1.3.1: Info and Relationships](https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html) (secondary requirement) | ||
giacomo-petri marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## Test Cases | ||
|
|
||
|
|
@@ -213,11 +229,9 @@ These two SVG `a` and HTML `a` elements have the same [accessible name][], same | |
| </html> | ||
| ``` | ||
|
|
||
| #### Passed Example 9 | ||
|
|
||
| These two HTML `a` elements have the same [accessible name][] and [context][programmatically determined link context], but resolve to different resources. However, the purpose of these links is [ambiguous to users in general](https://www.w3.org/TR/WCAG21/#dfn-ambiguous-to-users-in-general). Thus all readers are unsure about the destination and the person with a disability is not at any disadvantage. | ||
giacomo-petri marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ```html | ||
| <html lang="en"> | ||
|
|
@@ -229,80 +243,124 @@ These two HTML `a` elements have the same [accessible name][] and [context][prog | |
| </html> | ||
| ``` | ||
|
|
||
| ### Failed | ||
|
|
||
| #### Failed Example 1 | ||
|
There was a problem hiding this comment. I'm reluctant to add this example TBH. This is first and foremost a 1.1.1 issue. Informative images are missing a text alternative. I think that this then results in a 2.4.4 failure is kind of incidental. In the same way that putting aria-hidden on the text of a link makes it a 1.3.1 issue, but that then also fits under 2.4.4. This feels a bit more like a "gotcha" test case for tools than something that actually adds something important edge case. Even if we do keep the example I would prefer not to see it as the first one, as its far from the most obvious failure you can see get under this criterion. There was a problem hiding this comment. I'm fine moving the example below, but I don't agree that the 2.4.4 is "incidental" here. If we have an empty link due to child image with empty alt attribute such as:
the empty link is still failing 2.4.4. Of course it's "incidental" to the empty alt attribute and the image is failing 1.1.1, but both the issues are valid and should be triggered by tools. There was a problem hiding this comment. I don't mind having one or two examples of images in here. I don't think the examples should be exclusively about images. The far more common scenario is with just link text. I think the examples we had before did a better job of demonstrating that problem than the new examples do. There was a problem hiding this comment. Suggested failure examples without images: <p>W3C pages for ACT:</p>
<p><a href="//">ACT Rules</a></p>
<p>Community group for ACT:</p>
<p><a href="//Different">ACT Rules</a></p><p>
To reach us you can <a href="">Contact</a> us via e-mail, or <a href="">contact</a> us on Facebook.
</p> |
||
|
|
||
| These two HTML `a` elements have the same [accessible name][] and [context][programmatically determined link context]. They are visually distinguishable thanks to the relationships conveyed through CSS, but go to different resources. | ||
|
|
||
| ```html | ||
| <html lang="en"> | ||
| <p> | ||
| <h2>Contact us:</h2> | ||
| <a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/contact-us.html?page=1" style="display:inline-block; background: url(/test-assets/shared/chat.png) 0 / 40px no-repeat; padding: 20px 0 20px 50px;">Contact Us</a> | ||
| <a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/contact-us.html?page=2" style="display:inline-block; background: url(/test-assets/shared/phone.png) 0 / 40px no-repeat; padding: 20px 0 20px 50px; margin-left: 40px;">Contact Us</a> | ||
|
Comment on lines
+269
to
+270
There was a problem hiding this comment. These resolve to the same page with a different URL. That's not a failure of this rule. Same for other examples this PR adds. There was a problem hiding this comment. They are not the same resource. This is the content of page 1: and this is the content of page 2: There was a problem hiding this comment. I don't think this needs to be an HTML page that changes based on the query string. Actually having two HTML files would be better. There is nothing in this rule that requires a tester to compare the query string of two resources. So having an example that checks that you do that feels to me like a disconnect between what we say needs to be tested, and how we in practice want people to test. I don't think these examples are wrong, but they're not quite right either. They have a complexity to them which they either don't need, or which hint that we don't think this rule is tested in the way we say it is. Neither of which is quite right I think. There was a problem hiding this comment. Talked to @giacomo-petri. @Jym77 can we put this topic on the agenda of an upcoming meeting? |
||
| </p> | ||
| </html> | ||
| ``` | ||
Jym77 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| #### Failed Example 2 | ||
|
|
||
| These two HTML `a` elements have the same [accessible name][] and [context][programmatically determined link context], but go to different resources. Their purpose is disambiguated for sighted users by the alignment of the links with the images above. | ||
|
There was a problem hiding this comment. Kinda similar to the previous case, I feel this is primarily a reading order failure. There was a problem hiding this comment. I don't totally agree. If you fix the reading sequence it does not guarantee that these links will pass 2.4.4 The reading sequence is now correct, but it's still failing 2.4.4 |
||
|
|
||
| ```html | ||
| <html lang="en"> | ||
| <div> | ||
| <span style="text-align:center;">Contact us</span> | ||
| <span style="display:flex; justify-content:space-around;"> | ||
| <img src="/test-assets/shared/chat.png" alt="Chat" style="width:50%;"> | ||
| <img src="/test-assets/shared/phone.png" alt="Phone" style="width:50%;"> | ||
| </span> | ||
| <span style="display:flex; justify-content:space-around;"> | ||
| <a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/contact-us.html?page=60e950cff70bf1ec60a702086748ab4dec361514">Contact Us</a> | ||
| <a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/contact-us.html?page=c1d4e0f067462f4b28716f028d9213a25eb82f28">Contact Us</a> | ||
| </span> | ||
| </div> | ||
| </html> | ||
| ``` | ||
|
|
||
| #### Failed Example 3 | ||
|
|
||
| These two HTML `a` elements have the same [accessible name][] and [context][programmatically determined link context]. They link to web pages that are similar, but have different information in their content. Their purpose is disambiguated for sighted users by the alignment of the links with the images above. | ||
|
|
||
| ```html | ||
| <html lang="en"> | ||
| <div> | ||
| <span style="text-align:center;">Contact us</span> | ||
| <span style="display:flex; justify-content:space-around;"> | ||
| <img src="/test-assets/shared/chat.png" alt="Chat" style="width:50%;"> | ||
| <img src="/test-assets/shared/phone.png" alt="Phone" style="width:50%;"> | ||
| </span> | ||
| <span style="display:flex; justify-content:space-around;"> | ||
| <a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/contact-us.html?page=3">Contact Us</a> | ||
| <a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/contact-us.html?page=4">Contact Us</a> | ||
| </span> | ||
| </div> | ||
| </html> | ||
| ``` | ||
|
There was a problem hiding this comment. I'm not sure I remember why we kept both example 2 and 3 😓 There was a problem hiding this comment.
This distinction was already present at the time of the edits, so I kept it also for the new adjustments. If it's not necessary we can remove it. There was a problem hiding this comment. Ah, yes, thanks for the refresh. There was a problem hiding this comment. @Jym77, There was a problem hiding this comment. Let's see if others have opinions about it 😃 |
||
|
|
||
| #### Failed Example 4 | ||
|
|
||
| These two HTML `span` elements have an [explicit role][] of link, same [accessible name][] and [context][programmatically determined link context], but link to resources that offer different content. Their purpose is disambiguated for sighted users by the alignment of the links with the images above. | ||
|
|
||
| ```html | ||
| <html lang="en"> | ||
| <div> | ||
| <span style="text-align:center;">Contact us</span> | ||
| <span style="display:flex; justify-content:space-around;"> | ||
| <img src="/test-assets/shared/chat.png" alt="Chat" style="width:50%;"> | ||
| <img src="/test-assets/shared/phone.png" alt="Phone" style="width:50%;"> | ||
| </span> | ||
| <span style="display:flex; justify-content:space-around;"> | ||
| <span | ||
| role="link" | ||
| tabindex="0" | ||
| onclick="location='/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/contact-us.html?page=1'">Contact Us</span> | ||
| <span | ||
| role="link" | ||
| tabindex="0" | ||
| onclick="location='/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/contact-us.html?page=2'">Contact Us</span> | ||
| </span> | ||
| </div> | ||
| </html> | ||
| ``` | ||
|
|
||
| #### Failed Example 5 | ||
|
|
||
| These two SVG `a` elements have the same [accessible name][] and [context][programmatically determined link context] but link to different resources. | ||
|
|
||
| ```html | ||
| <html lang="en"> | ||
| <p> | ||
| <svg enable-background="new 0 0 264 120" viewBox="0 -20 264 140" xmlns="http://www.w3.org/2000/svg"> | ||
| <text>Contact us</text> | ||
| <a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/contact-us.html?page=1" aria-label="Contact Us"> | ||
| <path d="m212.0806 68.0717c-10.3917 10.3852-22.4311 20.3239-27.1905 15.5646-6.8075-6.8075-11.0088-12.7418-26.0285-.6696-15.0132 12.0657-3.4792 20.1139 3.1182 26.7047 7.6149 7.6149 36.0001.407 64.0571-27.6434 28.0504-28.057 35.2386-56.4422 27.6172-64.0571-6.5974-6.604-14.6062-18.1314-26.6719-3.1182-12.0723 15.0132-6.1444 19.2145.6761 26.0285 4.7397 4.7593-5.1925 16.7988-15.5777 27.1905z"/> | ||
| </a> | ||
| <a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/contact-us.html?page=2" aria-label="Contact Us"> | ||
Jym77 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| <path d="m105 7.5h-90c-8.2576 0-15 6.7497-15 15v52.5c0 8.2498 6.7424 15 15 15h30l30 22.5v-22.5h30c8.2498 0 15-6.7502 15-15v-52.5c0-8.2503-6.7502-15-15-15zm-80.7903 52.5c-6.2132 0-11.255-5.0372-11.255-11.25 0-6.2132 5.0418-11.25 11.255-11.25 6.2128 0 11.245 5.0418 11.245 11.25 0 6.2077-5.0322 11.25-11.245 11.25zm35.7953 0c-6.2128 0-11.255-5.0372-11.255-11.25 0-6.2132 5.0423-11.25 11.255-11.25 6.2132 0 11.245 5.0368 11.245 11.25 0 6.2128-5.0317 11.25-11.245 11.25zm35.7958 0c-6.2132 0-11.2555-5.0372-11.2555-11.25 0-6.2132 5.0423-11.25 11.2555-11.25 6.2128 0 11.2445 5.0368 11.2445 11.25 0 6.2128-5.0318 11.25-11.2445 11.25z"/> | ||
| </a> | ||
| </svg> | ||
| </p> | ||
| </html> | ||
| ``` | ||
|
|
||
| #### Failed Example 6 | ||
|
|
||
| These two HTML `a` elements with the same [accessible name][] and [context][programmatically determined link context] resolve to the [same resource][] after redirect, but the redirect is not instant. | ||
|
|
||
| ```html | ||
| <html lang="en"> | ||
| <p> | ||
| <span style="text-align:center;">Contact us</span> | ||
| <span style="display:flex; justify-content:space-around;"> | ||
| <img src="/test-assets/shared/chat.png" alt="Chat" style="width:50%;"> | ||
| <img src="/test-assets/shared/phone.png" alt="Phone" style="width:50%;"> | ||
| </span> | ||
| <span style="display:flex; justify-content:space-around;"> | ||
| <a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/index.html">Contact Us</a> | ||
| <a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/redirect1.html">Contact Us</a> | ||
| </span> | ||
| </p> | ||
| </html> | ||
| ``` | ||
|
|
@@ -398,8 +456,23 @@ These two HTML `a` elements have the same [accessible name][] but different [pro | |
| <div><a href="https://www.w3.org/International/">Read more</a> about the W3C internationalization</div> | ||
| ``` | ||
|
|
||
| #### Inapplicable Example 7 | ||
|
|
||
| These two HTML `a` elements have the same [accessible name][] and [context][programmatically determined link context], but the second one is not [included in the accessibility tree][included in the accessibility tree]. | ||
|
|
||
| ```html | ||
| <html lang="en"> | ||
| <p> | ||
| We are on social media: | ||
| <a href="https://act-rules.github.io/">ACT rules</a> | ||
| <a aria-hidden="true" href="https://www.w3.org/community/act-r/">ACT rules</a> | ||
WilcoFiers marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| </p> | ||
| </html> | ||
| ``` | ||
|
|
||
| [accessible name]: #accessible-name 'Definition of accessible name' | ||
| [document]: https://dom.spec.whatwg.org/#concept-document 'Definition of document' | ||
| [equivalent resource]: #equivalent-resource 'Definition of Equivalent Resource' | ||
| [explicit role]: #explicit-role 'Definition of explicit role' | ||
| [included in the accessibility tree]: #included-in-the-accessibility-tree 'Definition of included in the accessibility tree' | ||
| [inheriting semantic]: #inheriting-semantic 'Definition of Inheriting Semantic Role' | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I understand why you added 1.3.1 in here. Do any of the failed examples fail 1.3.1 in your opinion? I didn't think so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main idea behind is that if two links have identical acc name and context they should, in most cases, appear ambiguous to users in general.
But due to their "context" (not the programmatic one), that for example might include a wrong structure, background images that convey supplementary information, etc., they are not.
This "context" provides information and relationships through presentation. Consequently, I have included SC 1.3.1 here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this needs to have 1.3.1 / 1.1.1 in here any more than the link has accessible name rule does. Sure if 1.1.1 fails you might also fail 2.4.4 but it's entirely possible to for an image with a link in it to pass 1.1.1 and fail 2.4.4 and vice versa. That's not the case for something like an image button which always fails both 1.1.1 and 4.1.2, or something like a 2:1 text contrast which always fails both 1.4.3 and 1.4.5.
Rule of thumb here is if you can separate them, it's not a secondary requirement. There has to be some element for which its not possible to fail one without failing the other SC, or to pass one without passing the other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed. These should be removed.