Skip to content
Open
Show file tree
Hide file tree
Changes from 6 commits
Commits
Show all changes
88 commits
Select commit Hold shift + click to select a range
aeafb90
invalid-form-field-value-36b590: updating failed example 2.
dan-tripp-siteimprove Apr 4, 2023
5a07973
Merge branch 'develop' into develop
Jym77 Apr 27, 2023
a75c7f8
Merge branch 'act-rules:develop' into develop
dan-tripp-siteimprove May 24, 2023
623d26e
Rule visible-label-in-accessible-name-2ee8b8: introducing a new "labe…
dan-tripp-siteimprove Jun 22, 2023
f920a47
Merge branch 'act-rules:develop' into develop
dan-tripp-siteimprove Jun 22, 2023
ee3e993
Merge remote-tracking branch 'origin/develop' into rule-2ee8b8-may-2023
dan-tripp-siteimprove Jun 22, 2023
75a9878
Merge branch 'act-rules:develop' into develop
dan-tripp-siteimprove Aug 17, 2023
81caf8a
Adding examples to rule presentational-children-no-focusable-content-…
dan-tripp-siteimprove Aug 17, 2023
2928be6
Merge remote-tracking branch 'upstream/develop' into develop
dan-tripp-siteimprove Oct 27, 2023
5cd8b2c
Merge branch 'develop' of https://github.com/dan-tripp-siteimprove/ac…
dan-tripp-siteimprove Oct 27, 2023
092c849
removing Passed Example 15 because it's a duplicate.
dan-tripp-siteimprove Nov 9, 2023
f499d04
- adding frontmatter. (I originally copied this definition from http…
dan-tripp-siteimprove Nov 9, 2023
473bcb8
editing example: WAVE -> WCAG
dan-tripp-siteimprove Nov 9, 2023
5c7fc1e
Update pages/glossary/visible-inner-text.md
dan-tripp-siteimprove Nov 9, 2023
3d3b657
Update pages/glossary/visible-inner-text.md
dan-tripp-siteimprove Nov 9, 2023
8ed61b8
adding mention of innerText
dan-tripp-siteimprove Nov 9, 2023
24d0ffc
- removing mention of "the rule" from label-in-name-algorithm.md . r…
dan-tripp-siteimprove Nov 9, 2023
46294dd
adding preamble to label-in-name-algorithm.md which mentions what thi…
dan-tripp-siteimprove Nov 9, 2023
a141df8
visible-inner-text definition: now normalizing whitespace in the defi…
dan-tripp-siteimprove Nov 15, 2023
5220766
visible-inner-text: replacing "ASCII whitespace" with "ASCII space ch…
dan-tripp-siteimprove Nov 15, 2023
b2df021
adding passed example due to review at https://github.com/act-rules/a…
dan-tripp-siteimprove Nov 15, 2023
cde4ad4
handling review thread https://github.com/act-rules/act-rules.github.…
dan-tripp-siteimprove Nov 15, 2023
83d0e10
Merge branch 'act-rules:develop' into develop
dan-tripp-siteimprove Nov 24, 2023
5dce8e1
fixing failing test __tests__/link-reference-has-definition.js
dan-tripp-siteimprove Dec 13, 2023
2cfe5f8
fixing failing test _rules/__tests__/testcase-html-hint.js
dan-tripp-siteimprove Dec 13, 2023
7cdf8c3
fixing failing tests in __tests__/spelling.js
dan-tripp-siteimprove Dec 13, 2023
563ff5e
fixing more failing tests in __tests__/spelling.js
dan-tripp-siteimprove Dec 13, 2023
53fe350
fixing more failing tests in __tests__/spelling.js
dan-tripp-siteimprove Dec 13, 2023
821de81
more fixing of failing test(s) in __tests__/spelling.js
dan-tripp-siteimprove Dec 13, 2023
f9e7272
adding glossary definition inlined section.
dan-tripp-siteimprove Feb 5, 2024
ae2273a
changing example to match kathy's recent merged PR
dan-tripp-siteimprove Feb 5, 2024
d4f8076
adding failed example to emphasize that a word in the middle will cau…
dan-tripp-siteimprove Feb 5, 2024
2dcd941
.
dan-tripp-siteimprove Feb 5, 2024
09f668c
Merge branch 'act-rules:develop' into develop
dan-tripp-siteimprove Feb 6, 2024
a37cfd3
Merge remote-tracking branch 'origin/develop' into rule-2ee8b8-may-2023
dan-tripp-siteimprove Feb 6, 2024
22ad17b
Fixing mistaken branch/merge.
dan-tripp-siteimprove Feb 6, 2024
2dc429f
fixing failing test spelling.js / retext-repeated-words
dan-tripp-siteimprove Feb 7, 2024
2ab4489
Adding some clarity to the algorithm's wording.
dan-tripp-siteimprove Feb 7, 2024
db37b3b
fixing failing test spelling.js
dan-tripp-siteimprove Feb 7, 2024
7b2a053
Visible inner text: handling some uncommon whitespace / visibility ca…
dan-tripp-siteimprove Apr 10, 2024
9723ed1
- adding assumption to handle spelling and hyphenation. because of h…
dan-tripp-siteimprove Jul 25, 2024
4da5300
Assumptions:
dan-tripp-siteimprove Sep 26, 2024
5617755
Merge branch 'develop' into rule-2ee8b8-may-2023
daniel-montalvo Feb 18, 2025
6be702c
Put back removed exceptions
daniel-montalvo Feb 18, 2025
0d4c543
Add missing exxception
daniel-montalvo Feb 18, 2025
a959b09
minor rewording. based on review.
dan-tripp-siteimprove Feb 19, 2025
f1219c8
Adding an assumption about round brackets and the human language. As…
dan-tripp-siteimprove Feb 24, 2025
f9850c8
Fixing typo.
dan-tripp-siteimprove Feb 24, 2025
b77023c
Update _rules/visible-label-in-accessible-name-2ee8b8.md
dan-tripp-siteimprove Mar 27, 2025
1baf1ee
Removing Failed Example 5 because it violates one of the rule's assum…
dan-tripp-siteimprove Jan 29, 2026
4afc39b
Minor wording change.
dan-tripp-siteimprove Jan 29, 2026
cd69eaf
Replacing some bullet points with a numbered list. because of PR re…
dan-tripp-siteimprove Jan 29, 2026
9490a5e
- moving clauses about spelling, hyphenation, and abbreviations from…
dan-tripp-siteimprove Feb 9, 2026
8ea29b6
Merge branch 'develop' into rule-2ee8b8-may-2023
daniel-montalvo Feb 10, 2026
903ee9d
adding an inapplicable example.
dan-tripp-siteimprove Mar 4, 2026
3818b0e
Merge branch 'rule-2ee8b8-may-2023' of https://github.com/dan-tripp-s…
dan-tripp-siteimprove Mar 4, 2026
1565733
Update _rules/visible-label-in-accessible-name-2ee8b8.md
dan-tripp-siteimprove Mar 4, 2026
ec6a50f
Update _rules/visible-label-in-accessible-name-2ee8b8.md
dan-tripp-siteimprove Mar 4, 2026
268e5ae
Update _rules/visible-label-in-accessible-name-2ee8b8.md
dan-tripp-siteimprove Mar 4, 2026
bac2432
Passed Example 8 - changing wording re: whitespace.
dan-tripp-siteimprove Mar 4, 2026
38f7d65
Merge branch 'rule-2ee8b8-may-2023' of https://github.com/dan-tripp-s…
dan-tripp-siteimprove Mar 4, 2026
cf1e791
Changing wording on failed example 15, 1 vs. 1a, because of discussio…
dan-tripp-siteimprove Mar 5, 2026
531bf52
removing from applicability "The element does not contain any [render…
dan-tripp-siteimprove Mar 5, 2026
1dc4453
adding to algorithm some clarity on string equality check. my idea.
dan-tripp-siteimprove Mar 5, 2026
60e5734
algorithm:
dan-tripp-siteimprove Apr 1, 2026
0b25658
Update _rules/visible-label-in-accessible-name-2ee8b8.md
dan-tripp-siteimprove Apr 16, 2026
07e2c27
Update _rules/visible-label-in-accessible-name-2ee8b8.md
dan-tripp-siteimprove Apr 16, 2026
99a88a6
Update _rules/visible-label-in-accessible-name-2ee8b8.md
dan-tripp-siteimprove Apr 16, 2026
b781366
Update _rules/visible-label-in-accessible-name-2ee8b8.md
dan-tripp-siteimprove Apr 16, 2026
774547e
Update pages/glossary/label-in-name-algorithm.md
dan-tripp-siteimprove Apr 16, 2026
a839498
minor tweaks
dan-tripp-siteimprove Apr 16, 2026
3586285
for language, now linking to whatwg definition.
dan-tripp-siteimprove Apr 16, 2026
84f2e2d
Update _rules/visible-label-in-accessible-name-2ee8b8.md
dan-tripp-siteimprove Apr 16, 2026
c01ccfa
passed example 8: rewording.
dan-tripp-siteimprove Apr 16, 2026
fd8029c
Passed Example 11: adding "fragment link" to visible-inner-text:for-t…
dan-tripp-siteimprove Apr 16, 2026
b50d890
fixing previous commit
dan-tripp-siteimprove Apr 16, 2026
6816e7b
fixing previous commit
dan-tripp-siteimprove Apr 16, 2026
dd9d7f1
tweaking previous commit
dan-tripp-siteimprove Apr 16, 2026
e0b890a
another tweak
dan-tripp-siteimprove Apr 17, 2026
b9460bf
another tweak
dan-tripp-siteimprove Apr 17, 2026
29e576b
Update _rules/visible-label-in-accessible-name-2ee8b8.md
dan-tripp-siteimprove Apr 18, 2026
5aa55e6
Passed Example 9: changing from p to div as per Jym's review.
dan-tripp-siteimprove Apr 18, 2026
901e0d3
removing two references to "previous example"
dan-tripp-siteimprove Apr 21, 2026
df65c5b
Failed Example 12 (adding href)
dan-tripp-siteimprove Apr 21, 2026
b2374d7
removing "same as above" reference.
dan-tripp-siteimprove Apr 21, 2026
61d2d48
Update pages/glossary/visible-inner-text.md
dan-tripp-siteimprove Apr 21, 2026
5d5e8bd
using unicode spec notation eg. "U+0028 LEFT PARENTHESIS".
dan-tripp-siteimprove Apr 21, 2026
40525f4
Update pages/glossary/label-in-name-algorithm.md
dan-tripp-siteimprove Apr 21, 2026
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
236 changes: 220 additions & 16 deletions _rules/visible-label-in-accessible-name-2ee8b8.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,7 @@ acknowledgments:
authors:
- Anne Thyme Nørregaard
- Bryn Anderson
- Dan Tripp
- Jey Nandakumar
funding:
- WAI-Tools
Expand All @@ -38,10 +39,14 @@ This rule applies to any element for which all the following is true:

## Expectation

For each target element, all [text nodes][] in the [visible text content][] either match or are contained within the [accessible name][] of this target element, except for characters in the [text nodes][] used to express [non-text content][]. Leading and trailing [whitespace][] and difference in case sensitivity should be ignored.
For each target element, the [visible inner text][] is contained within the [accessible name][] of the target element according to the [label in name algorithm][].

## Assumptions

This rule assumes that the [visible inner text][] is equal to the [label][https://www.w3.org/WAI/WCAG21/Understanding/label-in-name#dfn-label] in most cases (enough cases to be useful) even though "label" is not precisely defined at this point in history.

This rule assumes that neither the label nor the [visible inner text][] are rearranged with CSS in some way so that they appear to the user in a different order than they do in the DOM.

This rule assumes that all resources needed for rendering the page are properly loaded. Checking if resources are missing is out of the scope of rules. Missing resources may be rendered as text (for example, missing `img` are rendered as their `alt` attribute).

## Accessibility Support
Expand All @@ -54,6 +59,7 @@ This rule applies to elements with a [widget role][] that [support name from con

The understanding document of [2.5.3 Label in Name][understand253] use the term "symbolic text characters" to refer to a type of [non-text content][] that uses text characters as symbols, such as using "x" to mean "close". This rule considers them as "characters expressing non-text content". Unicode emojis are another example of characters expressing non-text content, although these are not "symbolic text characters".


### Bibliography

- [Understanding Success Criterion 2.5.3: Label in Name][understand253]
Expand All @@ -65,39 +71,39 @@ The understanding document of [2.5.3 Label in Name][understand253] use the term

#### Passed Example 1

This link has [visible][] text that matches the [accessible name][].
This link has [visible inner text][] that is equal to the [accessible name][].

```html
<a href="https://act-rules.github.io/" aria-label="ACT rules">ACT rules</a>
```

#### Passed Example 2

This link has [visible][] text that, ignoring trailing whitespace, matches the [accessible name][].
This link has [visible inner text][] that, ignoring whitespace, is equal to the [accessible name][].

```html
<a href="https://act-rules.github.io/" aria-label=" ACT rules ">ACT rules</a>
<a href="https://act-rules.github.io/" aria-label=" ACT rules ">ACT rules</a>
```

#### Passed Example 3

This link has [visible][] text that, ignoring case, matches the [accessible name][].
This link has [visible inner text][] that, ignoring case, is equal to the [accessible name][].

```html
<a href="https://act-rules.github.io/" aria-label="act rules">ACT rules</a>
<a href="https://act-rules.github.io/" aria-label="act Rules">ACT rules</a>
```

#### Passed Example 4

This button has [visible][] text that is contained within the [accessible name][].
This button has [visible inner text][] that is contained within the [accessible name][] according to the [label in name algorithm][].

```html
<button aria-label="Next Page in the list">Next Page</button>
```

#### Passed Example 5

This button has [visible][] text that does not need to be contained within the [accessible name][], because the "x" text node is [non-text content][].
The "X" is [non-text content][], so it doesn't need to be contained within the [accessible name][].

```html
<button aria-label="close">X</button>
Expand All @@ -117,45 +123,242 @@ This `button` element has the text "search" rendered as an magnifying glass icon
<button aria-label="Find">search</button>
```

#### Passed Example 7

This button has [visible inner text][] that, according to the [label in name algorithm][], is contained within the [accessible name][]. This example shows why the [label in name algorithm][] uses the [visible inner text][] and not the [visible text content][]: the <p> tags insert whitespace into the result in the former but not the latter.

```html
<button aria-label="Hello world"><p>Hello</p><p>world</p></button>
```

#### Passed Example 8

Similar to the previous example.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Referencing "previous example" is a bit risky since nothing guarantees they will stay in the same order next time we rewrite the rule.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree there is a risk. In this case I think that the risk is worth it. With "previous", I claim that the readability is improved now. If I remove "previous", I can't think of a way to rewrite it that doesn't make it significantly less readable.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe include additional description, like:

Suggested change
Similar to the previous example.
Similar to the previous example. The [label in name algorithm][] inserts whitespace.


```html
<a href="#" aria-label="Some article by John Doe"><h6>Some article</h6><p>by John Doe</p></a>
```

#### Passed Example 9

The [visible inner text][] is "Download specification". The words "the" and "gizmo" aren't part of it.

```html
<a aria-label="Download specification" href="#">Download <span style="visibility: hidden">the</span> <span style="display: none">gizmo</span> specification</a>
```

#### Passed Example 10

This example shows that the [visible inner text][] isn't always the same as the [innerText][https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute]. The visible inner text is "Download specification". The innerText is 'Download \ngizmo\nspecification'. This rule uses the visible inner text - not innerText.

```html
<style>
.visually-hidden {
/* Source: https://www.tpgi.com/the-anatomy-of-visually-hidden/ */
clip-path: inset(50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;
}
</style>
<a aria-label="Download specification" href="#">Download <span class="visually-hidden">gizmo</span> specification</a>
```

#### Passed Example 11

This example shows that the [label in name algorithm][] handles many kinds of whitespace.

```html
<a aria-label="compose email" href="#">compose &nbsp;&nbsp;<br> email</a>
```

#### Passed Example 12

This example passes the rule because "YYYY-MM-DD" is in brackets. Text in brackets is removed by the [label in name algorithm][], because its not normally spoken by speech-input users.

```html
<button aria-label="Search by date">Search by date (YYYY-MM-DD)</button>
```

#### Passed Example 13

The passes for two reasons: 1) because the ellipsis ("…") is [non-text content][], and 2) because the ellipsis is neither a letter nor a digit and so is filtered out by the [label in name algorithm][].

```html
<button aria-label="Next">Next…</button>
```

#### Passed Example 14

This passes because the [label in name algorithm][] effectively ignores all punctuation and emoji, in both the visible inner text and the accessible name, as long as they don't break up words.

```html
<button aria-label="💡 Submit 💡">>>> ** Submit ** <<<</button>
```

#### Passed Example 15

The "X" is non-text content.

```html
<button aria-label="Close">X</button>
```
Comment thread
dan-tripp-siteimprove marked this conversation as resolved.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think adding the "First Name:" pass example from the Understanding document would be useful (since it's very common).

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a strong example for the SC, but I can't see how to adapt it to this ACT rule. That example (<label for="firstname">First Name:</label> <input id="firstname" type="text" name="firstname">) doesn't meet the applicability of this ACT rule because <input> doesn't support "name from content". For us to add an example which uses that visible label "First Name:" on an element which does support "name from content" (mostly <a> and <button>) seems unrealistic to me. Suggestions welcome on how to reconcile this.



### Failed

#### Failed Example 1

This link has [visible][] text that is different from the [accessible name][].
This link has [visible inner text][] that is very different from the [accessible name][].

```html
<a href="https://act-rules.github.io/" aria-label="WCAG">ACT rules</a>
```

#### Failed Example 2

This button has [visible][] text that is only partially contained within the [accessible name][].
This button has [visible inner text][] that is only partially contained within the [accessible name][].

```html
<button aria-label="the full">The full label</button>
```

#### Failed Example 3
#### Failed Example 3

This button has [visible inner text][] that is fully contained within the [accessible name][] when viewed as a character-by-character substring. But that does not satisfy our [label in name algorithm][], which works on full words. So this fails the rule.

```html
<a href="#" aria-label="Discover Italy">Discover It</a>
```

#### Failed Example 4

This link's [accessible name][] contains two tokens (according to the[label in name algorithm][]) and the [visible inner text][] contains one token. So it fails the rule.

```html
<a aria-label="just ice" href="#">justice</a>
```

#### Failed Example 5

This link has an [accessible name][] which contains a hyphen. The [label in name algorithm][] breaks up words on hyphens. So it turns "non-standard" into two tokens: "non" and "standard". So this fails the rule.

```html
<a href="#" aria-label="non-standard">nonstandard</a>
```

#### Failed Example 6

The rule has no special handling for acronyms or initialisms.

```html
<a aria-label="WAVE" href="#">W A V E</a>
Comment thread
dan-tripp-siteimprove marked this conversation as resolved.
Outdated
```

#### Failed Example 7

The rule has no special handling for abbreviations.
Copy link
Copy Markdown

@mbgower mbgower Mar 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rule has no special handling for abbreviations.

This seems problematic. For many abbreviations it is much more natural (in English) to say the full word when encountering an abbreviations (for example, abbreviations in an address like "Rd.", "St.", "Pl.", etc).

Perhaps it is just another shortcoming of this SC, but the calculation seems to me to need to be more fuzzy, and bias towards passing, not failing an abbreviation construct.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, I agree, but I consider this problem to be in the category of problems that this PR didn't create and didn't make worse. What do you think?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess two points.

The SC wording is: "the name contains the text that is presented visually."

We already have a rule stating that punctuation can be disregarded, so in this example, the displayed wording can be interpreted as "University Ave" and the name is "University Avenue". The accessible name literally contains the text that is presented visually (plus three more characters). So why is it a fail? It should be a pass, no?

The second point is just about abbreviations as synonyms. I can think of situations in English where it would be unusual to say only the abbreviation. For instance, if someone sees "Main St." or "First Rd.", they are going to say the abbreviation as the full word ("main street", "first road"). On the other hand "Ave" may be spoken as the full word or as the abbreviation. Part of me believes it is reasonable to compile a set of abbreviations which are commonly spoken as the full word, and not the abbreviation. But that seems unsustainable/unscalable.

On consideration, I reluctantly agree that failing a mismatch where the name does not contain all the characters of the displayed abbreviation (less punctuation) makes sense.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For future reference, if nothing else: here are some supporting arguments for failing abbreviations, from WCAG. These are independent of arguments about user impact. This is just about the letter of the law.

  1. "the exact string of the visible label does not occur in the accessible name" is mentioned as a reason for failure in failure technique F96 for this SC (https://www.w3.org/WAI/WCAG22/Techniques/failures/F96.html).
  2. "The accessible name contains a match for the string of the visible label" is a necessary condition for passing, under the "Procedure" section of - again - failure technique F96 for this SC.
  3. "When in doubt ... match the string exactly" - "Understanding SC 2.5.3: Label in Name" (https://www.w3.org/WAI/WCAG22/Understanding/label-in-name)

1 says "exact string" and 3 says "string exactly". That doesn't allow an abbreviation to pass.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While it's a good aspect to be thinking about, I don't agree that this is a problem for this test. From my experience (anecdotal of course) AT users want to have access to the same information as it is presented visually. In what cases would a non-sighted user need to have something fully spelled out and a sighted one wouldn't? While it's less severe of an impact, it's still impactful and should fail this test.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Point taken, but I've since side-stepped this by making anything with abbreviations inapplicable (inspired by per Giacomo's suggestion on Thursday). I did this in commit 9490a5e .


```html
<a aria-label="University Avenue" href="#">University Ave.</a>
```

#### Failed Example 8

This link has [visible][] text with mathematical symbols, that does not match the [accessible name][] because the mathematical symbols were written out in the accessible name. This is [explicitly mentioned in WCAG](https://www.w3.org/WAI/WCAG21/Understanding/label-in-name#mathematical-expressions-and-formulae).
This link has [visible inner text][] with mathematical symbols and is not contained within the [accessible name][] because the mathematical symbols are represented as English words (not digits) in the accessible name. This is [explicitly mentioned in WCAG](https://www.w3.org/WAI/WCAG21/Understanding/label-in-name#mathematical-expressions-and-formulae).

```html
<a href="/" aria-label="Proof of two multiplied by two is four">Proof of 2&times;2=4</a>
```

#### Failed Example 9

Similar to the previous example. This rule has no special handling for converting mathematical symbols into words, or vice versa.

```html
<button aria-label="11 times 3 equals 33">11×3=33</button>
```

#### Failed Example 10

This button's accessible name contains the same tokens that are in the visible label. But they aren't in the same order, so it fails the sublist check part of the [label in name algorithm][], and so it fails the rule.

```html
<button aria-label="how are you"><span>you</span><span>how</span><span>are</span></button>
```

#### Failed Example 11

This link's accessible name contains the same digits that are in the visible label, and in the same order. But they have different spaces and punctuation between them, so they are considered separate tokens. So this fails the rule.

```html
<a aria-label="Call 1 2 3. 4 5 6. 7 8 9 0." href="tel:1234567890">123.456.7890</a>
```

#### Failed Example 12

This rule has no special handling which tries to guess when number have the same semantic meaning. It operates on tokens only.

```html
<a href="#2021" aria-label="20 21">2021</a>
```

#### Failed Example 13

Similar to the previous example.
Comment thread
dan-tripp-siteimprove marked this conversation as resolved.
Outdated

```html
<a aria-label="fibonacci: 0 1 1 2 3 5 8 13 21 34">fibonacci: 0112358132134</a>
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue: The a element needs an href in order to be a widget.

```

#### Failed Example 14

This rule has no special handling for converting digits into words, or vice versa.

```html
<a href="#2021" aria-label="twenty twenty-one">two thousand twenty-one</a>
```

#### Failed Example 15

(Same as above.) This rule has no special handling for converting digits into words, or vice versa.

```html
<a aria-label="two zero two three" href="#">2 0 2 3</a>
```

#### Failed Example 16

This rule has no special handling for digits that appear next to letters with no spaces in between.

```html
<a aria-label="1a" href="#">1</a>
```

#### Failed Example 17

The definition of [visible inner text][] doesn't treat text any differently if it's excluded from the accessibility tree with aria-hidden. So this rule effectively ignores aria-hidden. So this element fails the rule.

```html
<a aria-label="Download specification" href="#">Download <span aria-hidden="true">gizmo</span> specification</a>
```

### Inapplicable

#### Inapplicable Example 1

This `nav` is not a widget, so the [visible][] text does not need to match the [accessible name][].
This `nav` is not a widget, so the [visible inner text][] does not need to match the [accessible name][].

```html
<nav aria-label="main nav">W3C navigation</nav>
```

#### Inapplicable Example 2

This email text field does not need to have its [visible][] text match the [accessible name][]. The content of a textfield shows its value instead of its label; it does not [support name from content][supports name from content]. The label is usually adjacent to the textfield instead.
This email text field does not need to have its [visible inner text][] match the [accessible name][]. The content of a textfield shows its value instead of its label; it does not [support name from content][supports name from content]. The label is usually adjacent to the textfield instead.

```html
<div>E-mail</div>
Expand All @@ -164,15 +367,15 @@ This email text field does not need to have its [visible][] text match the [acce

#### Inapplicable Example 3

This `div` element does not have a widget role, so the [visible][] text does not need to match the [accessible name][].
This `div` element does not have a widget role, so the [visible inner text][]t does not need to match the [accessible name][].

```html
<div role="tooltip" aria-label="OK">Next</div>
```

#### Inapplicable Example 4

This link has no [visible text content][].
This link has no [visible inner text][].

```html
<a href="https://w3.org" aria-label="W3C homepage">
Expand All @@ -186,6 +389,7 @@ This link has no [visible text content][].
[semantic role]: #semantic-role 'Definition of Semantic role'
[supports name from content]: https://www.w3.org/TR/wai-aria-1.1/#namefromcontent 'Definition of Supports name from contents'
[visible]: #visible 'Definition of visible'
[visible inner text]: #visible-inner-text 'Definition of Visible inner text'
[visible text content]: #visible-text-content 'Definition of Visible text content'
[whitespace]: #whitespace 'Definition of Whitespace'
[widget role]: https://www.w3.org/TR/wai-aria-1.1/#widget_roles 'Definition of Widget role'
Expand Down
4 changes: 4 additions & 0 deletions package.json
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,10 @@
"name": "Dagfinn Rømen",
"url": "https://github.com/DagfinnRomen"
},
{
"name": "Dan Tripp",
"url": "https://github.com/dan-tripp-siteimprove"
},
{
"name": "Daniël Strik",
"url": "https://github.com/danistr"
Expand Down
34 changes: 34 additions & 0 deletions pages/glossary/label-in-name-algorithm.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
---
title: Label in Name Algorithm
key: label-in-name-algorithm
unambiguous: true
objective: false
input_aspects:
- CSS styling
- DOM tree
---

Comment thread
dan-tripp-siteimprove marked this conversation as resolved.
Let 'label' be the [visible inner text][] of the target element. Let 'name' be the [accessible name][] of the target element. Both 'label' and 'name' are strings.
Comment thread
dan-tripp-siteimprove marked this conversation as resolved.
Outdated

Sub-algorithm to tokenize a string:
Comment thread
kengdoj marked this conversation as resolved.

- Convert the string to lower case.
- For each character that either a) represents non-text content, or b) isn't a letter or a digit: replace that character with a space character.
Copy link
Copy Markdown
Collaborator

@dd8 dd8 May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can cause false positives with words that are not consistently hyphenated. For example:

'antimatter' vs 'anti-matter' (the Wikipedia antimatter article uses both)
'derisk' vs 'de-risk' (Cambridge dictionary uses first spelling, Collins dictionary uses the second)
'nonnegative' vs 'non-negative' https://math.stackexchange.com/a/3344027

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, and I assume the voice control software would handle it fine, but if it was a customer who was arguing this, I would say "too bad" (diplomatically, of course). This is part of a larger issue that I call "you need to play ball with the automated check". I run into customer arguments like this often enough that I have a "canned response" it. It reads, in part: "It's not feasible for an automated checker to know any better in this situation. When you use an automated checker instead of a manual audit, in order to gain efficiency, you lose accuracy. This is an unavoidable example of that."

For the page author to "play ball" for "label in name" would be easy: use the same spelling, including hyphenation, in the aria-label that they used in the visible label. This is, I think, not a lot to ask of a page author.

I could add an assumption to the rule. Something along the lines of "This rule assumes that for any word (including any hyphenated word) that appears in both the accessible name and the visible label, the same spelling and hyphenation is used in both places. For example, using 'antimatter' in the accessible name and 'anti-matter' in the visible label would fail this rule, but arguably pass the Success Criterion.

Copy link
Copy Markdown
Collaborator

@dd8 dd8 Jun 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bearing in mind this is for voice control, would a voice control user pronounce the hyphenated and non-hyphenated versions differently? Personally, I would pronounce both versions identically:

'antimatter' vs 'anti-matter'
'derisk' vs 'de-risk'
'nonnegative' vs 'non-negative'

and sometimes it's context specific:

'1-2' might be pronounced as 'one two' in a sports context, but as 'one minus two' in a maths context/

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bearing in mind this is for voice control, would a voice control user pronounce the hyphenated and non-hyphenated versions differently? Personally, I would pronounce both versions identically:

'antimatter' vs 'anti-matter' 'derisk' vs 'de-risk' 'nonnegative' vs 'non-negative'

It's worth noting that Dragon voice recognition software only recognises and responds to words that are in its dictionary. For instance, if the accessible name is 'nonnegative', nothing you say will cause Dragon to interact with it if 'nonnegative' is not in its dictionary. If the accessible name is 'non negative', you could say either or both words because both will be in the dictionary. I suspect the same would be the case with 'non-negative', but I may be wrong.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I interpret this Dragon behaviour as causing an accessibility failure in some cases that this rule passed. I don't think it's practical for this rule to contain Dragon's dictionary and keep it up to date. But I think it indicates an opportunity for a vendor to do it, and thereby excel.

- For a) Judgement of "non-text" probably can't be fully automated. eg. "X" for "close" probably can be, but presumably there are more cases than this.
- For b) Use the unicode classes Letter, Mark, and "Number, Decimal Digit [Nd]". (This will exclude hyphens, punctuation, emoji, and more.)
- Remove all characters that are within parentheses (AKA round brackets).
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Parenthesis mean something very different in German, so maybe shouldn't be removed in German text:
https://translationpost.com/2019/08/06/difference-german-english-parenthesis-usage/

And in Arabic parenthesis are often uses as quote marks:
https://forum.wordreference.com/threads/parentheses-in-arabic.1772289/

In accounting, numbers in round brackets are negative - typically losses or debts - so these are really important.
e.g. Profit: (2,400) is a 2,400 loss, but would match aria-label='Profit'

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was educational. I admit that this PR will not handle those cases well. But at least it will handle them as "false negatives", which are inevitable in ACT rules. I think that this concern - and all of your concerns here - are valuable, but I don't think that this PR can reasonably be expected to handle them all. This PR "closes" 5 issues, explicitly "does not handle" 3 more, and (I think) doesn't do any harm. I'd like to improve the rule a little, then take it from there. This PR has been open for 10 months. "Perfect is the enemy of good" and all that.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that we know this is an issue, I think it should be included some how as a note that it may result in false negatives in these situations. Particularly since we are already recognising i18n differences in the whitespace splitting part of this algorithm.

- Ignore square brackets and braces.
- Split the string into a list of strings, using a whitespace regular expression as the separator.
- This 'split' operation must:
- Effectively remove leading and trailing whitespace as a pre-processing step.
- If the string was all whitespace before this operation: result in an empty list.

Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'?
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'?
Then do the check: is the tokenized `label` a sublist of the tokenized `name`?

- This 'sublist' check has these properties:
- It checks whether elements are consecutive or not. i.e. it checks for a substring, in the computer science sense of the term. Not a subsequence.
- An empty list is a sublist of any list.

If the answer is "yes" (i.e. the tokenized 'label' a sublist of the tokenized 'name'), then the target element passes the rule. Otherwise, it fails the rule.
Comment thread
dan-tripp-siteimprove marked this conversation as resolved.
Outdated

[accessible name]: #accessible-name 'Definition of accessible name'
[visible inner text]: #visible-inner-text 'Definition of Visible inner text'
Loading