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.

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

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

…://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

…ext-clause-2.

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

Also removing whitespace between the divs. Doing this because that whitespace was introduced accidentally in commit 5617755 (which was a merge).

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

as per act-rules#2075 (comment) this fixes a big problem that has been there since the beginning of this PR i.e. three years.

…iteimprove/act-rules.github.io into rule-2ee8b8-may-2023

as per act-rules#2075 (comment)

Jym77

Looks good. Many small editorial clean up.

Jym77 · 2026-05-21T10:56:56Z

+
+This rule assumes that the visible label doesn't use CSS to add whitespace where none exists in the DOM.
+
+This rule - specifically, the [label in name algorithm][] that this rule relies on - assumes that content within parentheses can be ignored.  ("Parentheses" are also known as "round brackets".)  This is important becuase the algorithm's treatment of parentheses is to remove them and all characters within them. This assumption is almost always true in English.  Exceptions include links with names such "Dune (1984 film)" and "Dune (2021 film)". This assumption is known to be often false in languages other than English, such as German (where parentheses indicate dual states) and Arabic (where parentheses are often used as quotation marks). Violations of this assumption will, in real-world scenarios, more often result in a false negative for this rule rather than a false positive.


Suggested change

This rule - specifically, the [label in name algorithm][] that this rule relies on - assumes that content within parentheses can be ignored. ("Parentheses" are also known as "round brackets".) This is important becuase the algorithm's treatment of parentheses is to remove them and all characters within them. This assumption is almost always true in English. Exceptions include links with names such "Dune (1984 film)" and "Dune (2021 film)". This assumption is known to be often false in languages other than English, such as German (where parentheses indicate dual states) and Arabic (where parentheses are often used as quotation marks). Violations of this assumption will, in real-world scenarios, more often result in a false negative for this rule rather than a false positive.

This rule — specifically, the [label in name algorithm][] that this rule relies on — assumes that content within parentheses can be ignored ("Parentheses" are also known as "round brackets"). This is important because the algorithm's treatment of parentheses is to remove them and all characters within them. This assumption is almost always true in English. Exceptions include links with names such "Dune (1984 film)" and "Dune (2021 film)". This assumption is known to be often false in languages other than English, such as German (where parentheses indicate dual states) and Arabic (where parentheses are often used as quotation marks). Violations of this assumption will, in real-world scenarios, more often result in a false negative for this rule rather than a false positive.

Jym77 · 2026-05-21T10:58:32Z

 #### 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][]. Note: this would need to meet SC 1.1.1 Non text content.
+This button has [visible inner text][] that does not need to be contained within the [accessible name][], because the "x" text node is [non-text content][]. Note: this would need to meet SC 1.1.1 Non text content.


Suggested change

This button has [visible inner text][] that does not need to be contained within the [accessible name][], because the "x" text node is [non-text content][]. Note: this would need to meet SC 1.1.1 Non text content.

This button has [visible inner text][] that does not need to be contained within the [accessible name][], because the "X" text node is [non-text content][]; the [label in name algorithm][] therefore ignores it. Note: this would need to meet SC 1.1.1 Non text content.

Jym77 · 2026-05-21T10:59:02Z

 #### Passed Example 6

-This `button` element has the text "search" rendered as an magnifying glass icon by the font. Because the text is rendered as [non-text content][], the text does not need to be contained within the [accessible name][].
+This `button` element has the text "search" rendered as a magnifying glass icon by the font. Because the text is rendered as [non-text content][], the text does not need to be contained within the [accessible name][].


Suggested change

This `button` element has the text "search" rendered as a magnifying glass icon by the font. Because the text is rendered as [non-text content][], the text does not need to be contained within the [accessible name][].

This `button` element has the text "search" rendered as a magnifying glass icon by the font. Because the text is rendered as [non-text content][], the text does not need to be contained within the [accessible name][]; and the [label in name algorithm][] ignores it.

Jym77 · 2026-05-21T11:01:49Z

+
+#### Passed Example 9
+
+The [visible inner text][] of this link is "ACT" (with no spaces) because of the explicit styles of `display: inline` on the `p` elements and the absence of whitespace between the `div` elements. The cases of `display: inline` and `display: block` are handled by the definition of [visible inner text of an element][]. This example shows that the definition agrees with the visual rendering done by the browser.


Suggested change

The [visible inner text][] of this link is "ACT" (with no spaces) because of the explicit styles of `display: inline` on the `p` elements and the absence of whitespace between the `div` elements. The cases of `display: inline` and `display: block` are handled by the definition of [visible inner text of an element][]. This example shows that the definition agrees with the visual rendering done by the browser.

The [visible inner text][] of this link is "ACT" (with no spaces) because of the explicit styles of `display: inline` on the `div` elements and the absence of whitespace between them. The cases of `display: inline` and `display: block` are handled by the definition of [visible inner text of an element][]. This example shows that the definition agrees with the visual rendering done by the browser.

Jym77 · 2026-05-21T11:07:43Z

+
+The <dfn id="visible-inner-text:for-text">visible inner text of a [text node][]</dfn> is:
+1.   if the [text node][] is [visible][], its visible inner text is its [data][] with whitespace normalized by replacing contiguous [whitespace][] with `" "` (U+0020 SPACE);
+1.   <span id="visible-inner-text:for-text-clause-2">if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);</span>


Suggestion: it may be nicer, both here and for references, to name the clauses and use a dfn element around the name. Something like:

Suggested change

1. if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);

1. (<dfn id="visible-inner-text:text-whitespace>Whitespace</dfn>): if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);

Obviously, it needs to be done on all clauses for consistency to make sense. But in a fairly complex definition like this one, it can also help discussing it.

Jym77 · 2026-05-21T11:50:22Z

+        - Effectively remove leading and trailing [whitespace][].
+        - If the input string contains nothing but [whitespace][] before this operation: return an empty list.
+    - In English and most other European languages, a greedy [whitespace][] regular expression will accomplish this.  In languages such as Thai, Chinese, and Japanese, it won't.
+    - A consequence of using the ACT definition of [whitespace][] here is that all kinds of whitespace are covered.  That includes the Unicode code point U+00A0 NO-BREAK SPACE (NBSP), which can be represented by the HTML named character reference `&nbsp;`.


Suggested change

- A consequence of using the ACT definition of [whitespace][] here is that all kinds of whitespace are covered. That includes the Unicode code point U+00A0 NO-BREAK SPACE (NBSP), which can be represented by the HTML named character reference ` `.

- A consequence of using the ACT definition of [whitespace][] here is that all kinds of whitespace are covered. That includes the Unicode code point U+00A0 NO-BREAK SPACE (NBSP), which can be represented by the HTML named character reference ` `.

Jym77 · 2026-05-21T11:52:01Z

+Then do the check: is the tokenized `label` a contiguous subsequence of the tokenized `name`?
+- This 'contiguous subsequence' check has these properties:
+    - Each string comparison (between a list element in the tokenized label and a list element in the tokenized name) is a simple string equality check.
+    - The "contiguous" aspect means that it's crucial that the elements are consecutive in the original list.  Put another way: a contiguous subsequence of X can be obtained by removing any number of tokens from the start and/or end (but not the middle) of X.  For example: ["A", "B", "C"] is a contiguous subsequence of ["A", "B", "C", "D"].  ["A", "B", "D"] is not.


Suggested change

- The "contiguous" aspect means that it's crucial that the elements are consecutive in the original list. Put another way: a contiguous subsequence of X can be obtained by removing any number of tokens from the start and/or end (but not the middle) of X. For example: ["A", "B", "C"] is a contiguous subsequence of ["A", "B", "C", "D"]. ["A", "B", "D"] is not.

- The "contiguous" aspect means that it's crucial that the elements are consecutive in the original list. Put another way: a contiguous subsequence of X can be obtained by removing any number of tokens from the start and/or end (but not the middle) of X. For example: ["A", "B", "C"] is a contiguous subsequence of ["A", "B", "C", "D"]; but ["A", "B", "D"] is not.

Jym77 · 2026-05-21T11:53:14Z

+  - DOM tree
+---
+
+(The "visible inner text" defined here is similar to, but not the same as, [visible text content][] and [innerText](https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute).)


Suggestion: Maybe move that to a Background section at the end of the definition? It looks weird starting the definition with a parenthesis.

Jym77 · 2026-05-21T11:56:17Z

+
+The <dfn id="visible-inner-text:for-text">visible inner text of a [text node][]</dfn> is:
+1.   if the [text node][] is [visible][], its visible inner text is its [data][] with whitespace normalized by replacing contiguous [whitespace][] with `" "` (U+0020 SPACE);
+1.   <span id="visible-inner-text:for-text-clause-2">if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);</span>


Note: You can also try and name the bullet, which can be convenient for a complex definition like this one, and makes it easier to define anchors.

Suggested change

1. if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);

1. **(<dfn id="visible-inner-text:text-whitespace">Whitespace</dfn>):** if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);

The bolding and parenthesis should make it visually obvious that it is not part of the definition. Obviously, it needs to be done on all items in a list if it is done on any.

Jym77 · 2026-05-21T11:57:33Z

+1.   if the [element][] is [rendered][] and not [visible][] and has a [bounding box][] which has width greater than 0, its visible inner text is `" "` (U+0020 SPACE);
+1.   if the [element][] is [rendered][] and not [visible][] and has a [bounding box][] which has width of 0, its visible inner text is `""` (the empty string);
+1.   if the [element][] is a [`<br>`][<br>] element, its visible inner text is `"\n"` (U+000A END OF LINE).
+1.   if the [computed][] [`display`][display] property of the [element][] has an [outer display type][] of `block`, or an [inner display type][] of `table-caption`, the visible inner text of the [element][] is the concatenation of is `"\n"` (U+000A END OF LINE) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus another `"\n"` (U+000A END OF LINE);


Suggested change

1. if the [computed][] [`display`][display] property of the [element][] has an [outer display type][] of `block`, or an [inner display type][] of `table-caption`, the visible inner text of the [element][] is the concatenation of is `"\n"` (U+000A END OF LINE) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus another `"\n"` (U+000A END OF LINE);

1. if the [computed][] [`display`][display] property of the [element][] has an [outer display type][] of `block`, or an [inner display type][] of `table-caption`, the visible inner text of the [element][] is the concatenation of `"\n"` (U+000A END OF LINE) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus another `"\n"` (U+000A END OF LINE);

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.

dan-tripp-siteimprove and others added 20 commits April 16, 2026 19:25

passed example 8: rewording.

c01ccfa

Passed Example 11: adding "fragment link" to visible-inner-text:for-t…

fd8029c

…ext-clause-2.

fixing previous commit

b50d890

fixing previous commit

6816e7b

tweaking previous commit

dd9d7f1

another tweak

e0b890a

another tweak

b9460bf

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

29e576b

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

Passed Example 9: changing from p to div as per Jym's review.

5aa55e6

Also removing whitespace between the divs. Doing this because that whitespace was introduced accidentally in commit 5617755 (which was a merge).

removing two references to "previous example"

901e0d3

Failed Example 12 (adding href)

df65c5b

removing "same as above" reference.

b2374d7

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

61d2d48

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

using unicode spec notation eg. "U+0028 LEFT PARENTHESIS".

5d5e8bd

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

40525f4

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

adding link to unicode categories

bf9bf6a

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

964ec63

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

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

b5ca23b

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

moving the "Remove parentheses" step.

e6dc5c8

as per act-rules#2075 (comment) this fixes a big problem that has been there since the beginning of this PR i.e. three years.

Merge branch 'rule-2ee8b8-may-2023' of https://github.com/dan-tripp-s…

1d084ce

…iteimprove/act-rules.github.io into rule-2ee8b8-may-2023

Jym77 removed the Agenda item label Apr 27, 2026

dan-tripp-siteimprove added 4 commits May 4, 2026 17:56

replacing "sublist" with "contiguous subsequence".

020300c

as per act-rules#2075 (comment)

oops

b01f57a

oops again.

94fcd8c

assumptions > brackets > handling a link named "Dune (1984 film)".

64fe779

as per act-rules#2075 (comment)

dan-tripp-siteimprove requested a review from Jym77 May 4, 2026 22:18

Jym77 and others added 2 commits May 21, 2026 11:22

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

92e86ab

Fix typo and syntax errors

2f42547

Jym77 requested changes May 21, 2026

View reviewed changes

Remove unused definition

5dd2d0b


		This rule assumes that the visible label doesn't use CSS to add whitespace where none exists in the DOM.

		This rule - specifically, the [label in name algorithm][] that this rule relies on - assumes that content within parentheses can be ignored. ("Parentheses" are also known as "round brackets".) This is important becuase the algorithm's treatment of parentheses is to remove them and all characters within them. This assumption is almost always true in English. Exceptions include links with names such "Dune (1984 film)" and "Dune (2021 film)". This assumption is known to be often false in languages other than English, such as German (where parentheses indicate dual states) and Arabic (where parentheses are often used as quotation marks). Violations of this assumption will, in real-world scenarios, more often result in a false negative for this rule rather than a false positive.

	This button has [visible inner text][] that does not need to be contained within the [accessible name][], because the "x" text node is [non-text content][]. Note: this would need to meet SC 1.1.1 Non text content.
	This button has [visible inner text][] that does not need to be contained within the [accessible name][], because the "X" text node is [non-text content][]; the [label in name algorithm][] therefore ignores it. Note: this would need to meet SC 1.1.1 Non text content.

	This `button` element has the text "search" rendered as a magnifying glass icon by the font. Because the text is rendered as [non-text content][], the text does not need to be contained within the [accessible name][].
	This `button` element has the text "search" rendered as a magnifying glass icon by the font. Because the text is rendered as [non-text content][], the text does not need to be contained within the [accessible name][]; and the [label in name algorithm][] ignores it.


		#### Passed Example 9

		The [visible inner text][] of this link is "ACT" (with no spaces) because of the explicit styles of `display: inline` on the `p` elements and the absence of whitespace between the `div` elements. The cases of `display: inline` and `display: block` are handled by the definition of [visible inner text of an element][]. This example shows that the definition agrees with the visual rendering done by the browser.

	1. <span id="visible-inner-text:for-text-clause-2">if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);</span>
	1. (<dfn id="visible-inner-text:text-whitespace>Whitespace</dfn>): if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);

	- A consequence of using the ACT definition of [whitespace][] here is that all kinds of whitespace are covered. That includes the Unicode code point U+00A0 NO-BREAK SPACE (NBSP), which can be represented by the HTML named character reference ` `.
	- A consequence of using the ACT definition of [whitespace][] here is that all kinds of whitespace are covered. That includes the Unicode code point U+00A0 NO-BREAK SPACE (NBSP), which can be represented by the HTML named character reference ` `.

	- The "contiguous" aspect means that it's crucial that the elements are consecutive in the original list. Put another way: a contiguous subsequence of X can be obtained by removing any number of tokens from the start and/or end (but not the middle) of X. For example: ["A", "B", "C"] is a contiguous subsequence of ["A", "B", "C", "D"]. ["A", "B", "D"] is not.
	- The "contiguous" aspect means that it's crucial that the elements are consecutive in the original list. Put another way: a contiguous subsequence of X can be obtained by removing any number of tokens from the start and/or end (but not the middle) of X. For example: ["A", "B", "C"] is a contiguous subsequence of ["A", "B", "C", "D"]; but ["A", "B", "D"] is not.

	1. <span id="visible-inner-text:for-text-clause-2">if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);</span>
	1. (<dfn id="visible-inner-text:text-whitespace">Whitespace</dfn>): if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);

	1. if the [computed][] [`display`][display] property of the [element][] has an [outer display type][] of `block`, or an [inner display type][] of `table-caption`, the visible inner text of the [element][] is the concatenation of is `"\n"` (U+000A END OF LINE) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus another `"\n"` (U+000A END OF LINE);
	1. if the [computed][] [`display`][display] property of the [element][] has an [outer display type][] of `block`, or an [inner display type][] of `table-caption`, the visible inner text of the [element][] is the concatenation of `"\n"` (U+000A END OF LINE) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus another `"\n"` (U+000A END OF LINE);

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!

Jym77 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

17 participants

dan-tripp-siteimprove commented Jun 22, 2023 •

edited by Jym77

Loading