Links with identical accessible names serve equivalent purpose

  • Rule Typeatomic
  • Rule ID: b20e66
  • Last modified: Aug 21, 2019
  • Accessibility Requirements Mapping
    • 2.4.9 Link Purpose (Link Only) (Level: AAA)
      • Learn More about 2.4.9 (Link Purpose (Link Only))
      • Required for conformance to WCAG 2.0 and above on level AAA and above
      • Outcome mapping:
        • Any failed outcomes: not satisfied
        • All passed outcomes: further testing is needed
        • An inapplicable outcome: further testing is needed
  • Input Aspects


This rule checks that links with identical accessible names resolve to the same resource or equivalent resources.


This rule applies to any set of any two or more HTML or SVG elements that have the semantic role of link, or a role that inherits from the link role, are included in the accessibility tree, and that have matching accessible names that do not only consist of whitespace.

Note: The test target for this rule is the full set of link elements that share the same matching accessible name.


When followed, the links in each set of target elements resolve to the same resource or to equivalent resources. Resolving the links includes potential redirects, if the redirects happen instantly.


This rule assumes that the purpose of the links with identical accessible names would not be ambiguous to users in general when seen in context on the web page, which is the exception mentioned in success criterion 2.4.9 Link Purpose (Link Only). If the links are ambiguous to users in general, users of assistive technologies are not at a disadvantage when viewing the links out of context, e.g. on a list of links in a screen reader, which makes it more of a general user experience concern than an accessibility issue.

Accessibility Support

There are no major accessibility support issues known for this rule.


Test Cases


Passed Example 1

A set of two HTML <a> elements have the same accessible name and link to the same resource.

<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/index.html">Contact us</a>

Passed Example 2

Links resolves to same resource after instant redirect:

<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/redirect.html">Contact us</a>

Passed Example 3

Resources are not the same, since the links resolve to different URLs, but the resources are completely identical, thus serving the same purpose:

<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/index-copy.html">Contact us</a>

Passed Example 4

Same link text used for links going to pages where the content section is the same, but where the navigation options (bread crumbs and local sub menus) differ due to different placement in navigation hierarchy:

<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/about/contact.html">Contact us</a>
<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/careers/contact.html">Contact us</a>

Passed Example 5

URLs differ due to trailing slashes, but resolves to the same resource after redirects caused by user agent:

<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/">Contact us</a>
<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66">Contact us</a>

Passed Example 6

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

<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/page1.html">Call us</a>
<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/page2.html">Call us</a>

Passed Example 7

Pages have the same advertised key content but use different layouts:

<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/page1.html">Contact us</a>
<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/page3.html">Contact us</a>

Passed Example 8

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

	Link text

	Link text

Passed Example 9

A set of two SVG <a> elements have the same accessible name and link to the same resource.

<svg viewBox="0 0 100 100" xmlns="" xmlns:xlink="">
	<a href="" aria-label="Follow us">
		<circle cx="50" cy="40" r="35" />

	<a href="">
		<text x="50" y="90" text-anchor="middle">
			Follow us


Failed Example 1

Same accessible name used for links going to different resources:

<a href="">Follow us</a> <a href="">Follow us</a>

Failed Example 2

Same accessible name used for links going to web pages that are similar, but have different information in their content:

<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/about/contact.html">Contact us</a>
<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/admissions/contact.html">Contact us</a>

Failed Example 3

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

	Link text

	Link text

Failed Example 4

Same accessible name used for image links going to different resources:

<a href=""><img src="facebook.jpg" alt="Follow us"/></a>
<a href=""><img src="twitter.jpg" alt="Follow us"/></a>

Failed Example 5

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

<svg viewBox="0 0 100 100" xmlns="" xmlns:xlink="">
	<a href="" aria-label="Follow us">
		<circle cx="50" cy="40" r="35" />

	<a href="">
		<text x="50" y="90" text-anchor="middle">
			Follow us

Failed Example 6

Links resolves to same resource after redirect, but the redirect is not instant:

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


Inapplicable Example 1

´a´ and ´area´ elements without ´href´ attribute:

<a>Link text</a> <area aria-label="Link text" />

Inapplicable Example 2

Links with different accessible names:

<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/about/contact.html"
	>Contact main office</a
<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/admissions/contact.html"
	>Contact admissions office</a

Inapplicable Example 3

Link is not included in the accessibility tree:

	>Contact Us</a
<a href="/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/pabe2.html">Contact Us</a>

Inapplicable Example 4

Links created via scripting, but without the semantic role of link:

<span onclick="location='/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/page1.html'">
	Contact Us

<span onclick="location='/test-assets/links-with-identical-names-serve-equivalent-purpose-b20e66/page2.html'">
	Contact Us

Inapplicable Example 5

Links do not have accessible names:

<a href=""></a> <a href=""></a>

Inapplicable Example 6

Image links do not have accessible names:

<a href=""><img src="facebook.jpg"/></a> <a href=""><img src="twitter.jpg"/></a>


Accessible Name

key: accessible-name

The programmatically determined name of a user interface element that is included in the accessibility tree.

The accessible name is calculated using the accessible name and description computation.

For native markup languages, such as HTML and SVG, additional information on how to calculate the accessible name can be found in HTML Accessibility API Mappings 1.0, Accessible Name and Description Computation (work in progress) and SVG Accessibility API Mappings, Name and Description (work in progress).

Equivalent resource

key: equivalent-resource

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 be equivalent resources, even if the resources:

  • are located on different URLs, including different domains
  • present different navigation options, e.g. through bread crumbs or local sub menus
  • contain different amounts of information and/or differently worded information
  • use different layouts.

If all resources cover the user's expectations equally well, the resources are considered to be equivalent.

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.

Note: If the same content is presented in different formats or languages, the format or language itself is often part of the purpose of the content, e.g. an article as both HTML and PDF, an image in different sizes, or an article in two different languages. If getting the same content in different formats or languages is the purpose of having seperate links, the resources are not equivalent.

Explicit Semantic Role

key: explicit-role

The explicit semantic role is the semantic role of an element set by its role attribute.

The role attribute takes a list of tokens. The explicit semantic role is the first valid role in this list. If none of the tokens are valid, the implicit semantic role will be used instead.

Non-abstract roles defined in the following specifications are considered valid:

Other roles may be added as they become available. Not all roles will be supported in all assistive technologies. Testers are encouraged to adjust which roles are allowed according to the accessibility support base line. For the purposes of executing test cases in all rules, it should be assumed that all roles are supported by assistive technologies so that none of the roles fail due to lack of accessibility support.

Acccessibility Support

Some browsers and assistive technologies treat the tokens of the role attribute as case-sensitive. Unless lowercase letters are used for the value of the role attribute, not all user agents will be able to interpret the tokens correctly. ARIA in HTML also specifies that authors must use lowercase letters for the role and aria-* attributes (work in progress).

Included in the accessibility tree

key: included-in-the-accessibility-tree

Elements included in the accessibility tree of platform specific accessibility APIs. Elements in the accessibility tree are exposed to assistive technologies, allowing users to interact with the elements in a way that meet the requirements of the individual user.

The general rules for when elements are included in the accessibility tree are defined in the core accessibility API mappings. For native markup languages, such as HTML and SVG, additional rules for when elements are included in the accessibility tree can be found in the HTML accessibility API mappings (work in progress) and the SVG accessibility API mappings (work in progress).

Note: Users of assistive technologies might still be able to interact with elements that are not included in the accessibility tree. An example of this is a focusable element with an aria-hidden attribute with a value of true. Such an element could still be interacted with using sequential keyboard navigation regardless of the assistive technologies used, even though the element would not be included in the accessibility tree.

Matching characters

key: matching-characters

A sequence of characters is considered to match another if, after removing leading and trailing space characters and replacing remaining occurrences of one or more space characters with a single space, the two sequences of characters are equal character-by-character, ignoring any differences in letter casing.


key: outcome

A conclusion that comes from evaluating an ACT Rule on a test subject or one of its constituent test target. An outcome can be one of the three following types:

  • Inapplicable: No part of the test subject matches the applicability
  • Passed: A test target meets all expectations
  • Failed: A test target does not meet all expectations

Note: A rule has one passed or failed outcome for every test target. When there are no test targets the rule has one inapplicable outcome. This means that each test subject will have one or more outcomes.

Note: Implementers using the EARL10-Schema can express the outcome with the outcome property. In addition to passed, failed and inapplicable, EARL 1.0 also defined an incomplete outcome. While this cannot be the outcome of an ACT Rule when applied in its entirety, it often happens that rules are only partially evaluated. For example, when applicability was automated, but the expectations have to be evaluated manually. Such "interim" results can be expressed with the incomplete outcome.

Same resource

key: same-resource

Two or more resources can be the same resource even though the URLs for them are different. This can be due to URL parsing, server settings, redirects and DNS aliasing.

If the parsed URLs for two resources are identical, the resources are the same resource.

Depending on the server, URLs can either be case-sensitive or case-insenstive, meaning that <a href="page1.html"> and <a href="Page1.html"> lead to either the same or two different pages.

Fully parsed URLs can be different, but still lead to the same resource after making the HTTP request, due to redirects and DNS aliasing. For example, these URLs are all fully normalised:,, The server can however be configured to serve the same site for http and https, and the same site for and This is common, but not guaranteed.

Some types of redirects are also caused by user agents, e.g. ensuring that and resolve to the same resource.

Semantic Role

key: semantic-role

A semantic role is a semantic association that indicates an object's type. This allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

The semantic role of an element is its explicit semantic role if it has any, otherwise, the implicit semantic role is used.


key: whitespace

Characters that have the Unicode "White_Space" property in the Unicode properties list.

This includes:

  • all characters in the Unicode Separator categories, and
  • the following characters in the Other, Control category:

    • Character tabulation (U+0009)
    • Line Feed (LF) (U+000A)
    • Line Tabulation (U+000B)
    • Form Feed (FF) (U+000C)
    • Carriage Return (CR) (U+000D)
    • Next Line (NEL) (U+0085)


Aug 21, 2019test: add tests to verify h4 headings (#810)
Aug 14, 2019feat: Define implicit/explicit role (4e8ab6, b20e66, c487ae, e086e5, 5c01ea) (#689)
Jul 19, 2019chore: run prettier (#688)
Jun 26, 2019Fix link to equivalent-resource definition in two rules (#612)
Jun 20, 2019chore: update test assets for rule - links with identical names serve equivalent purpose. (#583)
May 18, 2019chore: Validating rules frontmatter on CI (#551)
May 15, 2019New Rule: Links with identical accessible names serve equivalent purpose (#220)

Useful Links


Tool NameCreated ByReport
AlfaSiteimproveView Report