Rule 2ee8b8 ("Visible label is part of accessible name"): introducing a new "label in name algorithm". by dan-tripp-siteimprove · Pull Request #2075 · act-rules/act-rules.github.io

dan-tripp-siteimprove · 2023-06-22T00:53:18Z

<< Describe the changes >>

Closes issue(s):

closes Visible label is part of accessible name (2ee8b8): screen reader pronunciation help in name that is not in label #2051, closes Visible label is part of accessible name (2ee8b8): symbolic text should not be considered a visible label #1989, closes Visible label is part of accessible name (2ee8b8): should common abrevations be accepted? #1619, closes Visible label is part of accessible name (2ee8b8): extra spaces in name might be OK. #1615, closes Visible label is part of accessible name (2ee8b8): Expectation seems to have unintended consequences #1458
does not handle: "Visible label is part of accessible name" [2ee8b8]: does the "label" necessarily contains all the visible text content? #2040 Visible label is part of accessible name indicates that inputs are not applicable because the label is not contained in the input #1500 "label and name from content mismatch" needs to also fail split up labels [2ee8b8] #451

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

Pull Request Etiquette

When creating PR:

[ x] Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
[x ] Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

[ x] Add yourself (and co-authors) as "Assignees" for PR.
[ x] Add label to indicate if it's a Rule, Definition or Chore.
[x ] Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
[ x] Optionally request feedback from anyone in particular by assigning them as "Reviewers".

When merging a PR:

Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

Go to the “Files changed” tab
Here you will have the option to leave comments on different lines.
Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.

…l in name algorithm". It's intended mostly to handle whitespace and punctuation.

WilcoFiers · 2023-07-20T13:52:12Z

@dan-tripp-siteimprove Since this is being worked on still by @kengdoj, can we set this to draft?

dan-tripp-siteimprove · 2023-07-20T21:20:46Z

@dan-tripp-siteimprove Since this is being worked on still by @kengdoj, can we set this to draft?

Done

…307n5z

…t-rules.github.io into develop

Jym77

This looks good. I like the details and the many new examples that explicit the decisions we've taken.

_rules/visible-label-in-accessible-name-2ee8b8.md

pages/glossary/visible-inner-text.md

Jym77 · 2023-11-09T09:19:52Z

pages/glossary/visible-inner-text.md

+
+The <dfn id="for-text">visible inner text of a [text node][]</dfn> is:
+-   if the [text node][] is [visible][], its visible inner text is its [data][];
+-   if the [text node][] is not-[visible][], [rendered][], and contains only [whitespace][], its visible inner text is the string `" "` (a single ASCII whitespace);


The conditional here sounds a bit weird 🤔
Notably, a text node that is not visible, rendered, and contains more than whitespace (e.g. in Hello) would not trigger it and therefore have an empty string as visible inner text (rather than a whitespace).

Interesting question. I don't know the answer. But I'll note that I copied this definition from sanshikan so if it needs fixing here, it probably needs fixing there too.

OK, doing some archaeology, this is due to the fact that whitespace are not visible per our definition…

<button aria-label="hello world">hello world</button>

The span#space is not visible (and neither is its child text node). So the first bullet doesn't apply. Without the second bullet, the visible inner text of the button would be helloworld, not matching the accessible name of hello world due to spacing…
I guess we need to add an example to show that.

Done in b2df021

This raises another question: what should we do with this?
<a aria-label="Download specification" href="#">Downloadxspecification</a>
According to the current definition, because of the clause "contains only [whitespace][]", the visible inner text of the <a> element is "Downloadspecification". Visually it looks like "Download specification". So I wonder if we could remove the clause "contains only [whitespace][]". What do you think?

Good point 🤔 But if the span was invisible due to absolute positioning out of viewport, it shrould be removed:

<a aria-label="Download specification" href="#">Downloadxspecification</a>

I guess the true condition is whether it creates a CSS box that lies somewhere between the ones of the rest of the text taking part in the computation (and isn't fully contained in them), or something like that 🙈
Or maybe we just make the special case for visibility: hidden and assume that these is already a corner case and that it won't create too many true problems (We've been using that definition in Alfa for two years and I don't remember seeing a problem caused by it, so it may be safe to assume that it is a good enough approximation).

This has given me a lot to think about. I'll try to bring it up in our next one-on-one meeting.

pages/glossary/visible-inner-text.md

pages/glossary/label-in-name-algorithm.md

…://github.com/Siteimprove/sanshikan/blob/main/terms/visible-inner-text.md) - changing glossary links' prefixes from "./" to "#". I don't know if the former was working or not. but the latter is the common practice, it seems.

Co-authored-by: Jean-Yves Moyen <jym@siteimprove.com>

…placing it with a new idea: the algorithm 'return value' eg. 'returns "is contained"'. - rewording rule expectation. I think that 'For the target element' is better than 'For each target element' because for this rule, the computation of the expecation for each applicable target element is done in isolation from the other applicable targets on the page. It's simpler if the "for loop" over all applicable targets is done by the tool, not the rule.

…s algorithm is for.

Changes done

_rules/visible-label-in-accessible-name-2ee8b8.md

mbgower · 2025-03-26T18:29:32Z

_rules/visible-label-in-accessible-name-2ee8b8.md

 #### Failed Example 5

-This link has [visible][] text does not match the [accessible name][] because there are extra spaces in the accessible name.
+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.


The [label in name algorithm][] breaks up words on hyphens

That seems somewhat problematic, especially when considered from a speech input perspective, where aurally there is no meaningful difference between "non standard", "non-standard", and "nonstandard".

I agree, and it's unclear to me what the ideal fix for this would be, but I think this is a problem which - as I've said for other problems - "this PR didn't create, and didn't make worse" - am I right? If so, then I suggest - as I did with similar problems raised on this PR - that we deal with it later. In the spirit of incremental improvement.

I think the algorithm does make it worse by breaking a hyphenated word into two words. If the algorithm simply removed the hyphen (ignored it) rather than replacing it with a space, it would raise less false positives. I'm not saying it would be ideal, but less problematic.

To address this I removed this Failed Example, in commit 1baf1ee

mbgower · 2025-03-26T18:35:10Z

_rules/visible-label-in-accessible-name-2ee8b8.md

+
+#### Failed Example 7
+
+The rule has no special handling for abbreviations.


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.

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?

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.

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.

"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).

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

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

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.

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 .

Co-authored-by: Mike Gower <gowerm@ca.ibm.com>

detlevhfischer

I believe the computation of the label does not take into account cases where there is additional, clearly separated information following the label text that may be embedded in the same element, but should probably not be used when evaluating whether name contains the label string. Example:
<label>First name (required)</label><input type="text" aria-label="First name">

This would formally fail, but it probably shouldn't.

The broader problem is that the purpose of the SC (to allow predictable and workable speech input) is practically undone in cases where longish label text is included in the accessible name in order to meet 2.5.3. When using voice control on mobile phones, speaking the long label text to activate the element will then often not work. So, a formal PASS, but a practical FAIL.

Not sure how to include this in the algorithm though.

dan-tripp-siteimprove · 2025-05-07T15:36:21Z

I'd like to thank everyone for the comments in recent weeks. Unfortunately I have been too occupied with other work to respond to them. I hope to have time in late May.

…ptions. Somewhat related to PR review comment act-rules#2075 (comment)

netlify · 2026-01-29T02:23:26Z

✅ Deploy Preview for act-rules ready!

Name	Link
🔨 Latest commit	`8ea29b6`
🔍 Latest deploy log	https://app.netlify.com/projects/act-rules/deploys/698b27690fa0e80008464069
😎 Deploy Preview	https://deploy-preview-2075--act-rules.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

dan-tripp-siteimprove · 2026-01-29T02:52:23Z

Example: <label>First name (required)</label><input type="text" aria-label="First name">

This would formally fail, but it probably shouldn't.

Actually, on further inspection, I believe that example would pass the rule (in the rule's current state in this PR), due to the step of the algorithm which removes round brackets and everything inside of them.

…ew comment act-rules#2075 (comment)

detlevhfischer · 2026-01-29T07:24:07Z

I believe that example would pass the rule (in the rule's current state in this PR), due to the step of the algorithm which removes round brackets and everything inside of them.

Point taken. It still seems odd that (if I read the procedure correctly) First name (required) would pass, but not First name - required or First name | required or first name [required] whatever other variant authors would come up with.

… the assumptions to the applicability. as per meeting 2026-02-05. - adding clause to applicability: any widget that contains an image is inapplicable (due to lack of OCR in this rule - would cause a false positive.) - in some html examples: minor formatting fixes.

kengdoj · 2026-03-02T17:11:16Z

_rules/visible-label-in-accessible-name-2ee8b8.md

 - The element has [visible text content][]; and
 - The element has an `aria-label` or `aria-labelledby` attribute.
+- The element does not contain any [rendered image resources][rendered image resource].
+- If there are any words that appear in both the element's accessible name and its visible label, then for each such pair, the same spelling and hyphenation is used in both places.


I'm not clear why this (line 41) is under Applicability. Maybe an Inapplicable Example would help.

kengdoj · 2026-03-02T17:16:31Z

_rules/visible-label-in-accessible-name-2ee8b8.md

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


Since square or curly brackets aren't mentioned in the algorithm,

Suggested change

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

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

kengdoj · 2026-03-02T17:18:38Z

_rules/visible-label-in-accessible-name-2ee8b8.md


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


Suggested change

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

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

kengdoj · 2026-03-02T17:19:45Z

_rules/visible-label-in-accessible-name-2ee8b8.md

+
+#### Failed Example 12
+
+Similar to the previous example.


Suggested change

Similar to the previous example.

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

kengdoj · 2026-03-02T17:31:19Z

_rules/visible-label-in-accessible-name-2ee8b8.md

+
+#### Passed Example 8
+
+Similar to the previous example.


Maybe include additional description, like:

Suggested change

Similar to the previous example.

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

dan-tripp-siteimprove and others added 6 commits April 4, 2023 12:25

invalid-form-field-value-36b590: updating failed example 2.

aeafb90

Merge branch 'develop' into develop

5a07973

Merge branch 'act-rules:develop' into develop

a75c7f8

Rule visible-label-in-accessible-name-2ee8b8: introducing a new "labe…

623d26e

…l in name algorithm". It's intended mostly to handle whitespace and punctuation.

Merge branch 'act-rules:develop' into develop

f920a47

Merge remote-tracking branch 'origin/develop' into rule-2ee8b8-may-2023

ee3e993

dan-tripp-siteimprove added Rule Update Use this label for an existing rule that is being updated reviewers wanted labels Jun 22, 2023

dan-tripp-siteimprove requested review from giacomo-petri and kengdoj June 22, 2023 00:53

dan-tripp-siteimprove self-assigned this Jun 22, 2023

dan-tripp-siteimprove changed the title ~~Rule 2ee8b8 may 2023~~ Rule 2ee8b8 ("Visible label is part of accessible name"): introducing a new "label in name algorithm". Jun 22, 2023

dan-tripp-siteimprove marked this pull request as draft July 20, 2023 21:19

dan-tripp-siteimprove and others added 2 commits August 17, 2023 12:14

Merge branch 'act-rules:develop' into develop

75a9878

Adding examples to rule presentational-children-no-focusable-content-…

81caf8a

…307n5z

Jym77 mentioned this pull request Sep 28, 2023

Update visible-label-in-accessible-name-2ee8b8.md #2101

Merged

7 tasks

dan-tripp-siteimprove added 2 commits October 27, 2023 12:49

Merge remote-tracking branch 'upstream/develop' into develop

2928be6

Merge branch 'develop' of https://github.com/dan-tripp-siteimprove/ac…

5cd8b2c

…t-rules.github.io into develop

Jym77 previously requested changes Nov 9, 2023

View reviewed changes

dan-tripp-siteimprove and others added 8 commits November 9, 2023 11:42

removing Passed Example 15 because it's a duplicate.

092c849

editing example: WAVE -> WCAG

473bcb8

Update pages/glossary/visible-inner-text.md

5c7fc1e

Co-authored-by: Jean-Yves Moyen <jym@siteimprove.com>

Update pages/glossary/visible-inner-text.md

3d3b657

Co-authored-by: Jean-Yves Moyen <jym@siteimprove.com>

adding mention of innerText

8ed61b8

adding preamble to label-in-name-algorithm.md which mentions what thi…

46294dd

…s algorithm is for.

mbgower reviewed Mar 26, 2025

View reviewed changes

_rules/visible-label-in-accessible-name-2ee8b8.md Outdated Show resolved Hide resolved

mbgower reviewed Mar 26, 2025

View reviewed changes

Update _rules/visible-label-in-accessible-name-2ee8b8.md

b77023c

Co-authored-by: Mike Gower <gowerm@ca.ibm.com>

alastc mentioned this pull request Mar 28, 2025

ACT review for label in name algorythm w3c/wcag#4310

Closed

detlevhfischer suggested changes Apr 15, 2025

View reviewed changes

bruce-usab mentioned this pull request Apr 25, 2025

WCAG 2 Backlog TF review of Label in Name Algorithm w3c/wcag#4312

Open

HelenBurge removed the reviewers wanted label May 29, 2025

carlosapaduarte added the Agenda item label Jul 24, 2025

HelenBurge removed the Agenda item label Sep 29, 2025

Removing Failed Example 5 because it violates one of the rule's assum…

1baf1ee

…ptions. Somewhat related to PR review comment act-rules#2075 (comment)

Minor wording change.

4afc39b

Replacing some bullet points with a numbered list. because of PR revi…

cd69eaf

…ew comment act-rules#2075 (comment)

Jym77 added the Agenda item label Feb 2, 2026

dan-tripp-siteimprove requested review from Jym77, kengdoj and shunguoy February 9, 2026 19:32

Merge branch 'develop' into rule-2ee8b8-may-2023

8ea29b6

dan-tripp-siteimprove requested review from dd8, kengdoj and shunguoy and removed request for dd8, kengdoj and shunguoy February 25, 2026 23:01

kengdoj requested changes Mar 2, 2026

View reviewed changes


		#### Failed Example 7

		The rule has no special handling for abbreviations.


		#### Passed Example 14

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


		#### Failed Example 11

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

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

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

Conversation

dan-tripp-siteimprove commented Jun 22, 2023 • edited by Jym77 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Etiquette

When creating PR:

After creating PR:

When merging a PR:

How to Review And Approve

Uh oh!

WilcoFiers commented Jul 20, 2023

Uh oh!

dan-tripp-siteimprove commented Jul 20, 2023

Uh oh!

Jym77 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

mbgower Mar 26, 2025 • 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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

detlevhfischer left a comment • 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!

dan-tripp-siteimprove commented May 7, 2025

Uh oh!

netlify bot commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for act-rules ready!

Uh oh!

dan-tripp-siteimprove commented Jan 29, 2026

Uh oh!

detlevhfischer commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kengdoj Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

dan-tripp-siteimprove commented Jun 22, 2023 •

edited by Jym77

Loading

mbgower Mar 26, 2025 •

edited

Loading

detlevhfischer left a comment •

edited

Loading

netlify bot commented Jan 29, 2026 •

edited

Loading

detlevhfischer commented Jan 29, 2026 •

edited

Loading

kengdoj Mar 2, 2026 •

edited

Loading