diff --git a/.github/ISSUE_TEMPLATE/rules-issue-template.md b/.github/ISSUE_TEMPLATE/rules-issue-template.md
index 54d7c5fd887..d3cab5eed18 100644
--- a/.github/ISSUE_TEMPLATE/rules-issue-template.md
+++ b/.github/ISSUE_TEMPLATE/rules-issue-template.md
@@ -4,10 +4,7 @@ about: issues related with ACT Rules
 title: ''
 labels: ''
 assignees: ''
-
----
-
-Please describe the issue with references and relevant examples where necessary.
+---Please describe the issue with references and relevant examples where necessary.
 
 --- or ---
 
diff --git a/__tests__/spelling-ignore.yml b/__tests__/spelling-ignore.yml
index 85d7b20914d..a9106eec1f6 100644
--- a/__tests__/spelling-ignore.yml
+++ b/__tests__/spelling-ignore.yml
@@ -136,7 +136,7 @@
 - ozplayer
 - GitHub
 
-# Test case anamolies
+# Test case anomalies
 - brewitt-taylor
 - level2-frame1
 - level1-frame2
@@ -146,6 +146,9 @@
 - Sumei
 - Tuttle
 - lnik # intentional misspelling
+- ngizmo
+- nspecification
+- thelabel
 
 # Attributes (repeated words with casing as retext-spell has no config to ignore casing)
 - href
@@ -177,6 +180,9 @@
 - x1
 - y1
 
+# HTML character references
+- nbsp
+
 # DOM Events
 - auxclick
 - compostionend
@@ -243,6 +249,12 @@
 - disambiguated
 - superclass
 - grey
+- substring
+- initialisms
+- sublist
+- tokenize
+- tokenized
+- subsequence
 
 # Parts of Unicode
 - 000A
@@ -252,6 +264,8 @@
 - 4E00
 - 9FFF
 - 4E00–9FFF
+- 00A0
+- KD
 
 # JSON attributes/ metadata/ methods
 - examples
diff --git a/__tests__/spelling.js b/__tests__/spelling.js
index c5f09b69197..6a6a420e7d4 100755
--- a/__tests__/spelling.js
+++ b/__tests__/spelling.js
@@ -109,7 +109,9 @@ function getCuratedMarkdownBody(body, options = {}) {
  * @returns {String[]}
  */
 function getSpellIgnored() {
-	const ignoreConfigured = yaml.load(fs.readFileSync('./__tests__/spelling-ignore.yml', 'utf8'), {schema: yaml.FAILSAFE_SCHEMA}) //added schema due to entries starting with a non-zero digit
+	const ignoreConfigured = yaml.load(fs.readFileSync('./__tests__/spelling-ignore.yml', 'utf8'), {
+		schema: yaml.FAILSAFE_SCHEMA,
+	}) //added schema due to entries starting with a non-zero digit
 
 	/*
 	Building spelling exception in the shape FOOxxx where xxx is a number.
diff --git a/_rules/focusable-no-keyboard-trap-standard-nav-a1b64e.md b/_rules/focusable-no-keyboard-trap-standard-nav-a1b64e.md
index 9ed44c9b6c5..10a546fcdbc 100755
--- a/_rules/focusable-no-keyboard-trap-standard-nav-a1b64e.md
+++ b/_rules/focusable-no-keyboard-trap-standard-nav-a1b64e.md
@@ -88,43 +88,43 @@ use [standard keyboard navigation](#standard-keyboard-navigation) using the Esca
 ```html
 <div>Main page content with <a href="#">some link</a></div>
 <div aria-hidden="true">
-    <a href="#" id="sentinelBefore" style="position:absolute; top:-999em"
-        >Upon receiving focus, this focus sentinel should wrap focus to the bottom of the modal</a
-    >
+	<a href="#" id="sentinelBefore" style="position:absolute; top:-999em"
+		>Upon receiving focus, this focus sentinel should wrap focus to the bottom of the modal</a
+	>
 </div>
 <div
-    id="sampleModal"
-    role="dialog"
-    aria-label="Sample Modal"
-    aria-modal="true"
-    style="border: solid black 1px; padding: 1rem;"
+	id="sampleModal"
+	role="dialog"
+	aria-label="Sample Modal"
+	aria-modal="true"
+	style="border: solid black 1px; padding: 1rem;"
 >
-    <label>First and last name <input id="dialogFirst"/></label><br />
-    <button id="closeButton">Close button</button>
+	<label>First and last name <input id="dialogFirst"/></label><br />
+	<button id="closeButton">Close button</button>
 </div>
 <div aria-hidden="true">
-    <a href="#" id="sentinelAfter" style="position:absolute; top:-999em"
-        >Upon receiving focus, this focus sentinel should wrap focus to the top of the modal</a
-    >
+	<a href="#" id="sentinelAfter" style="position:absolute; top:-999em"
+		>Upon receiving focus, this focus sentinel should wrap focus to the top of the modal</a
+	>
 </div>
 <script>
-    window.addEventListener('load', () => {
-        document.getElementById('dialogFirst').focus();
-    })
-    document.getElementById('sentinelBefore').addEventListener('focus', () => {
-        document.getElementById('closeButton').focus()
-    })
-    document.getElementById('sentinelAfter').addEventListener('focus', () => {
-        document.getElementById('dialogFirst').focus()
-    })
-    document.getElementById('closeButton').addEventListener('click', () => {
-        document.getElementById('sampleModal').style.display = 'none'
-    })
-    document.getElementById('sampleModal').addEventListener('keydown', (evt) => {
-        if (evt.key === "Escape") {
-            document.getElementById('sampleModal').style.display = 'none';    
-        }
-    })
+	window.addEventListener('load', () => {
+		document.getElementById('dialogFirst').focus()
+	})
+	document.getElementById('sentinelBefore').addEventListener('focus', () => {
+		document.getElementById('closeButton').focus()
+	})
+	document.getElementById('sentinelAfter').addEventListener('focus', () => {
+		document.getElementById('dialogFirst').focus()
+	})
+	document.getElementById('closeButton').addEventListener('click', () => {
+		document.getElementById('sampleModal').style.display = 'none'
+	})
+	document.getElementById('sampleModal').addEventListener('keydown', evt => {
+		if (evt.key === 'Escape') {
+			document.getElementById('sampleModal').style.display = 'none'
+		}
+	})
 </script>
 ```
 
diff --git a/_rules/presentational-children-no-focusable-content-307n5z.md b/_rules/presentational-children-no-focusable-content-307n5z.md
index 1231ffd4c66..6c2d285c774 100755
--- a/_rules/presentational-children-no-focusable-content-307n5z.md
+++ b/_rules/presentational-children-no-focusable-content-307n5z.md
@@ -43,7 +43,7 @@ This rule assumes that elements that are part of [sequential focus navigation][]
 
 Several major browsers ignore the WAI-ARIA requirements on [presentational children][] for most or sometimes all roles, or in presence of focusable content. Since some browsers implement presentational children while others do not, pages failing this rule may only be problematic with some browsers.
 
-This rule is often misunderstood as applying to elements with an _explicit_ role of `presentation`.  In fact, this rule only applies to elements which have been given an _implicit_ role of `presentation` through the [presentational children][] mechanism.  Similarly, this rule does not apply to elements with `aria-hidden="true"`.
+This rule is often misunderstood as applying to elements with an _explicit_ role of `presentation`. In fact, this rule only applies to elements which have been given an _implicit_ role of `presentation` through the [presentational children][] mechanism. Similarly, this rule does not apply to elements with `aria-hidden="true"`.
 
 ### Related rules
 
@@ -97,13 +97,12 @@ This element with the `menuitemcheckbox` role has an `input` element as a descen
 
 #### Passed Example 4
 
-This `<button>` element has an `a` element as a [child][].  The `a` element has no `href` attribute, so it isn't included in [sequential focus navigation][].  So this `button` element passes the rule.
+This `<button>` element has an `a` element as a [child][]. The `a` element has no `href` attribute, so it isn't included in [sequential focus navigation][]. So this `button` element passes the rule.
 
 ```html
 <button><a>button/link</a></button>
 ```
 
-
 ### Failed
 
 #### Failed Example 1
@@ -140,7 +139,7 @@ This element with the `menuitemcheckbox` role has a checkbox as a child. Because
 
 #### Failed Example 4
 
-This element with the `tab` role contains an `a` element.  The `tab` role has [presentational children][].  The `a` element is included in [sequential focus navigation][].  So the element with the `tab` role fails the rule.  (This tablist implementation is non-functional for users.  It's not meant to function - it's only meant to show roles.)
+This element with the `tab` role contains an `a` element. The `tab` role has [presentational children][]. The `a` element is included in [sequential focus navigation][]. So the element with the `tab` role fails the rule. (This tablist implementation is non-functional for users. It's not meant to function - it's only meant to show roles.)
 
 ```html
 <ul role="tablist">
@@ -152,7 +151,7 @@ This element with the `tab` role contains an `a` element.  The `tab` role has [p
 
 #### Failed Example 5
 
-This element with the `img` role contains an `a` element.  The `img` role has [presentational children][].  The `a` element is included in [sequential focus navigation][].  So the element with the `img` role fails the rule.
+This element with the `img` role contains an `a` element. The `img` role has [presentational children][]. The `a` element is included in [sequential focus navigation][]. So the element with the `img` role fails the rule.
 
 ```html
 <span role="img" aria-label="some ASCII art">****** This ASCII art ******* <a href="#">contains a link.</a></span>
@@ -162,7 +161,7 @@ This element with the `img` role contains an `a` element.  The `img` role has [p
 
 #### Inapplicable Example 1
 
-None of the roles that build this semantic table structure (`table` for `table`, `row` for `tr`, `columnheader` for `th`, and `cell` for `td`) have [presentational children][].  So this rule does not apply to them.
+None of the roles that build this semantic table structure (`table` for `table`, `row` for `tr`, `columnheader` for `th`, and `cell` for `td`) have [presentational children][]. So this rule does not apply to them.
 
 ```html
 <table>
@@ -181,7 +180,7 @@ None of the roles that build this semantic table structure (`table` for `table`,
 
 #### Inapplicable Example 2
 
-This `a` element has a `link` role, which does not have [presentational children][].  So this `a` element does not fail this rule, because it's inapplicable.  To have a "focusable element within a focusable element" like this is a bad practice, but this rule doesn't directly check for it.
+This `a` element has a `link` role, which does not have [presentational children][]. So this `a` element does not fail this rule, because it's inapplicable. To have a "focusable element within a focusable element" like this is a bad practice, but this rule doesn't directly check for it.
 
 ```html
 <a href="https://w3.org"><span tabindex="0">W3C Website</span></a>
diff --git a/_rules/role-attribute-valid-value-674b10.md b/_rules/role-attribute-valid-value-674b10.md
index ec2d9ea3f18..129bf76ff82 100755
--- a/_rules/role-attribute-valid-value-674b10.md
+++ b/_rules/role-attribute-valid-value-674b10.md
@@ -167,7 +167,7 @@ This `role` attribute is empty ("").
 This `role` attribute is only [ASCII whitespace][].
 
 ```html
-<input type="text" role=" " aria-label="field name"/>
+<input type="text" role=" " aria-label="field name" />
 ```
 
 #### Inapplicable Example 5
diff --git a/_rules/role-required-states-and-properties-4e8ab6.md b/_rules/role-required-states-and-properties-4e8ab6.md
index 425a9800d6a..5a25dc2b3d1 100755
--- a/_rules/role-required-states-and-properties-4e8ab6.md
+++ b/_rules/role-required-states-and-properties-4e8ab6.md
@@ -121,7 +121,7 @@ This `combobox` has the required properties `aria-controls` and `aria-expanded`.
 
 ```html
 <label for="tag_combo" id="tag_label">Tag</label>
-<input type="text" id="tag_combo" role="combobox" aria-expanded="true" aria-controls="popup_listbox"/>
+<input type="text" id="tag_combo" role="combobox" aria-expanded="true" aria-controls="popup_listbox" />
 <ul role="listbox" id="popup_listbox" aria-labelledby="tag_label">
 	<li role="option">Zebra</li>
 	<li role="option" id="selected_option">Zoom</li>
@@ -197,7 +197,7 @@ This `div` does not have a [semantic role](#semantic-role).
 This `checkbox` has an [implicit semantic role](#implicit-role) that is identical to the [explicit semantic role](#explicit-role). This allows native HTML `checked` attribute to apply.
 
 ```html
-<input type="checkbox" role="checkbox" aria-label="Checkbox name"/>
+<input type="checkbox" role="checkbox" aria-label="Checkbox name" />
 ```
 
 #### Inapplicable Example 3
diff --git a/_rules/scrollable-element-keyboard-accessible-0ssw9k.md b/_rules/scrollable-element-keyboard-accessible-0ssw9k.md
index 755cb0113f1..2938bab8584 100755
--- a/_rules/scrollable-element-keyboard-accessible-0ssw9k.md
+++ b/_rules/scrollable-element-keyboard-accessible-0ssw9k.md
@@ -40,8 +40,9 @@ This rule applies to any [HTML element][] that has [visible][] [children][] in t
 
 ## Expectation
 
-For each target element, at least one of the following is true: 
-- the element is included in [sequential focus navigation][]; or 
+For each target element, at least one of the following is true:
+
+- the element is included in [sequential focus navigation][]; or
 - the element has a [descendant][] in the [flat tree][] that is included in [sequential focus navigation][]; or
 - the element is [inert][].
 
@@ -119,7 +120,7 @@ This [scrollable][] `section` element is [inert][] because of the modal dialog,
 ```html
 <style>
 	dialog:-internal-dialog-in-top-layer::backdrop {
-    		background: rgba(1, 1, 1, 0.8);
+		background: rgba(1, 1, 1, 0.8);
 	}
 </style>
 <section style="height: 100px; width: 500px; overflow: scroll;" tabindex="0">
@@ -144,11 +145,11 @@ This [scrollable][] `section` element is [inert][] because of the modal dialog,
 </dialog>
 <script>
 	const openDialog = () => {
-		ppDialog.showModal();
+		ppDialog.showModal()
 		myFrame.tabIndex = '-1'
 	}
-	ppDialog.addEventListener('close', () => myFrame.tabIndex = 0)
-	window.addEventListener('DOMContentLoaded', openDialog);
+	ppDialog.addEventListener('close', () => (myFrame.tabIndex = 0))
+	window.addEventListener('DOMContentLoaded', openDialog)
 </script>
 ```
 
diff --git a/_rules/video-transcript-1a02b0.md b/_rules/video-transcript-1a02b0.md
index d48baba56be..8cce2e7f8b6 100755
--- a/_rules/video-transcript-1a02b0.md
+++ b/_rules/video-transcript-1a02b0.md
@@ -17,7 +17,7 @@ accessibility_requirements:
     passed: further testing needed
     inapplicable: further testing needed
   wcag20:1.3.1: # Info and Relationships (A)
-    secondary: This success criterion is **related** to this rule. This is because this criterion applies to a visible transcript.  
+    secondary: This success criterion is **related** to this rule. This is because this criterion applies to a visible transcript.
   wcag20:1.2.1: # Audio-only and Video-only (Prerecorded) (A)
     secondary: This success criterion is **less strict** than this rule. This is because this criterion does not require a transcript when the audio-only or video-only is a media alternative for text and is clearly labeled as such. Some of the failed examples may satisfy this success criterion.
 input_aspects:
@@ -128,7 +128,12 @@ A video element with an associated track element that contains captions for all
 	<video src="/test-assets/perspective-video/perspective-video.mp4" controls>
 		<track src="/test-assets/perspective-video/perspective-caption.vtt" kind="captions" />
 	</video>
-	<p>	Web Accessibility Perspectives: Keyboard Accessibility. Not being able to use your computer because your mouse doesn't work, is frustrating. (A computer user's mouse breaks when it falls off the desk.) Many people use only the keyboard to navigate websites. Either through preference or 		circumstance. (A person wearing a sling on her arm typing with one hand.) </p>
+	<p>
+		Web Accessibility Perspectives: Keyboard Accessibility. Not being able to use your computer because your mouse
+		doesn't work, is frustrating. (A computer user's mouse breaks when it falls off the desk.) Many people use only the
+		keyboard to navigate websites. Either through preference or circumstance. (A person wearing a sling on her arm
+		typing with one hand.)
+	</p>
 </html>
 ```
 
diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md
index 65daa251c21..ab2bd4b7df6 100755
--- a/_rules/visible-label-in-accessible-name-2ee8b8.md
+++ b/_rules/visible-label-in-accessible-name-2ee8b8.md
@@ -24,6 +24,7 @@ acknowledgments:
   authors:
     - Anne Thyme Nørregaard
     - Bryn Anderson
+    - Dan Tripp
     - Jey Nandakumar
   funding:
     - WAI-Tools
@@ -36,10 +37,13 @@ This rule applies to any element for which all the following is true:
 - The element has a [semantic role][] that is a [widget][widget role] that [supports name from content][]; and
 - 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.
+- Both the element's accessible name and its visible label do not contain any abbreviations.
 
 ## Expectation
 
-For each target element, all [text nodes][] in the [visible text content][] [match characters][] and 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 the target element, the [visible inner text][] is contained within the [accessible name][] according to the [label in name algorithm][].
 
 ## Background
 
@@ -49,7 +53,13 @@ The understanding document of [2.5.3 Label in Name][understand253] use the term
 
 ### Assumptions
 
-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).
+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], even though "label" is not precisely defined at this point in history.
+
+This rule assumes that the visible label isn't rearranged with CSS so that it appears to the user in a different order than it appears in the DOM.
+
+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 the algorithm's treatment of parentheses is appropriate in the given human language. "Parentheses" are also known as "round brackets". The algorithm's treatment of parentheses is to remove them and all characters within them. This assumption can be reworded as: content within parentheses can be ignored. This assumption is almost always true in English. It is known to be often false in other languages, 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.
 
 ### Accessibility Support
 
@@ -66,7 +76,7 @@ Implementation of [Presentational Roles Conflict Resolution][] varies from one b
 
 #### 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>
@@ -74,23 +84,23 @@ This link has [visible][] text that matches the [accessible name][].
 
 #### 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>
@@ -98,7 +108,7 @@ This button has [visible][] text that is contained within the [accessible name][
 
 #### 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.
 
 ```html
 <button aria-label="anything">X</button>
@@ -106,7 +116,7 @@ This button has [visible][] text that does not need to be contained within the [
 
 #### 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][].
 
 ```html
 <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet" />
@@ -118,11 +128,119 @@ 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.
+
+```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][] 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 `p` 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.
+
+```html
+<a href="#" aria-label="ACT">
+	<p style="display: inline">A</p>
+	<p style="display: inline">C</p>
+	<p style="display: inline">T</p>
+</a>
+```
+
+#### Passed Example 10
+
+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 11
+
+The [visible inner text][] is "Download specification", which includes a space character between the two words due to the second clause of the definition of [visible inner text of a text node][].
+
+```html
+<a aria-label="Download specification" href="#"
+	><span>Download</span><span id="space"> </span><span>specification</span></a
+>
+```
+
+#### Passed Example 12
+
+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 13
+
+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 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.
+
+```html
+<button aria-label="Search by date">Search by date (YYYY-MM-DD)</button>
+```
+
+#### Passed Example 15
+
+This 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 16
+
+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 💡">&gt;&gt;&gt; ** Submit ** &lt;&lt;&lt;</button>
+```
+
 ### 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>
@@ -130,7 +248,7 @@ This link has [visible][] text that is different from the [accessible name][].
 
 #### 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>
@@ -138,33 +256,121 @@ This button has [visible][] text that is only partially contained within the [ac
 
 #### Failed Example 3
 
-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/WCAG22/Understanding/label-in-name#mathematical-expressions-and-formulae).
+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="Proof of two multiplied by two is four">Proof of 2&times;2=4</a>
+<a href="#" aria-label="Discover Italy">Discover It</a>
 ```
 
 #### Failed Example 4
 
-This link has [visible][] text does not match the [accessible name][] because there is a hyphen in the accessible name.
+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 href="#" aria-label="non-standard">nonstandard</a>
+<a aria-label="just ice" href="#">justice</a>
 ```
 
 #### Failed Example 5
 
-This link has [visible][] text does not match the [accessible name][] because there are extra spaces in the accessible name.
+The rule has no special handling for acronyms or initialisms.
+
+```html
+<a aria-label="WCAG" href="#">W C A G</a>
+```
+
+#### Failed Example 6
+
+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/WCAG22/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 7
+
+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 8
+
+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 9
+
+This button's accessible name contains the word "the" in the middle of it, which causes the sublist check of the [label in name algorithm][] (in particular: the "consecutive" requirement of that check) to fail. So it fails the rule.
+
+```html
+<button aria-label="Download the specification">Download specification</button>
+```
+
+#### Failed Example 10
+
+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="1 2 3. 4 5 6. 7 8 9 0" href="tel:1234567890">123.456.7890</a>
 ```
 
+#### 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.
+
+```html
+<a href="#2021" aria-label="20 21">2021</a>
+```
+
+#### Failed Example 12
+
+Similar to the previous example.
+
+```html
+<a aria-label="fibonacci: 0 1 1 2 3 5 8 13 21 34">fibonacci: 0112358132134</a>
+```
+
+#### Failed Example 13
+
+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 14
+
+(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 15
+
+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 16
+
+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>
@@ -172,7 +378,7 @@ This `nav` is not a widget, so the [visible][] text does not need to match the [
 
 #### 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 text field 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 text field instead.
 
 ```html
 <div>E-mail</div>
@@ -181,7 +387,7 @@ 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][] does not need to match the [accessible name][].
 
 ```html
 <div role="tooltip" aria-label="OK">Next</div>
@@ -189,7 +395,7 @@ This `div` element does not have a widget role, so the [visible][] text does not
 
 #### 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">
@@ -197,15 +403,23 @@ This link has no [visible text content][].
 </a>
 ```
 
+#### Inapplicable Example 5
+
+This link's label contains an abbreviation, so it is not applicable.
+
+```html
+<a aria-label="University Avenue" href="#">University Ave.</a>
+```
+
 [accessible name]: #accessible-name 'Definition of accessible name'
-[match characters]: #matching-characters 'Definition of matching characters'
+[label in name algorithm]: #label-in-name-algorithm 'Definition of Label in Name Algorithm'
 [non-text content]: https://www.w3.org/TR/WCAG22/#dfn-non-text-content 'WCAG Definition of Non-text content'
 [presentational roles conflict resolution]: https://www.w3.org/TR/wai-aria-1.2/#conflict_resolution_presentation_none 'Presentational Roles Conflict Resolution'
 [semantic role]: #semantic-role 'Definition of Semantic role'
-[supports name from content]: https://www.w3.org/TR/wai-aria-1.2/#namefromcontent 'Definition of Supports name from contents'
-[visible]: #visible 'Definition of visible'
+[supports name from content]: https://www.w3.org/TR/wai-aria-1.2/#namefromcontent 'Definition of Supports name from content'
+[understand253]: https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html
+[visible inner text]: #visible-inner-text 'Definition of Visible inner text'
+[visible inner text of a text node]: #visible-inner-text:for-text 'Definition of Visible inner text of a text node'
+[visible inner text of an element]: #visible-inner-text:for-element 'Definition of Visible inner text of an element'
 [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.2/#widget_roles 'Definition of Widget role'
-[text nodes]: https://dom.spec.whatwg.org/#text 'DOM text, 2020/08/18'
-[understand253]: https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html
diff --git a/package.json b/package.json
index 893ff5cdfc8..1d70f39625c 100644
--- a/package.json
+++ b/package.json
@@ -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"
diff --git a/pages/design/rule-design.md b/pages/design/rule-design.md
index a221449a011..9f77c214add 100755
--- a/pages/design/rule-design.md
+++ b/pages/design/rule-design.md
@@ -105,25 +105,27 @@ While optional, this can provide information on authors, previous authors, and o
 
 Applicability describes which (elements of) web pages should be tested using the rule. These elements are known as test targets. Applicability must be written in plain language, as well-formed grammatically correct sentences, so that it can be used by QA testers. Applicability must rely on well defined properties of the technologies that are tested. For instance, a rule may be applicable to all `video` elements, but it can not be applicable to all `object` elements used to show video, unless the term "video" is further defined.
 
-The applicability of a rule must be unambiguous and should be written using objective statements and in plain language. Finding objective definitions to use in rules can be difficult, if not outright impossible in some cases. New in version 1.1 of the ACT rules format is the ability to write rules using a subjective applicability. For rules that include a subjectivity, it is preferred to include a list of features (either in line or as part of a definition) that describes how an element should be evaluated for matching the accessibility (see the "Styled as a Heading" example in the  [ACT Rules Format: Applicability](https://www.w3.org/TR/act-rules-format/#applicability)). Additionally, in the past, exception statements have been included in the Expectation that can now be directly placed in the applicability. Placing exceptions in the Applicability is now the recommended approach when the test subject is inapplicable, instead of artificially making the test subject pass the rule by having the subjectivity in the expectation (see the "Subjectivity in Applicability vs Expectation" example below). As a reminder, the intent here is to ensure repeatability of the rule.
+The applicability of a rule must be unambiguous and should be written using objective statements and in plain language. Finding objective definitions to use in rules can be difficult, if not outright impossible in some cases. New in version 1.1 of the ACT rules format is the ability to write rules using a subjective applicability. For rules that include a subjectivity, it is preferred to include a list of features (either in line or as part of a definition) that describes how an element should be evaluated for matching the accessibility (see the "Styled as a Heading" example in the [ACT Rules Format: Applicability](https://www.w3.org/TR/act-rules-format/#applicability)). Additionally, in the past, exception statements have been included in the Expectation that can now be directly placed in the applicability. Placing exceptions in the Applicability is now the recommended approach when the test subject is inapplicable, instead of artificially making the test subject pass the rule by having the subjectivity in the expectation (see the "Subjectivity in Applicability vs Expectation" example below). As a reminder, the intent here is to ensure repeatability of the rule.
 
 > _For example:_ A rule testing that page titles are descriptive should only apply to specific `title` elements and this could be stated as _"This rule applies to the first HTML `title` element that is a descendant of the `html` element of a web page, and contains children that are text nodes that are not only whitespace."_.
 
 ### Subjectivity in Applicability vs Expectation Examples
 
-With the development of ACT Rules format 1.1, subjectivity is now allowed in both the Applicability and the Expectation. However, depending on the rule, it can be difficult to know if a subjective phrase belongs in the Applicability or the Expectation. While we will continue to rely on the best judgment of the rule authors, most S.C. contain language suggesting where the subjectivity be placed. Lastly, at the bottom of this section, we provide some concrete examples of each of the cases below to help illustrate our point. 
+With the development of ACT Rules format 1.1, subjectivity is now allowed in both the Applicability and the Expectation. However, depending on the rule, it can be difficult to know if a subjective phrase belongs in the Applicability or the Expectation. While we will continue to rely on the best judgment of the rule authors, most S.C. contain language suggesting where the subjectivity be placed. Lastly, at the bottom of this section, we provide some concrete examples of each of the cases below to help illustrate our point.
 
-When determining the placement of subjectivity in an ACT rule, the main question to answer is whether the success criterion would apply at all to the given content or if the content would satisfy the criteria via a normative exception. For example, 
- - For SC 1.4.3 Contrast Minimum, non-text content or text that is not expressing something in human language (like an emoji) is not evaluated by the success criterion and so should not be applicable in an ACT rule for 1.4.3
- - For SC 1.4.3 Contrast Minimum, logos are a normative exception to the success criterion, so they should be included as a passed exception to the Expectation for an ACT rule testing 1.4.3.
- - For SC 2.5.5 Target Size (Enhanced), a link inside of a paragraph of text and a pin on a map would fit the normative exceptions of "Inline" and "Essential" respectively, and so should be included as passed exceptions in the Expectation. 
- - For SC 3.3.1 Error Identification, a page should not be applicable for an ACT rule until a form field error indicator exists, thus the presence of a form field error indicator should be included in the rule's applicability.
+When determining the placement of subjectivity in an ACT rule, the main question to answer is whether the success criterion would apply at all to the given content or if the content would satisfy the criteria via a normative exception. For example,
+
+- For SC 1.4.3 Contrast Minimum, non-text content or text that is not expressing something in human language (like an emoji) is not evaluated by the success criterion and so should not be applicable in an ACT rule for 1.4.3
+- For SC 1.4.3 Contrast Minimum, logos are a normative exception to the success criterion, so they should be included as a passed exception to the Expectation for an ACT rule testing 1.4.3.
+- For SC 2.5.5 Target Size (Enhanced), a link inside of a paragraph of text and a pin on a map would fit the normative exceptions of "Inline" and "Essential" respectively, and so should be included as passed exceptions in the Expectation.
+- For SC 3.3.1 Error Identification, a page should not be applicable for an ACT rule until a form field error indicator exists, thus the presence of a form field error indicator should be included in the rule's applicability.
 
 When making these determinations, it may be helpful to consider the following circumstances:
- - If a page contained only the specific example, would you expect it to pass or be deemed inapplicable for an ACT rule? Passing would imply the subjectivity belongs in the Expectation, while being inapplicable suggests it belongs in the Applicability.
- - Does the formulation of applicability and expectation lead to test cases passing when they should be deemed inapplicable? If so, subjectivity likely needs to be added to the Applicability (possibility moved from the Expectation to the Applicability)
 
-As a final reminder, the end goal of allowing subjectivity in the applicability is to allow the creation of rules that were previously impossible and to prevent rules from creating passed examples that are inapplicable to the success criteria the rule is intended to test. 
+- If a page contained only the specific example, would you expect it to pass or be deemed inapplicable for an ACT rule? Passing would imply the subjectivity belongs in the Expectation, while being inapplicable suggests it belongs in the Applicability.
+- Does the formulation of applicability and expectation lead to test cases passing when they should be deemed inapplicable? If so, subjectivity likely needs to be added to the Applicability (possibility moved from the Expectation to the Applicability)
+
+As a final reminder, the end goal of allowing subjectivity in the applicability is to allow the creation of rules that were previously impossible and to prevent rules from creating passed examples that are inapplicable to the success criteria the rule is intended to test.
 
 For more details, see [ACT Rules Format: Applicability](https://www.w3.org/TR/act-rules-format/#applicability).
 
diff --git a/pages/glossary/label-in-name-algorithm.md b/pages/glossary/label-in-name-algorithm.md
new file mode 100755
index 00000000000..875e3bb3515
--- /dev/null
+++ b/pages/glossary/label-in-name-algorithm.md
@@ -0,0 +1,42 @@
+---
+title: Label in Name Algorithm
+key: label-in-name-algorithm
+unambiguous: true
+objective: false
+input_aspects:
+  - CSS styling
+  - DOM tree
+---
+
+To check whether an [element][] has <dfn>its label contained in its name</dfn>, follow this algorithm:
+
+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.
+
+Sub-algorithm to tokenize a string:
+
+1. Do Unicode [case folding][] on the string then convert it to [normalization form KD][].
+1. 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.
+    - For a) Judgment of "non-text" probably can't be fully automated.  For example: "X" for "close" probably can be automated, 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.)
+1. Remove parentheses (also known as round brackets) and all characters that are between an opening and closing parenthesis.
+    - Don't do this for square brackets, nor braces.
+1. Split the string into a list of strings, one string per word, according to the word segmentation rules for the inherited programmatic language.
+    - This 'split' operation must:
+        - 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 - the "No-Break Space" - which can be represented by the HTML named character reference `&nbsp;`.
+
+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.  That is: 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" (that is: the tokenized 'label' is a sublist of the tokenized 'name'), then this algorithm returns "is contained".  Otherwise, it returns "is not contained".
+
+[accessible name]: #accessible-name 'Definition of accessible name'
+[case folding]: https://www.w3.org/TR/charmod-norm/#dfn-case-folding
+[element]: https://dom.spec.whatwg.org/#element
+[normalization form KD]: https://www.unicode.org/glossary/#normalization_form_kd
+[visible inner text]: #visible-inner-text 'Definition of Visible inner text'
+[whitespace][]: #whitespace 'Definition of whitespace'
diff --git a/pages/glossary/large-scale-text.md b/pages/glossary/large-scale-text.md
index 7efd8dd96dc..91f5660cc57 100755
--- a/pages/glossary/large-scale-text.md
+++ b/pages/glossary/large-scale-text.md
@@ -13,17 +13,17 @@ A text node is large scale text if at least one of the following is true:
 - the text node [computed][] [font-size][] is at least 18 [points][], or
 - the text node [computed][] [font-size][] is at least 14 [points][] and has a [computed][] [font weight][] of 700 or higher.
 
-
 #### Background
+
 In the domain of languages such as Chinese, Japanese, and Korean (CJK languages), encompassing the Unicode character range from 4E00 to 9FFF ([CJK Unified Ideographs](https://unicode.org/charts/PDF/U4E00.pdf)), it becomes crucial to acknowledge the intricate nuances in their typographic requirements. Despite sharing a common Unicode spectrum, each CJK language and its corresponding country may exhibit distinct typographic preferences and standards.
 
 Particularly noteworthy is the lack of uniformity in defining text sizes as either large or small within the following ranges:
+
 - from 18 [points][] to 22 [points][]
 - from 14 [points][] to 18 [points][] with a [computed][] [font weight][] of 700 or higher.
 
 Whether CJK characters in these ranges should be considered as "large scale" depends on the language of the text, as well as the country for which the text is designed and whose requirements must be followed. Given that these pieces of information are not readily available, the ACT rules adhere to the large text definition outlined above. This definition is applicable across all languages under the rationale of "no false positives."
 
-
 [computed]: https://www.w3.org/TR/css-cascade-3/#computed-value
 [font-size]: https://www.w3.org/TR/css-fonts-3/#propdef-font-size
 [points]: https://www.w3.org/TR/css-values/#pt
diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md
new file mode 100755
index 00000000000..4a3c629a934
--- /dev/null
+++ b/pages/glossary/visible-inner-text.md
@@ -0,0 +1,47 @@
+---
+title: Visible Inner Text
+key: visible-inner-text
+unambiguous: true
+objective: true
+input_aspects:
+  - CSS styling
+  - 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].)
+
+The <dfn>visible inner text of a node</dfn> depends on the kind of node. 
+
+The <dfn id="visible-inner-text:for-text">visible inner text of a [text node][]</dfn> is:
+-   if the [text node][] is [visible][], its visible inner text is its [data][] with whitespace normalized by replacing contiguous [whitespace][] with the string `" "` (a single ASCII space character);
+-   if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is the string `" "` (a single ASCII space character);
+-   otherwise, the visible inner text of the [text node][] is the empty string (`""`).
+
+
+The <dfn id="visible-inner-text:for-element">visible inner text of an [element][]</dfn> is:
+-   if the [element][] is not [rendered][], its visible inner text is the empty string (`""`);
+-   if the [element][] is [rendered][] and not [visible][] and has a [bounding box][] which has width greater than 0, its visible inner text is an ASCII space character (`" "`);
+-   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 (`""`);
+-   if the [element][] is a [`<br>`][<br>] element, its visible inner text is a newline character (`"\n"`);
+-   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 a newline character (`"\n"`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus a newline character (`"\n"`);
+-   if the [computed][] [`display`][display] property of the [element][] has an [inner display type][] of `table-cell` or `table-row`, the visible inner text of the [element][] is the concatenation of an ASCII space character (`" "`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus an ASCII space character (`" "`);
+-   otherwise, the visible inner text of the [element][] is the concatenation of the visible inner text of its children (in [tree order][] in the [flat tree][]).
+
+
+The <dfn>visible inner text</dfn> of any other node is the concatenation of the visible inner text of its children (in [tree order][] in the [flat tree][]).
+
+[bounding box]: https://www.w3.org/TR/css-ui-3/#valdef-box-sizing-border-box
+[<br>]: https://html.spec.whatwg.org/#the-br-element
+[computed]: https://drafts.csswg.org/css-cascade/#computed
+[data]: https://dom.spec.whatwg.org/#concept-cd-data
+[display]: https://drafts.csswg.org/css2/#propdef-display
+[element]: https://dom.spec.whatwg.org/#element
+[flat tree]: https://drafts.csswg.org/css-scoping/#flat-tree
+[inner display type]: https://drafts.csswg.org/css-display/#inner-display-type
+[outer display type]: https://drafts.csswg.org/css-display/#outer-display-type
+[rendered]: https://html.spec.whatwg.org/#being-rendered
+[text node]: https://dom.spec.whatwg.org/#text
+[tree order]: https://dom.spec.whatwg.org/#concept-tree-order
+[visible]: #visible
+[visible text content]: #visible-text-content
+[whitespace]: #whitespace
diff --git a/pages/glossary/visible-text-content.md b/pages/glossary/visible-text-content.md
index f39f0e0a150..c422e31173d 100755
--- a/pages/glossary/visible-text-content.md
+++ b/pages/glossary/visible-text-content.md
@@ -8,10 +8,12 @@ input_aspects:
   - DOM tree
 ---
 
-The _visible text content_ of an [element][] is a set of all [visible][] [text nodes][] that are [descendants][] in the [flat tree][] of this element
+The _visible text content_ of an [element][] is a set of all [visible][] [text nodes][] that are [descendants][] in the [flat tree][] of this element.  (This is similar to, but not the same as, [visible inner text][].)
+
 
 [descendants]: https://dom.spec.whatwg.org/#concept-tree-descendant 'DOM tree descendant, 2020/08/18'
 [element]: https://dom.spec.whatwg.org/#element 'DOM element, 2020/08/18'
 [flat tree]: https://drafts.csswg.org/css-scoping/#flat-tree 'CSS draft, flat tree, 2020/08/18'
 [visible]: #visible
+[visible inner text]: #visible-inner-text
 [text nodes]: https://dom.spec.whatwg.org/#text 'DOM text, 2020/08/18'