From a0215ed392c889393ab01bd1ead7188d0e8d4dc9 Mon Sep 17 00:00:00 2001
From: Kevin White <kevin@w3.org>
Date: Thu, 7 Mar 2024 10:43:13 +0000
Subject: [PATCH 1/8] Fix <span> (#3732)

Co-authored-by: Patrick H. Lauke <redux@splintered.co.uk>
Co-authored-by: Mike Gower <mikegower@gmail.com>
---
 understanding/21/non-text-contrast.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/understanding/21/non-text-contrast.html b/understanding/21/non-text-contrast.html
index 37d1b171a0..7a7d622b25 100644
--- a/understanding/21/non-text-contrast.html
+++ b/understanding/21/non-text-contrast.html
@@ -140,7 +140,7 @@ <h4 id="related-focus">Relationship with Focus Visible</h4>
 				<figure id="figure-focus-outer-green">
 					<img src="img/ntc-focus-outer-green.png" alt="Three blue buttons on a white background, the middle has a dark green outline outside of the botton's non-focused boundary." width="400" />
 					<figcaption>
-						The external green indicator (#008000) does contrast with the white background (#FFF) which the component is on, <strong>passing</strong> the criterion. It does not need to contrast with both the component background and the component, as visually the effect is that the button is noticeably larger, and it's not necessary for a user to be able to discern this extra border in isolation. Although this passes non-text contrast, it is not a good indicator unless it is very thick. <span class="wcag22">There is a AAA criterion in WCAG 2.2 that addresses this aspect, <a href="../22/focus-appearance.html">Focus Appearance</a>.
+						The external green indicator (#008000) does contrast with the white background (#FFF) which the component is on, <strong>passing</strong> the criterion. It does not need to contrast with both the component background and the component, as visually the effect is that the button is noticeably larger, and it's not necessary for a user to be able to discern this extra border in isolation. Although this passes non-text contrast, it is not a good indicator unless it is very thick. <span class="wcag22">There is a AAA criterion in WCAG 2.2 that addresses this aspect, <a href="../22/focus-appearance.html">Focus Appearance</a></span>.
 					</figcaption>
 				</figure>
 

From 6fc9553f79a184d797bfb8b32e12f52d563517cb Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" <redux@splintered.co.uk>
Date: Mon, 11 Mar 2024 16:23:36 +0000
Subject: [PATCH 2/8] 2.5.3 - control with label but no accname (understanding
 note + new failure technique) (#2057)

Also cleans-up 2.5.3 understanding document markup/structure
- adds new F111 Control with visible label text but no accname
(improperly numbered F109 initially)
- add failure technique in Understanding document
- added notes in Understanding about UI components with visible text and
no name failing both 4.1.2 and 2.5.3
- removed direct reference to WCAG 2.1
- resolved discussion with ACT on where to report some of the failure
examples

Closes #2045

---------

Co-authored-by: Alastair Campbell
Co-authored-by: Mike Gower
Co-authored-by: Scott O'Hara
Co-authored-by: Dan Bjorge
---
 techniques/failures/F111.html       |  83 ++++++++++++++++++
 techniques/failures/F96.html        |   1 +
 understanding/21/label-in-name.html | 128 +++++++++++++++-------------
 3 files changed, 153 insertions(+), 59 deletions(-)
 create mode 100644 techniques/failures/F111.html

diff --git a/techniques/failures/F111.html b/techniques/failures/F111.html
new file mode 100644
index 0000000000..d2a73fc8ba
--- /dev/null
+++ b/techniques/failures/F111.html
@@ -0,0 +1,83 @@
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
+	<head>
+		<title>Failure of Success Criteria 1.3.1, 2.5.3, and 4.1.2 due to a control with visible label text but no accessible name</title>
+		<link rel="stylesheet" type="text/css" href="../../css/editors.css"/>
+	</head>
+	<body>
+		<h1>Failure of Success Criteria 1.3.1, 2.5.3, and 4.1.2 due to a control with visible label text but no accessible name</h1>
+		<section id="meta">
+			<h2>Metadata</h2>
+			<p id="id"></p>
+			<p id="technology">general</p>
+			<p id="type">failure</p>
+		</section>
+
+		<section id="applicability">
+			<h2>When to Use</h2>
+			<p>All technologies that include interactive controls (such as links or form inputs).</p>
+		</section>
+
+		<section id="description">
+			<h2>Description</h2>
+			<p>The objective of this Failure is to describe situations where speech input users cannot reliably speak the name of a control because although it has a visible label, it lacks an accessible name.</p>
+			<p>When speech input users interact with a web page, they usually speak a command followed by the reference to some visible label (like the text in a button or a link, or the text labelling some input). If the control lacks an accessible name, speech users won't be able to activate the control using its visible label.</p>	
+		</section>
+		
+		<section id="examples">
+			<h2>Examples</h2>
+      
+      <section class="example">
+				<h3>A text input with a visible label, but without an accessible name</h3>
+				<p>The text input is preceded by a visible text label "Enter name", but the text is not marked up as a <code>&lt;label&gt;</code> for the input, and there is no alternative way (e.g., <code>aria-label</code>) to provide the input with an accessible name at all.</p>
+				<pre><code>
+					&lt;p&gt;Enter name&lt;/p&gt;
+					&lt;input type="text"&gt;
+        </code></pre>
+      </section>
+
+			<section class="example">
+				<h3>A text input with a visible label and aria-labelledby pointing to a non-existent id</h3>
+				<p>The text input is preceded by a visible text label "Enter name". The text's container has an <code>id</code> of <code>nameEntry</code>, but the input has an <code>aria-labelledby</code> referencing a non-existent <code>name-entry</code> <code>id</code>. As a result, the input lacks an accessible name altogether.</p>
+				<pre><code>
+					&lt;p id="nameEntry"&gt;Enter name&lt;/p&gt;
+					&lt;input type="text" aria-labelledby="name-entry" &gt;
+        </code></pre>
+      </section>
+    </section>
+    
+		<section id="tests">
+			<h2>Tests</h2>
+			<section class="test-procedure">
+				<h3>Procedure</h3>
+				<p>For all controls with a visible label (e.g., link text, button text, programmatically linked label, images in links or buttons with text, etc.), check that:</p>
+				<ol>
+					<li>The control has a visible text label.</li>
+					<li>The control has an accessible name.</li>
+          <li>The accessible name contains the text that appears as the visible label.</li>
+				</ol>
+			</section>
+			<section class="test-results">
+				<h3>Expected Results</h3>
+				<ul>
+					<li>If check #1 is false, the Success Criterion does not apply.</li>
+					<li>If check #1 is true, but checks #2 and/or #3 are false, the content fails the Success Criterion.</li>
+					<li>If all checks are true, the content passes the Success Criterion.</li>
+				</ul>
+			</section>
+		</section>
+		<section id="related">
+			<h2>Related Techniques</h2>
+			<ul>
+				<li><a href="../../techniques/general/F96">F96</a></li>
+        <li><a href="../../techniques/general/G131">G131</a></li>
+        <li><a href="../../techniques/aria/ARIA7">ARIA7</a></li>
+        <li><a href="../../techniques/aria/ARIA8">ARIA8</a></li>
+        <li><a href="../../techniques/aria/ARIA9">ARIA9</a></li>
+				<li><a href="../../techniques/aria/ARIA14">ARIA14</a></li>
+        <li><a href="../../techniques/aria/ARIA16">ARIA16</a></li>
+        <li><a href="../../techniques/client-side-script/SCR30">SCR30</a></li>
+			</ul>
+		</section>
+	</body>
+</html>
diff --git a/techniques/failures/F96.html b/techniques/failures/F96.html
index 8bee496760..b853408bd9 100644
--- a/techniques/failures/F96.html
+++ b/techniques/failures/F96.html
@@ -71,6 +71,7 @@ <h3>Expected Results</h3>
 		<section id="related">
 			<h2>Related Techniques</h2>
 			<ul>
+				<li><a href="../../techniques/general/F111">F111</a></li>
         <li><a href="../../techniques/general/G131">G131</a></li>
         <li><a href="../../techniques/aria/ARIA7">ARIA7</a></li>
         <li><a href="../../techniques/aria/ARIA8">ARIA8</a></li>
diff --git a/understanding/21/label-in-name.html b/understanding/21/label-in-name.html
index efbd0edd69..7460eb4e57 100644
--- a/understanding/21/label-in-name.html
+++ b/understanding/21/label-in-name.html
@@ -25,75 +25,87 @@ <h2>Intent</h2>
 			<p>Note that where a visible text label does not exist for a component, this Success Criterion does not apply to that component.</p>
 			<p>Where text labels exist and are properly linked to the user interface components through established authoring practices, the label and name will normally match. When they don't match, speech-input users who attempt to use the visible text label as a means of navigation or selection (e.g., "move to Password") will be unsuccessful.  The speech-based navigation fails because the visible label spoken by the users does not match (or is not part of) the accessible name that is enabled as a speech-input command. In addition, when the accessible name is different from the visible label, it may function as a hidden command that can be accidentally activated by speech-input users.</p>
 			<p>Mismatches between visible labels and programmatic names for controls are even more of an issue for speech-input and text-to-speech users who also have cognitive challenges. Mismatches create an extra cognitive load for speech-input users, who must remember to say a speech command that is different from the visible label they see on a control. It also creates extra cognitive load for a text-to-speech user to absorb and understand speech output that does not match the visible label.</p>
+			<p>Note that when a <a>user interface component</a> lacks an <a>accessible name</a> — a failure of <a href="name-role-value">4.1.2 Name, Role, Value</a> — and has a visible text label, then it also fails this Success Criterion.</p>
+
 			<h3>Identifying label text for components</h3>
-<p>In order for the label text and accessible name to be matched, it is first necessary to determine which text on the screen should be considered a label for any given control. There are often multiple text strings in a user interface that may be relevant to a control. However, there are reasons why it is best to conservatively interpret the label as being only the text in close proximity.</p>
-<p>Conventionally the label for user interface components is the adjacent text string. The typical positioning for left to right languages is:</p>
-<ul><li>immediately to the left of comboboxes, dropdown lists, text inputs, and other widgets (or in the absence of left-side labels, immediately above and aligned with the left edge of each input)</li>
-<li>immediately to the right of checkboxes and radio buttons</li>
-<li>inside buttons and tabs or immediately below icons serving as buttons</li>
-</ul>
-<p>The rationale for some of these conventions is explained in <a href="https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/G162">G162: Positioning labels to maximize predictability of relationships</a>.
-</p>
-<p>It is important to bias towards treating only the adjacent text as a label because liberal interpretations of what constitutes a text label can jeopardize the value of this Success Criterion (SC) by lessening predictability. Isolating the label to the single string in close proximity to the component makes it easier for developers, testers, and end users to identify the label targeted for evaluation in this SC. Predictable interpretation of labeling allows users of speech recognition technologies to interact with the element via its conventionally positioned label, and allows users of screen reading technologies to enjoy consistency between the nearby visible label and the announced name of the component.</p>
-<p>Note that placeholder text within an input field is not considered an appropriate means of providing a label. The <a href="https://www.w3.org/TR/html52/sec-forms.html#the-placeholder-attribute">HTML5 specification</a> states <q>The placeholder attribute should not be used as an alternative to a &lt;label&gt;.</q> However, it is worth noting that "label" in that HTML5 statement is in code brackets and links to the <code>label</code> element. For the purposes of this Label in Name Success Criterion, "label" is not used in such a programmatic sense but is simply referring to a text string in close visual proximity to a component. As such, in the absence of any other nearby text string (as described in the preceding list), if an input contains placeholder text, such text may be a candidate for Label in Name. This is supported both through the accessible name calculation (discussed later) and from the practical sense that where a visible label is not otherwise provided, it is likely that a speech-input user may attempt to use the placeholder text value as a means of interacting with the input.</p>
+			<p>In order for the label text and accessible name to be matched, it is first necessary to determine which text on the screen should be considered a label for any given control. There are often multiple text strings in a user interface that may be relevant to a control. However, there are reasons why it is best to conservatively interpret the label as being only the text in close proximity.</p>
+			<p>Conventionally the label for user interface components is the adjacent text string. The typical positioning for left to right languages is:</p>
+			<ul>
+				<li>immediately to the left of comboboxes, dropdown lists, text inputs, and other widgets (or in the absence of left-side labels, immediately above and aligned with the left edge of each input)</li>
+				<li>immediately to the right of checkboxes and radio buttons</li>
+				<li>inside buttons and tabs or immediately below icons serving as buttons</li>
+			</ul>
+			<p>The rationale for some of these conventions is explained in <a href="../../Techniques/general/G162">G162: Positioning labels to maximize predictability of relationships</a>.</p>
+			<p>It is important to bias towards treating only the adjacent text as a label because liberal interpretations of what constitutes a text label can jeopardize the value of this Success Criterion (SC) by lessening predictability. Isolating the label to the single string in close proximity to the component makes it easier for developers, testers, and end users to identify the label targeted for evaluation in this SC. Predictable interpretation of labeling allows users of speech recognition technologies to interact with the element via its conventionally positioned label, and allows users of screen reading technologies to enjoy consistency between the nearby visible label and the announced name of the component.</p>
+			<p>Note that placeholder text within an input field is not considered an appropriate means of providing a label. The <a href="https://www.w3.org/TR/html52/sec-forms.html#the-placeholder-attribute">HTML5 specification</a> states <q>The placeholder attribute should not be used as an alternative to a <code>&lt;label&gt;</code>.</q> However, it is worth noting that "label" in that HTML5 statement is in code brackets and links to the <code>label</code> element. For the purposes of this Label in Name Success Criterion, "label" is not used in such a programmatic sense but is simply referring to a text string in close visual proximity to a component. As such, in the absence of any other nearby text string (as described in the preceding list), if an input contains placeholder text, such text may be a candidate for Label in Name. This is supported both through the accessible name calculation (discussed later) and from the practical sense that where a visible label is not otherwise provided, it is likely that a speech-input user may attempt to use the placeholder text value as a means of interacting with the input.</p>
 			<section>
-<h3>Text labels "express something in human language"</h3>
+				<h3>Text labels "express something in human language"</h3>
 				<section>
-<h4>Symbolic text characters</h4>
-<p>For the purposes of this SC, text should not be considered a visible label if it is used in a symbolic manner, rather than directly <q>expressing something in human language</q> as per the definition of <a>text</a> in WCAG. For example, <a href="https://www.w3.org/TR/WCAG21/#images-of-text">1.4.5 Images of Text</a> describes considerations for "symbolic text characters." In the images of text example "B", "I", and "ABC" appear on icons in a text editor, where they are meant to symbolize the functions for Bold, Italics, and Spelling, respectively. In such a case, the accessible name should be the function the button serves (e.g., "Spell check" or "Check spelling"), not the visible symbolic characters. A similar text editor is shown in the figure below.</p>
-<figure id="figure-RTE-github">
-	<img alt="Icons for transforming text, including heading, bold, italic, quote, code, and link, along with icons for ordered and unordered lists and other controls" src="img/rich-text-editor-detail.png" />
-	<figcaption>A detail of the rich text editor in Github, showing a variety of unlabeled icons, including icons resembling text characters.</figcaption>
-</figure>
-<p>Likewise, where an author has used a greater-than symbol (">") to mimic the appearance of the right-facing arrow, the text does not convey something in human language. It is a symbol, in this scenario likely meant to mimic the icons used for a "Play" button or a "Next" arrow.</p>
-<h4>Punctuation and capitalization</h4>
+					<h4>Symbolic text characters</h4>
+					<p>For the purposes of this SC, text should not be considered a visible label if it is used in a symbolic manner, rather than directly <q>expressing something in human language</q> as per the definition of <a>text</a> in WCAG. For example, <a href="images-of-text">1.4.5 Images of Text</a> describes considerations for "symbolic text characters." In the images of text example "B", "I", and "ABC" appear on icons in a text editor, where they are meant to symbolize the functions for Bold, Italics, and Spelling, respectively. In such a case, the accessible name should be the function the button serves (e.g., "Spell check" or "Check spelling"), not the visible symbolic characters. A similar text editor is shown in the figure below.</p>
+					<figure id="figure-RTE-github">
+						<img alt="Icons for transforming text, including heading, bold, italic, quote, code, and link, along with icons for ordered and unordered lists and other controls" src="img/rich-text-editor-detail.png" />
+						<figcaption>A detail of the rich text editor in Github, showing a variety of unlabeled icons, including icons resembling text characters.</figcaption>
+					</figure>
+					<p>Likewise, where an author has used a greater-than symbol (<code>&gt;</code>) to mimic the appearance of the right-facing arrow, the text does not convey something in human language. It is a symbol, in this scenario likely meant to mimic the icons used for a "Play" button or a "Next" arrow.</p>
 				</section>
 				<section>
-<p>The use of punctuation and capitalization in labels <em>may</em> also be considered optional for the same reason. For example, the colon conventionally added at the end of input labels does not express something in human language, and capitals on the first letter of each word in a label do not normally alter the words' meaning. This is particularly relevant in the context of this SC, since it is primarily aimed at users of speech recognition; capitals and most punctuation are frequently ignored when a user speaks a label as a means of interacting with a control.</p>
-<p>While it is certainly not an error to include the colon and capitalization in the accessible name, a computed name of "First name" should not be considered a failure of "First Name:".<br />
-<label for="firstname">First Name: </label><input id="firstname" type="text" name="firstname" /><br />
-Likewise, "Next…" visibly shown on a button could have "Next" as the accessible name. When in doubt, where a meaningful visible label exists, match the string exactly for the accessible name.<br />
-<input type="submit" value="Next..." /></p>
+					<h4>Punctuation and capitalization</h4>
+					<p>The use of punctuation and capitalization in labels <em>may</em> also be considered optional for the same reason. For example, the colon conventionally added at the end of input labels does not express something in human language, and capitals on the first letter of each word in a label do not normally alter the words' meaning. This is particularly relevant in the context of this SC, since it is primarily aimed at users of speech recognition; capitals and most punctuation are frequently ignored when a user speaks a label as a means of interacting with a control.</p>
+
+					<p>While it is certainly not an error to include the colon and capitalization in the accessible name, a computed name of "First name" should not be considered a failure of "First Name:".</p>
+
+<pre xml:space="preserve"><code class="language-html">
+&lt;label for="firstname"&gt;First Name:&lt;/label&gt;
+&lt;input id="firstname" type="text" name="firstname"&gt;
+</code></pre>
+
+					<p>Likewise, "Next…" visibly shown on a button could have "Next" as the accessible name. When in doubt, where a meaningful visible label exists, match the string exactly for the accessible name.</p>
+
+<pre xml:space="preserve"><code class="language-html">
+&lt;input type="submit" value="Next..."&gt;
+</code></pre>
+
 				</section>
 				<section>
+					<h4>Mathematical expressions and formulae</h4>
+					<p>Mathematical expressions are an exception to the previous subsection about symbolic characters. Math symbols can be used as labels; for example <code>11&#215;3=33</code> and <code>A&gt;B</code> convey meaning. The label should not be overwritten in the accessible name, and substitutions of words where a formula is used should be avoided since there are multiple ways to express the same equation. For example, making the name "eleven multiplied by three is equivalent to thirty-three" might mean a user who said "eleven times three equals thirty-three" may not match. It is best to leave the formulas as used in the label and count on the user's familiarity with their speech software to achieve a match. Further, converting a mathematical formula label into an accessible name that is a spelled-out equivalent may create issues for translation. The name should match the label's formula text. Note that a consideration for authors is to use the proper symbol in the formula. For instance <code>11x3</code> (with a lower or upper case letter X), <code>11*3</code> (with the asterisk symbol), and <code>11&#215;3</code> (with the <code>&amp;times;</code> symbol) are all easy for sighted users to interpret as meaning the same formula, but may not all be matched to "11 times 3" by the speech recognition software. The proper operator symbol (in this case the times symbol) should be used.</p>
 
-<h4>Mathematical expressions and formulae</h4>
-<p>Mathematical expressions are an exception to the previous subsection about symbolic characters. Math symbols can be used as labels; for example "11&#215;3=33" and "A>B" convey meaning. The label should not be overwritten in the accessible name, and substitutions of words where a formula is used should be avoided since there are multiple ways to express the same equation. For example, making the name "eleven multiplied by three is equivalent to thirty-three" might mean a user who said "eleven times three equals thirty-three" may not match. It is best to leave the formulas as used in the label and count on the user's familiarity with their speech software to achieve a match. Further, converting a mathematical formula label into an accessible name that is a spelled-out equivalent may create issues for translation. The name should match the label's formula text. Note that a consideration for authors is to use the proper symbol in the formula. For instance 11x3 (with a lower or upper case letter X), 11*3 (with the asterisk symbol), and 11&#215;3 (with the <code>&amp;</code>times<code>;</code> symbol) are all easy for sighted users to interpret as meaning the same formula, but may not all be matched to "11 times 3" by the speech recognition software. The proper operator symbol (in this case the times symbol) should be used.<br />
+<pre xml:space="preserve"><code class="language-html">
+&lt;input type="radio" name="equation" id="answer1" value="A&gt;B"&gt;&lt;label for="answer1"&gt;A&gt;B&lt;/label&gt;
+&lt;input type="radio" name="equation" id="answer2" value="A=B"&gt;&lt;label for="answer2"&gt;A=B&lt;/label&gt;
+&lt;input type="radio" name="equation" id="answer3" value="A&lt;B"&gt;&lt;label for="answer3"&gt;A&lt;B&lt;/label&gt;
+</code></pre>
 
-    <input type="radio" name="equation" id="answer1" value="A&gt;B" /><label for="answer1">A&gt;B</label>
-    <input type="radio" name="equation" id="answer2" value="A=B" /><label for="answer2">A=B</label>
-    <input type="radio" name="equation" id="answer3" value="A&lt;B" /><label for="answer3">A&lt;B</label></p>
 				</section>
 			</section>
 			<section>
-
- <h3>Accessible Name and Description Computation specification</h3>
- <p>It is important to understand how the accessible name is derived. The <a href="https://www.w3.org/TR/accname-1.1/">Accessible Name and Description Computation 1.1</a> and the <a href="https://w3c.github.io/html-aam/#accessible-name-and-description-computation">HTML Accessibility API Mappings 1.0</a> describe how the accessible name is computed, including which attributes are considered in its calculation, and in what order of preference. If a component has multiple possible attribute values that could be used for its accessible name, only the most preferred of those values will be computed. None of the other, less preferred values will be part of the name. For the most part, existing established programmatic relationships between labels and controls are reinforced by the specification.</p>
- <p>Other text displayed on the screen that is correctly coded to meet 1.3.1: Info and Relationships is <strong>not</strong> normally factored into the calculation for the accessible name of a UI component without author intervention (via ARIA labeling techniques). The most common of these are:</p>
-	<ul>
-		<li>headings and instructions</li>
-<li>group labels for sets of components (i.e., used with <code>legend</code>/<code>fieldset</code> or with role of <code>group</code> or <code>radiogroup</code>)</li> 
-</ul>
-<p>Such textual information may constitute part of the component's <em>description</em>. So from both a programmatic viewpoint, and from the conservative tactic of only considering a label to be "adjacent text," neither headings, instructions, nor group 'labels' should normally be considered <strong>labels</strong> for the purpose of this Success Criterion.</p>
- <p>It is important to note that the specification allows authors to override the name calculated through native semantics. Both <code>aria-label</code> and <code>aria-labelledby</code> take precedence in the name calculation, overriding the visible text as the accessible name even when the visible text label is programmatically associated with the control. For this reason, when a visible label already exists, <code>aria-label</code> should be avoided or used carefully, and <code>aria-labelledby</code> should be used as a supplement with care.</p>
-<p>Finally, <code>aria-describedby</code> is not included in the Accessible Name computation (instead it is part of the Accessible Description computation). By convention, text associated with a control through <code>aria-describedby</code> is announced immediately after the accessible name by screen readers. Therefore, the context of headings, instructions, and group labels can be provided through the accessible description to assist users of screen readers without affecting the experience of those who navigate using speech recognition software.</p>
-			</section>
-		</section>
-
-
-			<section id="benefits">
-				<h2>Benefits</h2>
+				<h3>Accessible Name and Description Computation specification</h3>
+				<p>It is important to understand how the accessible name is derived. The <a href="https://www.w3.org/TR/accname-1.1/">Accessible Name and Description Computation 1.1</a> and the <a href="https://www.w3.org/TR/html-aam-1.0/#accessible-name-and-description-computation">HTML Accessibility API Mappings 1.0</a> describe how the accessible name is computed, including which attributes are considered in its calculation, and in what order of preference. If a component has multiple possible attribute values that could be used for its accessible name, only the most preferred of those values will be computed. None of the other, less preferred values will be part of the name. For the most part, existing established programmatic relationships between labels and controls are reinforced by the specification.</p>
+				<p>Other text displayed on the screen that is correctly coded to meet 1.3.1: Info and Relationships is <strong>not</strong> normally factored into the calculation for the accessible name of a UI component without author intervention (via ARIA labeling techniques). The most common of these are:</p>
 				<ul>
-					<li>Speech-input users can directly activate controls on a page with fewer surprising changes of focus.</li>
-					<li>Text-to-speech users will have a better experience because the labels that they hear match the visible text labels that
-					they see on the screen.</li>
+					<li>headings and instructions</li>
+					<li>group labels for sets of components (i.e., used with <code>legend</code>/<code>fieldset</code> or with role of <code>group</code> or <code>radiogroup</code>)</li>
 				</ul>
+				<p>Such textual information may constitute part of the component's <em>description</em>. So from both a programmatic viewpoint, and from the conservative tactic of only considering a label to be "adjacent text," neither headings, instructions, nor group 'labels' should normally be considered <strong>labels</strong> for the purpose of this Success Criterion.</p>
+				<p>It is important to note that the specification allows authors to override the name calculated through native semantics. Both <code>aria-label</code> and <code>aria-labelledby</code> take precedence in the name calculation, overriding the visible text as the accessible name even when the visible text label is programmatically associated with the control. For this reason, when a visible label already exists, <code>aria-label</code> should be avoided or used carefully, and <code>aria-labelledby</code> should be used as a supplement with care.</p>
+				<p>Finally, <code>aria-describedby</code> is not included in the Accessible Name computation (instead it is part of the Accessible Description computation). By convention, text associated with a control through <code>aria-describedby</code> is announced immediately after the accessible name by screen readers. Therefore, the context of headings, instructions, and group labels can be provided through the accessible description to assist users of screen readers without affecting the experience of those who navigate using speech recognition software.</p>
 			</section>
+		</section>
+
+		<section id="benefits">
+			<h2>Benefits</h2>
+			<ul>
+				<li>Speech-input users can directly activate controls on a page with fewer surprising changes of focus.</li>
+				<li>Text-to-speech users will have a better experience because the labels that they hear match the visible text labels that
+				they see on the screen.</li>
+			</ul>
+		</section>
 		<section id="examples">
 			<h2>Examples</h2>
 			<ul>
-				<li><strong>Accessible name matches visible label:</strong> The accessible name and visible label of a control match.</li>
-				<li><strong>Accessible name starts with visible label:</strong> The accessible name "Search for a value" begins with the text of the visible label, "Search".</li>
+				<li><strong>Accessible name matches visible label:</strong> The accessible name and visible label of a control match.</li>
+				<li><strong>Accessible name starts with visible label:</strong> The accessible name "Search for a value" begins with the text of the visible label, "Search".</li>
 			</ul>
 		</section>
 		<section id="resources">
@@ -108,25 +120,23 @@ <h2>Techniques</h2>
 			<section id="sufficient">
 				<h3>Sufficient Techniques</h3>
 				<ul>
-					<li><a href="../../techniques/general/G208">G208: Including the text of the visible label as part of the accessible name</a></li>
-					<li><a href="../../techniques/general/G211">G211: Matching the accessible name to the visible label</a></li>
+					<li><a href="../../Techniques/general/G208">G208: Including the text of the visible label as part of the accessible name</a></li>
+					<li><a href="../../Techniques/general/G211">G211: Matching the accessible name to the visible label</a></li>
 				</ul>
 			</section>
 			<section id="advisory">
 				<h2>Advisory Techniques</h2>
-				<p>Although not required for conformance, the following additional techniques should
-                  be considered in order to make content more accessible. Not all techniques can be
-                  used or would be effective in all situations.
-               </p>
+				<p>Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.</p>
 				<ul>
-					<li><a href="https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/G162">G162: Positioning labels to maximize predictability of relationships</a></li>
+					<li><a href="../../Techniques/general/G162">G162: Positioning labels to maximize predictability of relationships</a></li>
 					<li>If an icon has no accompanying text, consider using its hover text as its accessible name (Potential future technique)</li>
 				</ul>
 			</section>
 			<section id="failure">
 				<h2>Failure Techniques</h2>
 				<ul>
-					<li><a href="../../techniques/failures/F96">F96: Failure due to the accessible name not containing the visible label text</a></li>
+					<li><a href="../../Techniques/failures/F96">F96: Failure due to the accessible name not containing the visible label text</a></li>
+					<li><a href="../../Techniques/failures/F111">F111: Failure due to a control with visible label text but no accessible name</a></li>
 					<li>Accessible name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text (Potential future technique)</li>
 					<li>Accessible name contains the visible label text, but one or more other words are interspersed in the label (Potential future technique)</li>
 				</ul>

From ca71bccb7bcd103c440d7ee94e54f469042afbf2 Mon Sep 17 00:00:00 2001
From: Mike Gower <mikegower@gmail.com>
Date: Mon, 11 Mar 2024 09:26:29 -0700
Subject: [PATCH 3/8] Update base.xslt (#3708)

Closes #3684
Fixing typo in email address
---
 xslt/base.xslt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xslt/base.xslt b/xslt/base.xslt
index 3a0e3e53d0..9eb6d193d0 100644
--- a/xslt/base.xslt
+++ b/xslt/base.xslt
@@ -339,7 +339,7 @@
 				<h2> Help improve this page </h2>
 			</header>
 			<div class="box-i">
-    		<p>Please share your ideas, suggestions, or comments via e-mail to the publicly-archived list <a href="mailto:public-agwg-comments@w3.org?subject=%5BUnderstanding%20and%20Techniques%20Feedback%5D">public-agwg-comments@w3.org@w3.org</a> or via GitHub</p>
+    		<p>Please share your ideas, suggestions, or comments via e-mail to the publicly-archived list <a href="mailto:public-agwg-comments@w3.org?subject=%5BUnderstanding%20and%20Techniques%20Feedback%5D">public-agwg-comments@w3.org</a> or via GitHub</p>
 				<div class="button-group">
 					<a href="mailto:public-agwg-comments@w3.org?subject=%5BUnderstanding%20and%20Techniques%20Feedback%5D"
 						class="button"><span>E-mail</span></a>

From a9dbe114c24a1472c9f057cedd1d6c5e22998136 Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" <redux@splintered.co.uk>
Date: Mon, 11 Mar 2024 16:34:59 +0000
Subject: [PATCH 4/8] Update definition for single pointer (#3536)

The definition for "single pointer" has had issues for a long time, as
it mixes the idea of what a pointer *is* with the action(s) *performed*
using a pointer.

I originally tried to fix this, but there was no appetite for it once
2.1 was released. However, with 2.2 and the new 2.5.7 Dragging Movement
SC, the broken definition is causing actual misunderstandings/illogical
non-sequiturs.

See https://github.com/w3c/wcag/issues/749#issuecomment-494146357 and
the recent https://github.com/w3c/wcag/issues/3535 where this is once
again causing a non-sequitur

Closes https://github.com/w3c/wcag/issues/3535

(this is effectively a follow-up to https://github.com/w3c/wcag/pull/809
which had disambiguated things, but the definition had since been
changed further/again to reintroduce the ambiguous wording we have at
this point which confuses input with action)

This would be applied to WCAG 2.1 and 2.2, unless there is a decision to
only apply it to 2.2.

EDIT: Also closes https://github.com/w3c/wcag/issues/394


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/w3c/wcag/pull/3536.html"
title="Last updated on Mar 8, 2024, 7:30 PM UTC (6c36df1)">Preview</a> |
<a
href="https://pr-preview.s3.amazonaws.com/w3c/wcag/3536/afbf9ee...6c36df1.html"
title="Last updated on Mar 8, 2024, 7:30 PM UTC (6c36df1)">Diff</a>

---------

Co-authored-by: Alastair Campbell <ac@alastc.com>
---
 guidelines/terms/21/single-pointer.html | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/guidelines/terms/21/single-pointer.html b/guidelines/terms/21/single-pointer.html
index 46ea4f99f9..7f0001968a 100644
--- a/guidelines/terms/21/single-pointer.html
+++ b/guidelines/terms/21/single-pointer.html
@@ -1,7 +1,6 @@
 <dt><dfn id="dfn-single-pointer">single pointer</dfn></dt>
 <dd>
-   	
-   <p>pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures</p>
-  				
+   <p>an input that only targets a single point on the page/screen at a time – such as a mouse, single finger on a touch screen, or stylus.</p>
+   <p class="note">In contrast to single pointer inputs, multipoint interactions involve the use of two or more pointers at the same time – such as two finger interactions on a touchscreen, or the simultaneous use of a mouse and stylus.</p>
 </dd>
 

From 31b1ad3680bac99540521bb919ee8b8e74ccb570 Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" <redux@splintered.co.uk>
Date: Mon, 11 Mar 2024 22:28:08 +0000
Subject: [PATCH 5/8] Update general understanding documents (#3588)

* removes the woefully out-of-date (and likely never going to be
maintained) "Change log" from the
https://www.w3.org/WAI/WCAG22/Understanding/about page
* where possible, makes WCAG mentions "versionless" ("WCAG 2" instead of
"WCAG 2.0" / "WCAG 2.1" / "WCAG 2.2")
* <s>where not possible (e.g. links to techniques document), bumps to
2.2</s> EDIT: made techniques document link versionless as well
* <s>change `success criterion`/`success criteria` to `Success
Criterion`/`Success Criteria` (and correct minor instances where the
latter was used as if it were singular - "is the Success Criteria" >
"are the Success Criteria" or "is the Success Criterion")</s> EDIT: as a
result of discussions that came after this PR was made, reverting this
change, and changing any straggler references that did use uppercase
`Success Criteria` to lowercase `success criteria`
* adds `lang` attributes to all documents
* updates some of the links (most prominent: replace the outdated
https://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/ to instead point to the
github repo)

Closes #3585

Note that this change is based on existing non-normative information
under [Background on WCAG
2](https://www.w3.org/TR/WCAG22/#background-on-wcag-2) in the existing
TR, which reads in part:
>Where this document refers to WCAG 2 it is intended to mean any and all
versions of WCAG that start with 2.

---------

Co-authored-by: Mike Gower <mikegower@gmail.com>
Co-authored-by: David Cox <98318778+dav-idc@users.noreply.github.com>
Co-authored-by: Sebastian <39335537+sebazai@users.noreply.github.com>
---
 understanding/about.html                      | 140 +++++++++---------
 understanding/conformance.html                |  99 ++++++-------
 .../documenting-accessibility-support.html    |   6 +-
 understanding/intro.html                      |  48 +++---
 understanding/refer-to-wcag.html              |  54 +++----
 understanding/understanding-act-rules.html    |  22 +--
 understanding/understanding-metadata.html     |   6 +-
 understanding/understanding-techniques.html   |  52 +++----
 understanding/understanding-template.html     |  12 +-
 9 files changed, 215 insertions(+), 224 deletions(-)

diff --git a/understanding/about.html b/understanding/about.html
index 98cefe490a..e953954844 100644
--- a/understanding/about.html
+++ b/understanding/about.html
@@ -17,94 +17,86 @@
 				<header class="box-h ">Page Contents</header>
 				<div class="box-i">
 					<ul>
-             <li><a href="#aboutwcag">About WCAG</a></li>
-             <li><a href="#introduction">About the Understand Documents</a></li>
-             <li><a href="#structure">Structure of the Documents</a></li>
-             <li><a href="#changelog">Change Log</a></li>
-             <li><a href="#acknowledgements">Acknowledgements</a></li>
+            <li><a href="#aboutwcag">About WCAG</a></li>
+            <li><a href="#introduction">About the Understand Documents</a></li>
+            <li><a href="#structure">Structure of the Documents</a></li>
+            <li><a href="#changelog">Change Log</a></li>
+            <li><a href="#acknowledgements">Acknowledgements</a></li>
 					</ul>
 				</div>
 			</nav>
 		</aside>
 		<main id="main" class="main-content standalone-resource__main">
 			<h1 id="title" class="title p-name">About WCAG Understanding Documents</h1>
-    <aside class="box">
-      <header class="box-h ">Summary</header>
-      <div class="box-i">
-        <p><em>Understanding documents</em> provide detailed  explanations for Web Content Accessibility Guidelines (WCAG) guidelines and success criteria. They are informative, not  part of the &quot;normative&quot; WCAG standard. To start learning about WCAG, see the <a href="https://www.w3.org/WAI/intro/wcag">WCAG Overview</a>.</p>
-      </div>
-    </aside>
-		  <section id="aboutwcag">
-    <h2>About WCAG</h2>
-    <p>Web Content Accessibility Guidelines (WCAG) provides requirements for making websites, applications, and other digital content accessible to people with disabilities. For an introduction to WCAG, supporting technical documents, and educational material, see <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">WCAG 2 Overview<!-- <svg focusable="false" aria-hidden="true" class="icon-different-view "><use xlink:href="/WAI/assets/images/icons.svg#icon-different-view"></use></svg> --></a>.</p>
-    <p>There are additional resources that help you understand and implement WCAG. These Understanding documents are one type of resource. Others are explained in the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/docs/">WCAG 2 Documents<!-- <svg focusable="false" aria-hidden="true" class="icon-different-view "><use xlink:href="/WAI/assets/images/icons.svg#icon-different-view"></use></svg>--></a>.</p>
-		  </section>
-		  <section id="introduction">
-    <h2>About the Understanding Documents</h2>
-    <p>WCAG Understanding documents are guides to understanding and implementing WCAG.   They provide detailed  explanations for
-      each guideline and each success criterion to help readers better understand the intent
-      of the success criteria. They include  background information and  technical details. They include <em>techniques</em> that are examples of ways to meet the success criteria. Each technique is linked to more details in a techniques page. Techniques are explained in <a class="understanding" href="understanding-techniques">Understanding Techniques for WCAG Success Criteria</a>.</p>
-    <p>WCAG Understanding documents are not  introductory resources. They are  for people who want to understand WCAG more thoroughly. The <a href="https://www.w3.org/WAI/intro/wcag">WCAG Overview</a> provides introductory information.</p>
-    <section id="structure">
-      <h3>Structure of the Documents</h3>
-      <p><em>Understanding <strong>Guideline</strong> </em>pages include:</p>
-      <ul>
-        <li>The intent</li>
-        <li>Any advisory techniques that are related
-          to the guideline and not specifically related to any of its success criteria</li>
-      </ul>
-      <p><em>Understanding <strong>Success Criterion</strong></em> pages include:</p>
-      <ul>
-        <li> The success criterion wording from WCAG</li>
-        <li> Intent of the success criterion </li>
-        <li> Benefits, how  it helps people with disabilities</li>
-        <li> Examples </li>
-        <li> Related resources</li>
-        <li>Techniques
+      <aside class="box">
+        <header class="box-h ">Summary</header>
+        <div class="box-i">
+          <p><em>Understanding documents</em> provide detailed  explanations for Web Content Accessibility Guidelines (WCAG) guidelines and success criteria. They are informative, not  part of the &quot;normative&quot; WCAG standard. To start learning about WCAG, see the <a href="https://www.w3.org/WAI/intro/wcag">WCAG Overview</a>.</p>
+        </div>
+      </aside>
+      <section id="aboutwcag">
+        <h2>About WCAG</h2>
+        <p>Web Content Accessibility Guidelines (WCAG) provides requirements for making websites, applications, and other digital content accessible to people with disabilities. For an introduction to WCAG, supporting technical documents, and educational material, see <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">WCAG 2 Overview<!-- <svg focusable="false" aria-hidden="true" class="icon-different-view "><use xlink:href="/WAI/assets/images/icons.svg#icon-different-view"></use></svg> --></a>.</p>
+        <p>There are additional resources that help you understand and implement WCAG. These Understanding documents are one type of resource. Others are explained in the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/docs/">WCAG 2 Documents<!-- <svg focusable="false" aria-hidden="true" class="icon-different-view "><use xlink:href="/WAI/assets/images/icons.svg#icon-different-view"></use></svg>--></a>.</p>
+      </section>
+      <section id="introduction">
+        <h2>About the Understanding Documents</h2>
+        <p>WCAG Understanding documents are guides to understanding and implementing WCAG.   They provide detailed  explanations for
+          each guideline and each success criterion to help readers better understand the intent
+          of the success criteria. They include  background information and  technical details. They include <em>techniques</em> that are examples of ways to meet the success criteria. Each technique is linked to more details in a techniques page. Techniques are explained in <a class="understanding" href="understanding-techniques">Understanding Techniques for WCAG Success Criteria</a>.</p>
+        <p>WCAG Understanding documents are not  introductory resources. They are  for people who want to understand WCAG more thoroughly. The <a href="https://www.w3.org/WAI/intro/wcag">WCAG Overview</a> provides introductory information.</p>
+
+        <section id="structure">
+          <h3>Structure of the Documents</h3>
+          <p><em>Understanding <strong>Guideline</strong> </em>pages include:</p>
+          <ul>
+            <li>The intent</li>
+            <li>Any advisory techniques that are related
+              to the guideline and not specifically related to any of its success criteria</li>
+          </ul>
+          <p><em>Understanding <strong>Success Criterion</strong></em> pages include:</p>
           <ul>
-            <li> Sufficient techniques</li>
-            <li> Advisory techniques</li>
-            <li> Failures</li>
+            <li> The success criterion wording from WCAG</li>
+            <li> Intent of the success criterion </li>
+            <li> Benefits, how  it helps people with disabilities</li>
+            <li> Examples </li>
+            <li> Related resources</li>
+            <li>Techniques
+              <ul>
+                <li> Sufficient techniques</li>
+                <li> Advisory techniques</li>
+                <li> Failures</li>
+              </ul>
+            </li>
+            <li> Key terms for this success criterion,  from the WCAG Glossary </li>
           </ul>
-        </li>
-        <li> Key terms for this success criterion,  from the WCAG Glossary </li>
-      </ul>
-    </section>
-				
-			</section>
-			<section id="changelog">
-                <details>
-                    <summary>
-                        <h2>Change Log</h2>
-                    </summary>
-                    <p>A list of significantly updated Understanding documents since WCAG 2.1 was published:</p>
-                    <ol>
-                      <li>
-                        <time datetime="2019-01-17">Jan 18th 2019</time>: Updated <a href="./non-text-contrast">Understanding Non-text contrast</a>, based on the changes from <a href="https://github.com/w3c/wcag/pull/550">Pull request 550</a>.
-                      </li>
-                    </ol>
-                    <p>For a more detailed view of recent changes to the informative documents see the <a href="https://github.com/w3c/wcag/commits/master">github updates</a>.</p>
-          
-                </details>
-            </section>
+        </section>
+      </section>
+
+      <section id="changelog">
+        <details>
+          <summary><h2>Change Log</h2></summary>
+          <p>For a detailed view of recent changes to the informative documents see the <a href="https://github.com/w3c/wcag/commits/master">github updates</a>.</p>
+        </details>
+      </section>
+
+      <section id="acknowledgements">
+        <details>
+          <summary><h2>Acknowledgements</h2></summary>
+          <div data-include="../acknowledgements/ag-wg-active.html" data-include-replace="true"></div>
+          <div data-include="../acknowledgements/ag-contributors.html" data-include-replace="true"></div>
+          <div data-include="../acknowledgements/funders.html" data-include-replace="true"></div>
+        </details>
+      </section>
 
-        	<section id="acknowledgements">
-        		<details>
-        			<summary><h2>Acknowledgements</h2></summary>
-        			<div data-include="../acknowledgements/ag-wg-active.html" data-include-replace="true"></div>
-        			<div data-include="../acknowledgements/ag-contributors.html" data-include-replace="true"></div>
-        			<div data-include="../acknowledgements/funders.html" data-include-replace="true"></div>
-        		</details>
-        	</section>
-        	
-        </main>
+    </main>
 		<a class="button button-backtotop" href="#top"><span><svg focusable="false" aria-hidden="true" class="icon-arrow-up " viewBox="0 0 26 28">
 			<path d="M25.172 15.172c0 0.531-0.219 1.031-0.578 1.406l-1.172 1.172c-0.375 0.375-0.891 0.594-1.422 0.594s-1.047-0.219-1.406-0.594l-4.594-4.578v11c0 1.125-0.938 1.828-2 1.828h-2c-1.062 0-2-0.703-2-1.828v-11l-4.594 4.578c-0.359 0.375-0.875 0.594-1.406 0.594s-1.047-0.219-1.406-0.594l-1.172-1.172c-0.375-0.375-0.594-0.875-0.594-1.406s0.219-1.047 0.594-1.422l10.172-10.172c0.359-0.375 0.875-0.578 1.406-0.578s1.047 0.203 1.422 0.578l10.172 10.172c0.359 0.375 0.578 0.891 0.578 1.422z"></path></svg> Back to Top
 		</span></a>
 	</div>
 	<script>
-				var translationStrings = {}; /* fix WAI JS */
-			</script>
+  	var translationStrings = {}; /* fix WAI JS */
+	</script>
 	<script src="https://www.w3.org/WAI/assets/scripts/main.js"></script></body>
 
 </html>
diff --git a/understanding/conformance.html b/understanding/conformance.html
index 20edb2b339..c2740b77ee 100644
--- a/understanding/conformance.html
+++ b/understanding/conformance.html
@@ -8,15 +8,15 @@
    <h1>Understanding Conformance</h1>
    
    
-   <p>All WCAG 2.0 Success Criteria are written as testable criteria for objectively determining
-      if content satisfies them. Testing the Success Criteria would involve a combination
+   <p>All WCAG 2 success criteria are written as testable criteria for objectively determining
+      if content satisfies them. Testing the success criteria would involve a combination
       of automated testing and human evaluation. The content should be tested by those who
       understand how people with different types of disabilities use the Web.
    </p>
    
    <p>Testing and testable in the context refer to functional testing, that is verifying
-      that the content functions as expected, or in this case, that it satisfies the Success
-      Criteria. Although content may satisfy all Success Criteria, the content may not always
+      that the content functions as expected, or in this case, that it satisfies the success criteria.
+      Although content may satisfy all success criteria, the content may not always
       be usable by people with a wide variety of disabilities. Therefore, usability testing
       is recommended, in addition to the required functional testing. Usability testing
       aims to determine how well people can use the content for its intended purpose. It
@@ -29,22 +29,21 @@ <h1>Understanding Conformance</h1>
       <h2>What does conformance mean?</h2>
       
       <p>Conformance to a standard means that you meet or satisfy the 'requirements' of the
-         standard. In WCAG 2.0 the 'requirements' are the Success Criteria. To conform to WCAG
-         2.0, you need to satisfy the Success Criteria, that is, there is no content which
-         violates the Success Criteria. 
+         standard. In WCAG 2 the 'requirements' are the success criteria. To conform to WCAG
+         2, you need to satisfy the success criteria, that is, there is no content which
+         violates the success criteria.
       </p>
       
       <div class="note">
          
-         <p>This means that if there is no content to which a success criterion applies, the success
-            criterion is satisfied.
+         <p>This means that if there is no content to which a success criterion applies, the success criterion is satisfied.
          </p>
          
       </div>
       
       <p>Most standards only have one level of conformance. In order to accommodate different
          situations that may require or allow greater levels of accessibility than others,
-         WCAG 2.0 has three levels of conformance, and therefore, three levels of Success Criteria.
+         WCAG 2 has three levels of conformance, and therefore, three levels of success criteria.
       </p>
       
    </section>
@@ -54,7 +53,7 @@ <h2>What does conformance mean?</h2>
       <h2>Understanding Conformance Requirements</h2>
       
       <p>There are five requirements that must be met in order for content to be classified
-         as 'conforming' to WCAG 2.0. This section provides brief notes on those requirements.
+         as 'conforming' to WCAG 2. This section provides brief notes on those requirements.
          This section will be expanded over time to address questions that may arise or to
          provide new examples of ways to meet the different conformance requirements.
       </p>
@@ -67,19 +66,19 @@ <h3>Understanding Requirement 1</h3>
          	<p><strong>Conformance Level</strong>: One of the following levels of conformance is met in full.</p>
          	<ul>
          		<li>For Level A conformance (the minimum level of conformance), the <a>Web page</a>
-         			<a>satisfies</a> all the Level A Success Criteria, or a <a>conforming alternate version</a> is provided.</li>
-         		<li>For Level AA conformance, the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided.</li>
-         		<li>For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided.</li>
+         			<a>satisfies</a> all the Level A success criteria, or a <a>conforming alternate version</a> is provided.</li>
+         		<li>For Level AA conformance, the Web page satisfies all the Level A and Level AA success criteria, or a Level AA conforming alternate version is provided.</li>
+         		<li>For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA success criteria, or a Level AAA conforming alternate version is provided.</li>
          	</ul>
          	<p class="note">Although conformance can only be achieved at the stated levels, authors are encouraged to report (in their claim) any progress toward meeting success criteria from all levels beyond the achieved level of conformance.</p>
-         	<p class="note">It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.</p>
+         	<p class="note">It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.</p>
          	
          </blockquote>
          
          <p>The first requirement deals with the levels of conformance. It basically says that
             all information on a page conforms or has a 
             <a>conforming alternate version</a> that is available from the page. The requirement also explains that no conformance
-            is possible without at least satisfying all of the Level A Success Criteria. 
+            is possible without at least satisfying all of the Level A success criteria. 
          </p>
          
          <p>The note points out that authors are encouraged to go beyond conformance to a particular
@@ -156,7 +155,7 @@ <h3>Understanding Requirement 3</h3>
          <h3>Understanding Requirement 4</h3>
          
       	<blockquote class="scquote" id="cc4">
-      		<p><strong>Only Accessibility-Supported Ways of Using Technologies</strong>: Only <a>accessibility-supported</a> ways of using <a>technologies</a> are <a>relied upon</a> to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See <a href="https://www.w3.org/WAI/WCAG21/Understanding/conformance#accessibility-support">Understanding accessibility support</a>.)</p></blockquote>
+      		<p><strong>Only Accessibility-Supported Ways of Using Technologies</strong>: Only <a>accessibility-supported</a> ways of using <a>technologies</a> are <a>relied upon</a> to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See <a href="#accessibility-support">Understanding accessibility support</a>.)</p></blockquote>
          
          <p>This conformance requirement is explained below under 
             <a href="#accessibility-support">Understanding Accessibility Support</a>.
@@ -201,7 +200,7 @@ <h3>Understanding Requirement 5</h3>
          
          <p>There are four provisions that particularly deal with issues of interference with
             use of the page. These four are included in a note here. A note on each of the provisions
-            indicates that these Success Criteria need to be met for all content including content
+            indicates that these success criteria need to be met for all content including content
             created using technologies that are not accessibility supported.
          </p>
          
@@ -316,11 +315,11 @@ <h3>Partial conformance claims due to third party content</h3>
       
       <section>
          
-         <h3>Information about any additional steps taken that go beyond the Success Criteria</h3>
+         <h3>Information about any additional steps taken that go beyond the success criteria</h3>
          
          <p>One of the optional components of a conformance claim is "Information about any additional
-            steps taken that go beyond the Success Criteria to enhance accessibility." This can
-            include additional Success Criteria that have been met, advisory techniques that were
+            steps taken that go beyond the success criteria to enhance accessibility." This can
+            include additional success criteria that have been met, advisory techniques that were
             implemented, information about any additional protocols used to aid access for people
             with particular disabilities or needs, etc. Any information that would be useful to
             people in understanding the accessibility of the pages may be included.
@@ -340,7 +339,7 @@ <h3>Use of metadata to report conformance claims</h3>
             and tool developers are encouraged to support them.
          </p>
          
-         <p>In addition, metadata can be used to report conformance to individual Success Criteria
+         <p>In addition, metadata can be used to report conformance to individual success criteria
             once Level A conformance has been achieved.
          </p>
          
@@ -425,7 +424,7 @@ <h4>Examples of Conformance Claims including optional components</h4>
                
                <ul>
                   
-                  <li>The following additional Success Criteria have also been met: 1.1.2, 1.2.5, and 1.4.3.
+                  <li>The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3.
                      
                   </li>
                   
@@ -546,56 +545,56 @@ <h3>Advisory Techniques for Conformance Claims</h3>
       
       <h2>Understanding Levels of Conformance</h2>
       
-      <p>First, there are a number of conditions that must be met for a Success Criterion to
+      <p>First, there are a number of conditions that must be met for a success criterion to
          be included at all. These include:
       </p>
       
       <ol>
          
-         <li>All Success Criteria must be 
+         <li>All success criteria must be 
             <strong>important access issues for people with disabilities</strong> that address problems beyond the usability problems that might be faced by all users.
             In other words, the access issue must cause a proportionately greater problem for
             people with disabilities than it causes people without disabilities in order to be
             considered an accessibility issue (and covered under these accessibility guidelines).
          </li>
          
-         <li>All Success Criteria must also be testable. This is important since otherwise it would
-            not be possible to determine whether a page met or failed to meet the Success Criteria.
-            The Success Criteria can be tested by a combination of machine and human evaluation
-            as long as it is possible to determine whether a Success Criterion has been satisfied
+         <li>All success criteria must also be testable. This is important since otherwise it would
+            not be possible to determine whether a page met or failed to meet the success criteria.
+            The success criteria can be tested by a combination of machine and human evaluation
+            as long as it is possible to determine whether a success criterion has been satisfied
             with a high level of confidence.
          </li>
          
       </ol>
       
-      <p>The Success Criteria were assigned to one of the three levels of conformance by the
+      <p>The success criteria were assigned to one of the three levels of conformance by the
          working group after taking into consideration a wide range of interacting issues.
          Some of the common factors evaluated when setting the level included:
       </p>
       
       <ul>
          
-         <li>whether the Success Criterion is 
-            <strong>essential</strong> (in other words, if the Success Criterion isn't met, then even assistive technology
+         <li>whether the success criterion is 
+            <strong>essential</strong> (in other words, if the success criterion isn't met, then even assistive technology
             can't make content accessible)
          </li>
          
-         <li>whether it is possible to satisfy the Success Criterion for 
-            <strong>all Web sites and types of content</strong> that the Success Criteria would apply to (e.g., different topics, types of content,
+         <li>whether it is possible to satisfy the success criterion for 
+            <strong>all Web sites and types of content</strong> that the success criterion would apply to (e.g., different topics, types of content,
             types of Web technology)
          </li>
          
-         <li>whether the Success Criterion requires skills that could 
-            <strong>reasonably be achieved by the content creators</strong> (that is, the knowledge and skill to meet the Success Criteria could be acquired
+         <li>whether the success criterion requires skills that could 
+            <strong>reasonably be achieved by the content creators</strong> (that is, the knowledge and skill to meet the success criterion could be acquired
             in a week's training or less)
          </li>
          
-         <li>whether the Success Criterion would impose limits on the "look &amp; feel" and/or function
+         <li>whether the success criterion would impose limits on the "look &amp; feel" and/or function
             of the Web page. (limits on function, presentation, freedom of expression, design
-            or aesthetic that the Success Criteria might place on authors)
+            or aesthetic that the success criterion might place on authors)
          </li>
          
-         <li>whether there are no workarounds if the Success Criterion is not met</li>
+         <li>whether there are no workarounds if the success criterion is not met</li>
          
       </ul>
       
@@ -605,9 +604,9 @@ <h2>Understanding Levels of Conformance</h2>
       
       <h2>Understanding Accessibility Support</h2>
       
-      <p>Many of the Success Criteria deal with providing accessibility through assistive technologies
+      <p>Many of the success criteria deal with providing accessibility through assistive technologies
          or special accessibility features in mainstream user agents (for example, a 'show
-         captions' option in a media player). That is, the Success Criteria require that something
+         captions' option in a media player). That is, the success criteria require that something
          be done in the Web content that would make it possible for assistive technologies
          to successfully present the content's information to the user. For example, a picture
          that you were supposed to click on to go to a topic would not be accessible to a person
@@ -851,7 +850,7 @@ <h3>Accessibility Support Statements</h3>
       
       <h2>Understanding "Programmatically Determined"</h2>
       
-      <p>Several Success Criteria require that content (or certain aspects of content) can
+      <p>Several success criteria require that content (or certain aspects of content) can
          be "programmatically determined." This means that the content is authored in such
          a way that user agents, including assistive technologies, can access the information.
       </p>
@@ -859,7 +858,7 @@ <h2>Understanding "Programmatically Determined"</h2>
       <p>In order for content created with Web technologies (such as HTML, CSS, PDF, GIF, MPEG, etc.) to be accessible to people with different types of disabilities, it is
          essential that the technologies used work with the accessibility features of browsers
          and other user agents, including assistive technologies. In order for something to
-         meet a Success Criterion that requires it to be "programmatically determined," it
+         meet a success criterion that requires it to be "programmatically determined," it
          would need to be implemented using a technology that has assistive technology support.
       </p>
       
@@ -929,7 +928,7 @@ <h2>Understanding Conforming Alternate Versions</h2>
          <h3>Why permit alternate versions?</h3>
          
          <p>Why does WCAG permit conforming alternate versions of Web pages to be included in
-            conformance claims? That is, why include pages that do not satisfy the Success Criteria
+            conformance claims? That is, why include pages that do not satisfy the success criteria
             for a conformance level in the scope of conformance or a claim?
          </p>
          
@@ -944,7 +943,7 @@ <h3>Why permit alternate versions?</h3>
                providing an accessible alternative page in technologies that are accessibility supported.
                Users for whom the new technology is adequately supported get the benefits of the
                new version. Authors who look ahead to future accessibility support can satisfy the
-               Success Criteria now with the alternate version page, and also work with the other
+               success criteria now with the alternate version page, and also work with the other
                page to build in future access when assistive technology (AT) support is available.
             </li>
             
@@ -979,7 +978,7 @@ <h3>Why permit alternate versions?</h3>
             <li>Sometimes, the best experience for users with certain types of disabilities is provided
                by tailoring a Web page specifically to accommodate that disability. In such a situation,
                it may not be possible or practical to make the Web page accommodate all disabilities
-               by satisfying all of the Success Criteria. The alternate versions requirement permits
+               by satisfying all of the success criteria. The alternate versions requirement permits
                such specialized pages to be included within a conformance claim as long as there
                is a fully conformant 'alternate version' page.
             </li>
@@ -998,10 +997,10 @@ <h3>Why permit alternate versions?</h3>
             
          </ul>
          
-         <p>A concern when permitting Web pages that do not satisfy the Success Criteria is that
+         <p>A concern when permitting Web pages that do not satisfy the success criteria is that
             people with disabilities will encounter these non-conforming pages, not be able to
             access their content, and not be able to find the “conforming alternate version."
-            A key part of the Alternate Versions provision, therefore, is the ability to find
+            A key part of the alternate versions provision, therefore, is the ability to find
             the conforming page (the alternate version) from the non-conforming page when it is
             encountered. The conformance requirement that permits alternate pages, therefore,
             also requires a way for users to find the accessible version among the alternate versions.
@@ -1040,7 +1039,7 @@ <h3>Techniques for Providing a Conforming Alternate Version</h3>
             <h4>Sufficient Techniques for Providing Conforming Alternative Versions of Web pages</h4>
             
             <p>Each numbered item in this section represents a technique or combination of techniques
-               that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is
+               that the WCAG Working Group deems sufficient for meeting this success criterion. However, it is
                not necessary to use these particular techniques. For information on using other techniques,
                see 
                <a href="understanding-techniques"></a>, particularly the "Other Techniques" section.
@@ -1165,7 +1164,7 @@ <h4>Examples of Conforming Alternate Versions</h4>
                      site might limit their ability to address the needs of diverse office locations that
                      have different technology bases and individual employees who use a wide variety of
                      user agents and assistive technologies. To address these concerns, the company created
-                     an alternate version of the content that met all Level A Success Criteria using a
+                     an alternate version of the content that met all Level A success criteria using a
                      more limited set of uses of accessibility-supported content technologies. 
                      The two versions link to each other.
                      
diff --git a/understanding/documenting-accessibility-support.html b/understanding/documenting-accessibility-support.html
index 185fa6c654..d9b619e75e 100644
--- a/understanding/documenting-accessibility-support.html
+++ b/understanding/documenting-accessibility-support.html
@@ -1,11 +1,11 @@
 <!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
 	<head>
 		<title>Documenting Accessibility Support for Uses of a Web Technology</title>
 	</head>
 	<body>
 		<h1>Documenting Accessibility Support for Uses of a Web Technology</h1>
-		<p>The documentation of accessibility support for uses of a Web technology provides the information needed to determine whether it is possible to satisfy the WCAG 2.1 Success Criteria for a particular environment. </p>
+		<p>The documentation of accessibility support for uses of a Web technology provides the information needed to determine whether it is possible to satisfy the WCAG 2 success criteria for a particular environment. </p>
 		<p>Accessibility Support documentation for uses of a Web technology includes the following information: </p>
 		<ul>
 			<li>
@@ -21,7 +21,7 @@ <h1>Documenting Accessibility Support for Uses of a Web Technology</h1>
 						<p> Ways of using the technology that are supported by the user agent; ideally, there are ways to meet all of the success criteria, but exceptions should be noted. </p>
 					</li>
 					<li>
-						<p> Known limitations of the user agent support for uses of the technology to meet Success Criteria </p>
+						<p> Known limitations of the user agent support for uses of the technology to meet success criteria </p>
 					</li>
 				</ul>
 			</li>
diff --git a/understanding/intro.html b/understanding/intro.html
index fb8cba8688..0ccbf90ac6 100644
--- a/understanding/intro.html
+++ b/understanding/intro.html
@@ -1,23 +1,23 @@
 <!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
 	<head>
-		<title>Introduction to Understanding WCAG 2.1</title>
+		<title>Introduction to Understanding WCAG 2</title>
 	</head>
 	<body>
-		<h1>Introduction to Understanding WCAG 2.1</h1>
-		<p>Understanding WCAG 2.1 is an essential guide to understanding and using "<a href="https://www.w3.org/TR/WCAG21/">Web Content Accessibility Guidelines 2.1</a>". Although the normative definition and requirements for WCAG 2.1 can all be found in the WCAG 2.1 document itself, the concepts and provisions may be new to some people. Understanding WCAG 2.1 provides a non-normative extended commentary on each guideline and each Success Criterion to help readers better understand the intent and how the guidelines and Success Criteria work together. It also provides examples of techniques or combinations of techniques that the Working Group has identified as being sufficient to meet each Success Criterion. Links are then provided to write-ups for each of the techniques.</p>
-		<p>This is not an introductory document. It is a detailed technical description of the guidelines and their Success Criteria. See <a href="https://www.w3.org/WAI/intro/wcag">Web Content Accessibility Guidelines (WCAG) Overview</a> for an introduction to WCAG, supporting technical documents, and educational material. </p>
-		<p>Understanding WCAG 2.1 is organized by guideline. There is an <em>Understanding Guideline X.X</em> section for each guideline. The intent and any advisory techniques that are related to the guideline but not specifically related to any of its Success Criteria are listed there as well.</p>
-		<p>The <em>Understanding Guidelines X.X</em> section is then followed by a <em>Understanding Success Criterion X.X.X</em> section for each Success Criterion of that guideline. These sections each contain:</p>
+		<h1>Introduction to Understanding WCAG 2</h1>
+		<p>Understanding WCAG 2 is an essential guide to understanding and using "<a href="https://www.w3.org/TR/WCAG/">Web Content Accessibility Guidelines 2</a>". Although the normative definition and requirements for WCAG 2 can all be found in the WCAG 2 document itself, the concepts and provisions may be new to some people. Understanding WCAG 2 provides a non-normative extended commentary on each guideline and each success criterion to help readers better understand the intent and how the guidelines and success criteria work together. It also provides examples of techniques or combinations of techniques that the Working Group has identified as being sufficient to meet each success criterion. Links are then provided to write-ups for each of the techniques.</p>
+		<p>This is not an introductory document. It is a detailed technical description of the guidelines and their success criteria. See <a href="https://www.w3.org/WAI/intro/wcag">Web Content Accessibility Guidelines (WCAG) Overview</a> for an introduction to WCAG, supporting technical documents, and educational material. </p>
+		<p>Understanding WCAG 2 is organized by guideline. There is an <em>Understanding Guideline X.X</em> section for each guideline. The intent and any advisory techniques that are related to the guideline but not specifically related to any of its success criteria are listed there as well.</p>
+		<p>The <em>Understanding Guidelines X.X</em> section is then followed by a <em>Understanding success criterion X.X.X</em> section for each success criterion of that guideline. These sections each contain:</p>
 		<ul>
 			<li>
-				<p>The Success Criterion as it appears in WCAG 2.1</p>
+				<p>The success criterion as it appears in WCAG 2</p>
 			</li>
 			<li>
-				<p>Intent of the Success Criterion</p>
+				<p>Intent of the success criterion</p>
 			</li>
 			<li>
-				<p>Benefits (how the Success Criterion helps people with disabilities)</p>
+				<p>Benefits (how the success criterion helps people with disabilities)</p>
 			</li>
 			<li>
 				<p>Examples</p>
@@ -29,21 +29,21 @@ <h1>Introduction to Understanding WCAG 2.1</h1>
 				<p>Techniques or combinations of techniques that are sufficient to meet the guidelines</p>
 			</li>
 			<li>
-				<p>Common failures of this Success Criterion</p>
+				<p>Common failures of this success criterion</p>
 			</li>
 			<li>
-				<p>Additional advisory techniques that go beyond what is required to meet the Success Criterion but can be used to make some or all types of content more accessible. Use of advisory techniques does not impact the level of conformance claimed. </p>
+				<p>Additional advisory techniques that go beyond what is required to meet the success criterion but can be used to make some or all types of content more accessible. Use of advisory techniques does not impact the level of conformance claimed. </p>
 			</li>
 			<li>
-				<p>Key terms for this Success Criterion (taken from the WCAG 2.1 Glossary)</p>
+				<p>Key terms for this success criterion (taken from the WCAG 2 Glossary)</p>
 			</li>
 		</ul>
-		<p>Links are provided from each Guideline in WCAG 2.1 directly to each <em>Understanding Guideline X.X</em> in this document. Similarly, there is a link from each Success Criterion in WCAG 2.1 to the <em>Understanding Success Criterion X.X.X</em> section in this document. </p>
-		<p>For information about individual techniques, follow the links throughout this document to the techniques of interest in the <a href="https://www.w3.org/WAI/WCAG21/Techniques/">Techniques for WCAG 2.1</a> document.</p>
+		<p>Links are provided from each Guideline in WCAG 2 directly to each <em>Understanding Guideline X.X</em> in this document. Similarly, there is a link from each success criterion in WCAG 2 to the <em>Understanding Success Criterion X.X.X</em> section in this document. </p>
+		<p>For information about individual techniques, follow the links throughout this document to the techniques of interest in the <a href="../Techniques/">Techniques for WCAG 2</a> document.</p>
 		<p>For links to information on different disabilities and assistive technologies see <a href="https://en.wikipedia.org/wiki/Disability">Disabilities on Wikipedia</a>. </p>
 		<section>
 			<h2>Understanding the Four Principles of Accessibility</h2>
-			<p>The guidelines and Success Criteria are organized around the following four principles, which lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:</p>
+			<p>The guidelines and success criteria are organized around the following four principles, which lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:</p>
 			<ol>
 				<li>
 					<p> Perceivable - Information and user interface components must be presentable to users in ways they can perceive.</p>
@@ -79,30 +79,30 @@ <h2>Understanding the Four Principles of Accessibility</h2>
 				</li>
 			</ol>
 			<p>If any of these are not true, users with disabilities will not be able to use the Web. </p>
-			<p>Under each of the principles are guidelines and Success Criteria that help to address these principles for people with disabilities. There are many general usability guidelines that make content more usable by all people, including those with disabilities. However, in WCAG 2.1, we only include those guidelines that address problems particular to people with disabilities. This includes issues that block access or interfere with access to the Web more severely for people with disabilities.</p>
+			<p>Under each of the principles are guidelines and success criteria that help to address these principles for people with disabilities. There are many general usability guidelines that make content more usable by all people, including those with disabilities. However, in WCAG 2, we only include those guidelines that address problems particular to people with disabilities. This includes issues that block access or interfere with access to the Web more severely for people with disabilities.</p>
 		</section>
 		<section>
 			<h2>Layers of Guidance</h2>
 			<section>
 				<h3>The Guidelines</h3>
-				<p>Under each principle there is a list of guidelines that address the principle. There are a total of 12 guidelines. A convenient list of just the guidelines can be found in the <a class="gl-ref" href="https://www.w3.org/TR/WCAG21/#toc">WCAG 2.1 table of contents</a>. One of the key objectives of the guidelines is to ensure that content is directly accessible to as many people as possible, and capable of being re-presented in different forms to match different peoples' sensory, physical and cognitive abilities.</p>
+				<p>Under each principle there is a list of guidelines that address the principle. There are a total of 13 guidelines. A convenient list of just the guidelines can be found in the <a class="gl-ref" href="https://www.w3.org/TR/WCAG/#toc">WCAG 2 table of contents</a>. One of the key objectives of the guidelines is to ensure that content is directly accessible to as many people as possible, and capable of being re-presented in different forms to match different peoples' sensory, physical and cognitive abilities.</p>
 			</section>
 			<section>
 				<h3>Success Criteria</h3>
-				<p>Under each guideline, there are Success Criteria that describe specifically what must be achieved in order to <a class="gl-ref" href="https://www.w3.org/TR/WCAG21/#dfn-conform">conform</a> to this standard. They are similar to the "checkpoints" in WCAG 1.0. Each Success Criterion is written as a statement that will be either true or false when specific Web content is tested against it. The Success Criteria are written to be technology neutral.</p>
-				<p>All WCAG 2.1 Success Criteria are written as testable criteria for objectively determining if content satisfies the Success Criteria. While some of the testing can be automated using software evaluation programs, others require human testers for part or all of the test.</p>
-				<p>Although content may satisfy the Success Criteria, the content may not always be usable by people with a wide variety of disabilities. Professional reviews utilizing recognized qualitative heuristics are important in achieving accessibility for some audiences. In addition, usability testing is recommended. Usability testing aims to determine how well people can use the content for its intended purpose.</p>
+				<p>Under each guideline, there are success criteria that describe specifically what must be achieved in order to <a class="gl-ref" href="https://www.w3.org/TR/WCAG/#dfn-conform">conform</a> to this standard. They are similar to the "checkpoints" in WCAG 1.0. Each success criterion is written as a statement that will be either true or false when specific Web content is tested against it. The success criteria are written to be technology neutral.</p>
+				<p>All WCAG 2 success criteria are written as testable criteria for objectively determining if content satisfies the success criteria. While some of the testing can be automated using software evaluation programs, others require human testers for part or all of the test.</p>
+				<p>Although content may satisfy the success criteria, the content may not always be usable by people with a wide variety of disabilities. Professional reviews utilizing recognized qualitative heuristics are important in achieving accessibility for some audiences. In addition, usability testing is recommended. Usability testing aims to determine how well people can use the content for its intended purpose.</p>
 				<p>The content should be tested by those who understand how people with different types of disabilities use the Web. It is recommended that users with disabilities be included in test groups when performing human testing. </p>
-				<p>Each Success Criterion for a guideline has a link to the section of the How to Meet document that provides:</p>
+				<p>Each success criterion for a guideline has a link to the section of the How to Meet document that provides:</p>
 				<ul>
 					<li>
-						<p>sufficient techniques for meeting the Success Criterion,</p>
+						<p>sufficient techniques for meeting the success criterion,</p>
 					</li>
 					<li>
 						<p>optional advisory techniques, and</p>
 					</li>
 					<li>
-						<p>descriptions of the intent of the Success Criteria, including benefits, and examples.</p>
+						<p>descriptions of the intent of the success criterion, including benefits, and examples.</p>
 					</li>
 				</ul>
 			</section>
diff --git a/understanding/refer-to-wcag.html b/understanding/refer-to-wcag.html
index 8fb4adb859..22b4450799 100644
--- a/understanding/refer-to-wcag.html
+++ b/understanding/refer-to-wcag.html
@@ -1,60 +1,60 @@
 <!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
 	<head>
-		<title>How to refer to WCAG 2.1 from other documents</title>
+		<title>How to refer to WCAG 2 from other documents</title>
 	</head>
 	<body>
-		<h1>How to refer to WCAG 2.1 from other documents</h1>
-		<p>The following examples show how to reference WCAG 2.1 in various situations. For additional guidance, see <a href="https://www.w3.org/WAI/intro/linking.html">Referencing and Linking to WAI Guidelines and Technical Documents</a>.</p>
-		<p> Please note that the following language for referencing WCAG 2.1 can be inserted into your own documents. </p>
+		<h1>How to refer to WCAG 2 from other documents</h1>
+		<p>The following examples show how to reference WCAG 2 in various situations. For additional guidance, see <a href="https://www.w3.org/WAI/intro/linking.html">Referencing and Linking to WAI Guidelines and Technical Documents</a>.</p>
+		<p> Please note that the following language for referencing WCAG 2 can be inserted into your own documents. </p>
 		<section id="conformance-referencing-information">
 			<h2>Information references</h2>
-			<p>When referencing WCAG 2.1 in an informational fashion, the following format can be used.</p>
-			<p><em>Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/, Latest version at https://www.w3.org/TR/WCAG21/)</em></p>
+			<p>When referencing WCAG 2 in an informational fashion, the following format can be used.</p>
+			<p><em>Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/, Latest version at https://www.w3.org/TR/WCAG22/)</em></p>
 		</section>
 		<section id="conformance-referencing-should">
-			<h2>When referring to WCAG 2.1 from another standard with a "should" statement</h2>
-			<p>When referencing WCAG 2.1 from within a <strong>should</strong> statement in a standard (or advisory statement in a regulation), then the full WCAG 2.1 should be referenced. This would mean that all three levels of WCAG 2.1 should be considered but that none are required. The format for referencing WCAG 2.1 from a "should" statement therefore, is:</p>
-			<p><em>Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year. (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/)</em></p>
+			<h2>When referring to WCAG 2 from another standard with a "should" statement</h2>
+			<p>When referencing WCAG 2 from within a <strong>should</strong> statement in a standard (or advisory statement in a regulation), then the full WCAG 2 should be referenced. This would mean that all three levels of WCAG 2 should be considered but that none are required. The format for referencing WCAG 2 from a "should" statement therefore, is:</p>
+			<p><em>Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year. (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/)</em></p>
 		</section>
 		<section id="conformance-referencing-must">
-			<h2>When referring to WCAG 2.1 from another standard with a "shall or must" statement</h2>
-			<p>When citing WCAG 2.1 as part of a requirement (e.g., a <strong>shall or must </strong> statement in a standard or regulation), the reference must include the specific parts of WCAG 2.1 that are intended to be required. When referencing WCAG 2.1 in this manner, the following rules apply: </p>
+			<h2>When referring to WCAG 2 from another standard with a "shall or must" statement</h2>
+			<p>When citing WCAG 2 as part of a requirement (e.g., a <strong>shall or must </strong> statement in a standard or regulation), the reference must include the specific parts of WCAG 2 that are intended to be required. When referencing WCAG 2 in this manner, the following rules apply: </p>
 			<ol class="enumar">
 				<li>
-					<p>Conformance at any level of WCAG 2.1 requires that all of the Level A Success Criteria be met. References to WCAG 2.1 conformance cannot be for any subset of Level A. </p>
+					<p>Conformance at any level of WCAG 2 requires that all of the Level A success criteria be met. References to WCAG 2 conformance cannot be for any subset of Level A. </p>
 				</li>
 				<li>
-					<p>Beyond Level A, a "shall or must" reference may include any subset of provisions in Levels AA and AAA. For example, "<em>all of Level A and [some specific list of Success Criteria in Level AA and Level AAA]</em>" be met. </p>
+					<p>Beyond Level A, a "shall or must" reference may include any subset of provisions in Levels AA and AAA. For example, "<em>all of Level A and [some specific list of success criteria in Level AA and Level AAA]</em>" be met. </p>
 				</li>
 				<li>
-					<p>If Level AA conformance to WCAG 2.1 is specified, then all Level A and all Level AA Success Criteria must be met.</p>
+					<p>If Level AA conformance to WCAG 2 is specified, then all Level A and all Level AA success criteria must be met.</p>
 				</li>
 				<li>
-					<p>If Level AAA conformance to WCAG 2.1 is specified, then all Level A, all Level AA, and all Level AAA Success Criteria must be met.</p>
-					<p class="prefix"><em>Note 1: </em>It is not recommended that Level AAA conformance ever be required for entire sites as a general policy because it is not possible to satisfy all Level AAA Success Criteria for some content. </p>
-					<p class="prefix"><em>Note 2: </em>The sets of Success Criteria defined in WCAG are interdependent and individual Success Criteria rely on each other's definitions in ways which may not be immediately obvious to the reader. Any set of Success Criteria must include all of the Level A provisions.</p>
+					<p>If Level AAA conformance to WCAG 2 is specified, then all Level A, all Level AA, and all Level AAA success criteria must be met.</p>
+					<p class="prefix"><em>Note 1: </em>It is not recommended that Level AAA conformance ever be required for entire sites as a general policy because it is not possible to satisfy all Level AAA success criteria for some content. </p>
+					<p class="prefix"><em>Note 2: </em>The sets of success criteria defined in WCAG 2 are interdependent and individual success criteria rely on each other's definitions in ways which may not be immediately obvious to the reader. Any set of success criteria must include all of the Level A provisions.</p>
 				</li>
 			</ol>
 		</section>
 		<section id="conformance-referencing-examples">
 			<h2>Examples</h2>
 			<p><strong>To cite only the Level A Success Criteria (Single-A conformance):</strong></p>
-			<p><em>Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria. (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/)</em></p>
+			<p><em>Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria. (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/)</em></p>
 			<p><strong>To cite the Levels A and AA Success Criteria (Double-A conformance):</strong></p>
-			<p><em>Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A &amp; Level AA Success Criteria. (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/)</em></p>
+			<p><em>Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year, Level A &amp; Level AA Success Criteria. (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/)</em></p>
 			<p><strong>To cite Level A Success Criteria and selected Success Criteria from Level AA and Level AAA: </strong></p>
-			<p><em>Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.x.x, 2.y.y, … 3.z.z. (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/)</em></p>
-			<p><strong>Example of use of a WCAG reference in a "shall or must" statement.</strong></p>
-			<p>All Web content on publicly available Web sites shall conform to Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.2.3, 2.4.5-6, 3.1.2 (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/)</p>
+			<p><em>Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.x.x, 2.y.y, … 3.z.z. (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/)</em></p>
+			<p><strong>Example of use of a WCAG 2 reference in a "shall or must" statement.</strong></p>
+			<p>All Web content on publicly available Web sites shall conform to Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.2.3, 2.4.5-6, 3.1.2 (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/)</p>
 		</section>
 		<section id="conformance-referencing-support">
-			<h2>Referring to content from WCAG support documents</h2>
-			<p>Techniques, which are listed in Understanding WCAG 2.1 and described in other supporting documents, are not part of the normative WCAG 2.1 Recommendation and should not be cited using the citation for the WCAG 2.1 Recommendation itself. References to techniques in support documents should be cited separately.</p>
-			<p>Techniques can be cited based on the individual Technique document or on the master WCAG 2.1 Techniques document. For example, the technique "Using alt attributes on img elements" could be cited as</p>
+			<h2>Referring to content from WCAG 2 support documents</h2>
+			<p>Techniques, which are listed in Understanding WCAG 2 and described in other supporting documents, are not part of the normative WCAG 2 Recommendation and should not be cited using the citation for the WCAG 2 Recommendation itself. References to techniques in support documents should be cited separately.</p>
+			<p>Techniques can be cited based on the individual Technique document or on the master WCAG 2 Techniques document. For example, the technique "Using alt attributes on img elements" could be cited as</p>
 			<p class="indented"><em>"Using alt attributes on img elements," W3C World Wide Web Consortium Note. (URI: {URI of technique}) </em></p>
 			<p class="indented">or</p>
-			<p class="indented"><em>W3C World Wide Web Consortium (200x): WCAG2.0 HTML Techniques (URI: {URI of HTML Techniques})</em></p>
+			<p class="indented"><em>W3C World Wide Web Consortium (20xx): WCAG2.2 HTML Techniques (URI: {URI of HTML Techniques})</em></p>
 			<p class="indented"><strong>Techniques are not designed to be referenced as "required"</strong> from any standard or regulation.Standards and regulations should not make any specific technique mandatory, though they may choose to recommend techniques.</p>
 		</section>
 	</body>
diff --git a/understanding/understanding-act-rules.html b/understanding/understanding-act-rules.html
index 4e01230946..ef08e26b36 100644
--- a/understanding/understanding-act-rules.html
+++ b/understanding/understanding-act-rules.html
@@ -1,31 +1,31 @@
 <!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
 	<head>
-		<title>Understanding Test Rules for WCAG Success Criteria</title>
+		<title>Understanding Test Rules for WCAG 2 Success Criteria</title>
 	</head>
 	<body>
-		<h1>Understanding Test Rules for WCAG Success Criteria</h1>
+		<h1>Understanding Test Rules for WCAG 2 Success Criteria</h1>
 		
-		<p>Test Rules provide guidance for developers of automated testing tools and manual testing methodologies, to help ensure consistent interpretation of WCAG Success Criteria.</p>
+		<p>Test Rules provide guidance for developers of automated testing tools and manual testing methodologies, to help ensure consistent interpretation of WCAG 2 success criteria.</p>
 		<p>W3C's <a href="https://www.w3.org/WAI/standards-guidelines/act/rules/">List of Test Rules for WCAG 2</a> is updated periodically. They are developed according to the <a href="https://www.w3.org/TR/act-rules-format/">Accessibility Conformance Testing (ACT) Rules Format 1.0</a> standard.</p>
 		<p><a href="conformance">Understanding Conformance</a> provides related information, including on <a href="conformance#accessibility-support">understanding accessibility support</a>.</p>
 		
 		<section>
 			<h2>Test Rules Rules are Informative</h2>
-			<p><em>Test Rules are informative — that means they are not required for determining conformance. The basis for determining conformance to WCAG is the success criteria from the WCAG standard — not the Test Rules.</em></p>
-			<p>While W3C's <a href="https://www.w3.org/WAI/standards-guidelines/act/rules/">List of Test Rules for WCAG 2</a> are reviewed by the W3C Accessibility Guidelines Working Group (AGWG), they are not vetted to the same degree as the W3C Web Content Accessibility Guidelines (WCAG) standard (called <em>W3C Recommendation</em>). The WCAG standard is the normative reference on determining conformance.</p>
+			<p><em>Test Rules are informative — that means they are not required for determining conformance. The basis for determining conformance to WCAG 2 are the success criteria from the WCAG 2 standard — not the Test Rules.</em></p>
+			<p>While W3C's <a href="https://www.w3.org/WAI/standards-guidelines/act/rules/">List of Test Rules for WCAG 2</a> are reviewed by the W3C Accessibility Guidelines Working Group (AGWG), they are not vetted to the same degree as the W3C Web Content Accessibility Guidelines (WCAG) standard (called <em>W3C Recommendation</em>). The WCAG 2 standard is the normative reference on determining conformance.</p>
 		</section>
 		
 		<section>
 			<h2>Test Rules are Partial Checks</h2>
-			<p>Test Rules typically check specific aspects of WCAG success criteria. For example, that a table cell has a header rather than the entire WCAG 2.2 success criterion 1.3.1 "Info and Relationships", which applies to many more information structures on a web page. In fact, this example rule would not even check the validity of the table header, only if the header exists for a given table cell.</p>
-			<p>Test Rules are also technology-specific. For example, the aforementioned table header example would be specific to HTML, possibly enriched with WAI-ARIA roles and properties, but not to other formats with tables. WCAG 2.2 success criteria are designed to be technology-agnostic and applicable to all web technologies.</p>
+			<p>Test Rules typically check specific aspects of WCAG 2 success criteria. For example, that a table cell has a header rather than the entire WCAG 2 success criterion 1.3.1 "Info and Relationships", which applies to many more information structures on a web page. In fact, this example rule would not even check the validity of the table header, only if the header exists for a given table cell.</p>
+			<p>Test Rules are also technology-specific. For example, the aforementioned table header example would be specific to HTML, possibly enriched with WAI-ARIA roles and properties, but not to other formats with tables. WCAG 2 success criteria are designed to be technology-agnostic and applicable to all web technologies.</p>
 		</section>
 		
 		<section>
 			<h2>Test Rules Check for Failures</h2>
-			<p>Test Rules are designed to check failures in satisfying WCAG success criteria. That is, when content fails Test Rules, it means that the content does not satisfy the corresponding success criteria. However, when content passes Test Rules, it means that no corresponding failures were detected — it does not necessarily mean that the content satisfies all aspects of the corresponding success criteria.</p>
-			<p>The reason for this is because WCAG success criteria typically cover several aspects and technologies, while Test Rules only check specific aspects. Checking that content satisfies all aspects of WCAG success criteria typically requires further verification by human testers.</p>
+			<p>Test Rules are designed to check failures in satisfying WCAG 2 success criteria. That is, when content fails Test Rules, it means that the content does not satisfy the corresponding success criteria. However, when content passes Test Rules, it means that no corresponding failures were detected — it does not necessarily mean that the content satisfies all aspects of the corresponding success criteria.</p>
+			<p>The reason for this is because WCAG 2 success criteria typically cover several aspects and technologies, while Test Rules only check specific aspects. Checking that content satisfies all aspects of WCAG 2 success criteria typically requires further verification by human testers.</p>
 			<p class="note"><a href="conformance#cc1">WCAG 2 Conformance Requirement 1</a> allows for "conforming alternate versions". That means that content may still conform to WCAG 2, even when content fails Test Rules, thus does not satisfy the corresponding success criteria.</p>
 		</section>
 		
@@ -53,7 +53,7 @@ <h2>Structure of Test Rules</h2>
 						<li><strong>Composite Rule</strong> – combine outcome from multiple atomic rules to one outcome</li>
 					</ul>
 				</li>
-				<li><strong>Accessibility Requirements Mapping</strong> – maps the Test Rule to particular accessibility requirements; in this suite of rules we use Web Content Accessibility Guidelines (WCAG) 2 Success Criteria</li>
+				<li><strong>Accessibility Requirements Mapping</strong> – maps the Test Rule to particular accessibility requirements; in this suite of rules we use Web Content Accessibility Guidelines (WCAG) 2 success criteria</li>
 				<li><strong>Rule Input</strong> – describes the scope of input into Test Rules, which is one of the following:
 					<ul>
 						<li><strong>Input Aspects</strong> – input into atomic rules, such as DOM Tree and CSS Styling etc.</li>
diff --git a/understanding/understanding-metadata.html b/understanding/understanding-metadata.html
index 759498f57b..7dee0f25ca 100644
--- a/understanding/understanding-metadata.html
+++ b/understanding/understanding-metadata.html
@@ -1,14 +1,14 @@
 <!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
 	<head>
 		<title>Understanding Metadata</title>
 	</head>
 	<body>
 		<h1>Understanding Metadata</h1>
-		<p>This section discusses metadata techniques that can be employed to satisfy WCAG 2.1 Success Criteria. For more information about metadata see resources below. </p>
+		<p>This section discusses metadata techniques that can be employed to satisfy WCAG 2 success criteria. For more information about metadata see resources below. </p>
 		<p>At its most basic level, metadata is essentially 'data about data' and is used to both describe and find resources. </p>
 		<p>Metadata is a powerful tool that can be used for describing Web pages and accessible components of Web pages as well as associating alternate versions of Web content to each other. These descriptions in turn allows users to locate specific information they need or prefer. </p>
-		<p>In conjunction with WCAG, metadata can play a number of roles including: </p>
+		<p>In conjunction with WCAG 2, metadata can play a number of roles including: </p>
 		<ol>
 			<li>
 				<p> Metadata can be used to associate conforming alternate versions of Web pages with Web pages which do not conform, in order to allow users to find the conforming alternate version when they land on a non-conforming page that they cannot use. </p>
diff --git a/understanding/understanding-techniques.html b/understanding/understanding-techniques.html
index 8bb496e315..22e861ae18 100644
--- a/understanding/understanding-techniques.html
+++ b/understanding/understanding-techniques.html
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <html xmlns="http://www.w3.org/1999/xhtml">
 	<head>
-		<title>Understanding Techniques for WCAG Success Criteria</title>
+		<title>Understanding Techniques for WCAG 2 Success Criteria</title>
 	</head>
 	<body>
-		<h1>Understanding Techniques for WCAG Success Criteria</h1>
-		<p>WCAG 2.1 guidelines and success criteria are designed to be broadly applicable to current and future web technologies, including dynamic applications, mobile, digital television, etc. They are stable and do not change.</p>
-		<p>Specific guidance for authors and evaluators on meeting the WCAG success criteria is provided in techniques, which include code examples, resources, and tests. W3C's <a href="https://www.w3.org/WAI/WCAG21/Techniques/">Techniques for WCAG 2.1</a> document is updated periodically, about twice per year, to cover more current best practices and changes in technologies and tools.</p>
-		<p>The three types of guidance in <a href="https://www.w3.org/WAI/WCAG21/Techniques/">Techniques for WCAG 2.1</a> are explained below:</p>
+		<h1>Understanding Techniques for WCAG 2 Success Criteria</h1>
+		<p>WCAG 2 guidelines and success criteria are designed to be broadly applicable to current and future web technologies, including dynamic applications, mobile, digital television, etc. They are stable and do not change.</p>
+		<p>Specific guidance for authors and evaluators on meeting the WCAG 2 success criteria is provided in techniques, which include code examples, resources, and tests. W3C's <a href="../Techniques/">Techniques for WCAG 2</a> document is updated periodically, about twice per year, to cover more current best practices and changes in technologies and tools.</p>
+		<p>The three types of guidance in <a href="../Techniques/">Techniques for WCAG 2</a> are explained below:</p>
 		<ul>
 			<li>
 				<p>Sufficient techniques</p>
@@ -40,14 +40,14 @@ <h1>Understanding Techniques for WCAG Success Criteria</h1>
 		<p><a href="conformance">Understanding Conformance</a> provides related information, including on <a href="conformance#accessibility-support">understanding accessibility support</a>.</p>
 		<section>
 			<h2>Techniques are Informative</h2>
-			<p><em>Techniques are informative—that means they are not required. The basis for determining conformance to WCAG 2.1 is the success criteria from the WCAG 2.1 standard—not the techniques.</em></p>
-			<p class="prefix"><em>Note 1: </em>W3C cautions against requiring W3C's sufficient techniques. The only thing that should be required is meeting the WCAG 2.1 success criteria. To learn more, see:</p>
+			<p><em>Techniques are informative — that means they are not required. The basis for determining conformance to WCAG 2 are the success criteria from the WCAG 2 standard — not the techniques.</em></p>
+			<p class="prefix"><em>Note 1: </em>W3C cautions against requiring W3C's sufficient techniques. The only thing that should be required is meeting the WCAG 2 success criteria. To learn more, see:</p>
 			<ul>
 				<li>
-					<p><a href="https://www.w3.org/WAI/WCAG20/wcag2faq.html#techsnot">What would be the negative consequences of allowing <em>only</em> W3C's published techniques to be used for conformance to WCAG 2.1?</a> in the WCAG 2 FAQ</p>
+					<p><a href="https://www.w3.org/WAI/standards-guidelines/wcag/faq/#techsnot">What would be the negative consequences of allowing <em>only</em> W3C's published techniques to be used for conformance to WCAG 2?</a> in the WCAG 2 FAQ</p>
 				</li>
 			</ul>
-			<p class="prefix"><em>Note 2: </em><a href="https://www.w3.org/WAI/WCAG21/Techniques/">Techniques for WCAG 2.1</a> uses the words "must" and "should" only to clarify guidance within the techniques, not to convey requirements for WCAG.</p>
+			<p class="prefix"><em>Note 2: </em><a href="../Techniques/">Techniques for WCAG 2</a> uses the words "must" and "should" only to clarify guidance within the techniques, not to convey requirements for WCAG 2.</p>
 		</section>
 		<section>
 			<h2>Sufficient Techniques</h2>
@@ -60,7 +60,7 @@ <h2>Sufficient Techniques</h2>
 					<p>From an evaluator's perspective: If web content implements the sufficient techniques for a given criterion correctly and it is <a href="conformance#accessibility-support">accessibility-supported</a> for the content's users, it conforms to that success criterion. (The converse is not true; if content does not implement these sufficient techniques, it does not necessarily fail the success criteria, as explained in <a href="#understanding-techniques-tests">Testing Techniques</a> below.)</p>
 				</li>
 			</ul>
-			<p>There may be other ways to meet success criteria besides the sufficient techniques in W3C's <a href="https://www.w3.org/WAI/WCAG21/Techniques/">Techniques for WCAG 2.1</a> document, as explained in <a href="#understanding-techniques-othertechs">Other Techniques</a> below. <em>(See also <a href="#understanding-techniques-informative">Techniques are Informative</a> above.)</em></p>
+			<p>There may be other ways to meet success criteria besides the sufficient techniques in W3C's <a href="../Techniques/">Techniques for WCAG 2</a> document, as explained in <a href="#understanding-techniques-othertechs">Other Techniques</a> below. <em>(See also <a href="#understanding-techniques-informative">Techniques are Informative</a> above.)</em></p>
 			<section>
 				<h3>Numbered Lists, "AND"</h3>
 				<p> The W3C-documented sufficient techniques are provided in a numbered list where each list item provides a technique or combination of techniques that can be used to meet the success criterion. Where there are multiple techniques on a numbered list item connected by "AND" then all of the techniques must be used to be sufficient. For example, <a href="info-and-relationships#techniques">Sufficient Techniques for 1.3.1</a> has: "G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text (HTML)".</p>
@@ -100,40 +100,40 @@ <h2>Failures</h2>
 					<p>Authors to know what to avoid,</p>
 				</li>
 				<li>
-					<p>Evaluators to use for checking if content does not meet WCAG success criteria.</p>
+					<p>Evaluators to use for checking if content does not meet WCAG 2 success criteria.</p>
 				</li>
 			</ul>
-			<p>Content that has a <em>failure</em> does not meet WCAG success criteria, unless an alternate version is provided without the failure.</p>
-			<p>If anyone identifies a situation where a documented failure is not correct, please <a href="https://www.w3.org/WAI/WCAG21/comments/">report the situation as a WCAG comment</a> so that it can be corrected or deleted as appropriate.</p>
+			<p>Content that has a <em>failure</em> does not meet WCAG 2 success criteria, unless an alternate version is provided without the failure.</p>
+			<p>If anyone identifies a situation where a documented failure is not correct, please <a href="https://www.w3.org/WAI/standards-guidelines/wcag/commenting/">report the situation as a WCAG 2 comment</a> so that it can be corrected or deleted as appropriate.</p>
 		</section>
 		<section>
 			<h2> General and Technology-specific Techniques</h2>
 			<p><em>General techniques</em> describe basic practices that apply to all technologies. <em>Technology-specific techniques</em> apply to a specific technology.</p>
 			<p>Some success criteria do not have technology-specific techniques and are covered only with general techniques. Therefore, both the general techniques and the relevant technology-specific techniques should be considered.</p>
-			<p>Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2.1 success criteria and conformance requirements. Developers need to be aware of the limitations of specific technologies and provide content in a way that is accessible to people with disabilities.</p>
+			<p>Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2 success criteria and conformance requirements. Developers need to be aware of the limitations of specific technologies and provide content in a way that is accessible to people with disabilities.</p>
 		</section>
 		<section>
 			<h2>Other Techniques</h2>
-			<p>In addition to the techniques in W3C's <a href="https://www.w3.org/WAI/WCAG21/Techniques/">Techniques for WCAG 2.1</a> document, <em>there are other ways to meet WCAG success criteria</em>. W3C's techniques are not comprehensive and may not cover newer technologies and situations.</p>
-			<p><em>Web content does not have to use W3C's published techniques in order to conform to WCAG 2.1.</em><em>(See also <a href="understanding-techniques-informative">Techniques are Informative</a> above.)</em></p>
-			<p>Content authors can develop different techniques. For example, an author could develop a technique for HTML5, <a href="https://www.w3.org/WAI/intro/aria">WAI-ARIA</a>, or other new technology. Other organizations may develop sets of techniques to meet WCAG 2.1 success criteria.</p>
+			<p>In addition to the techniques in W3C's <a href="../Techniques/">Techniques for WCAG 2</a> document, <em>there are other ways to meet WCAG 2 success criteria</em>. W3C's techniques are not comprehensive and may not cover newer technologies and situations.</p>
+			<p><em>Web content does not have to use W3C's published techniques in order to conform to WCAG 2. (See also <a href="understanding-techniques-informative">Techniques are Informative</a> above.)</em></p>
+			<p>Content authors can develop different techniques. For example, an author could develop a technique for HTML5, <a href="https://www.w3.org/WAI/intro/aria">WAI-ARIA</a>, or other new technology. Other organizations may develop sets of techniques to meet WCAG 2 success criteria.</p>
 			<p>Any techniques can be sufficient if:</p>
 			<ul>
 				<li>
 					<p>they satisfy the success criterion, and</p>
 				</li>
 				<li>
-					<p> all of the <a href="conformance">WCAG 2.1 conformance requirements</a> are met.</p>
+					<p> all of the <a href="conformance">WCAG 2 conformance requirements</a> are met.</p>
 				</li>
 			</ul>
 			<section>
 				<h3>Submitting Techniques</h3>
-				<p>The WCAG Working Group encourages people to submit new techniques so that they can be considered for inclusion in updates of the <a href="https://www.w3.org/WAI/WCAG21/Techniques/">Techniques for WCAG 2.1</a> document. Please submit techniques for consideration using the <a href="https://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/">Techniques Submission Form</a>.</p>
+				<p>The WCAG Working Group encourages people to submit new techniques so that they can be considered for inclusion in updates of the <a href="../Techniques/">Techniques for WCAG 2</a> document. Please submit techniques for consideration to the <a href="https://github.com/w3c/wcag/">WCAG repository on GitHub</a>.</p>
 			</section>
 		</section>
 		<section>
 			<h2>Testing Techniques</h2>
-			<p> Each technique has tests that help:</p>
+			<p>Each technique has tests that help:</p>
 			<ul>
 				<li>
 					<p> authors verify that they implemented the technique properly, and</p>
@@ -142,22 +142,22 @@ <h2>Testing Techniques</h2>
 					<p>evaluators determine if web content meets the technique.</p>
 				</li>
 			</ul>
-			<p>The tests are only for a technique, they are not tests for conformance to WCAG success criteria.</p>
+			<p>The tests are only for a technique, they are not tests for conformance to WCAG 2 success criteria.</p>
 			<ul>
 				<li>
 					<p>Failing a technique test does not necessarily mean failing WCAG, because the techniques are discrete (that is, they address one specific point) and they are not required.</p>
 				</li>
 				<li>
-					<p>Content can meet WCAG success criteria in different ways other than W3C's published sufficient techniques.</p>
+					<p>Content can meet WCAG 2 success criteria in different ways other than W3C's published sufficient techniques.</p>
 				</li>
 				<li>
-					<p>Content that passes the sufficient techniques for a specific technology does not necessarily meet all WCAG success criteria. Some success criteria have only general techniques, not technology-specific techniques.</p>
+					<p>Content that passes the sufficient techniques for a specific technology does not necessarily meet all WCAG 2 success criteria. Some success criteria have only general techniques, not technology-specific techniques.</p>
 				</li>
 				<li>
 					<p>The content must be <a href="conformance#accessibility-support">accessibility supported</a> for the content's users. Some sufficient techniques require browser, assistive technology, or other support that some users might not have.</p>
 				</li>
 			</ul>
-			<p>Thus while the techniques are useful for evaluating content, evaluations must go beyond just checking the sufficient technique tests in order to evaluate how content conforms to WCAG success criteria.</p>
+			<p>Thus while the techniques are useful for evaluating content, evaluations must go beyond just checking the sufficient technique tests in order to evaluate how content conforms to WCAG 2 success criteria.</p>
 			<p><em>Failures</em> are particularly useful for evaluations because they do indicate non-conformance (unless an alternate version is provided without the failure).</p>
 		</section>
 		<section>
@@ -170,10 +170,10 @@ <h3>Support Notes Change Over Time</h3>
 		</section>
 		<section>
 			<h2>Using the Techniques</h2>
-			<p><a href="https://www.w3.org/WAI/WCAG21/Techniques/">Techniques for WCAG 2.1</a> is not intended to be used as a stand-alone document. Instead, it is expected that content authors will usually use <a href="https://www.w3.org/WAI/WCAG21/quickref/">How to Meet WCAG 2.1: A customizable quick reference</a> to read the WCAG success criteria, and follow links from there to specific topics in Understanding WCAG 2.1 and to specific techniques.</p>
+			<p><a href="../Techniques/">Techniques for WCAG 2</a> is not intended to be used as a stand-alone document. Instead, it is expected that content authors will usually use <a href="https://www.w3.org/WAI/WCAG22/quickref/">How to Meet WCAG 2.2: A customizable quick reference</a> to read the WCAG 2 success criteria, and follow links from there to specific topics in Understanding WCAG 2 and to specific techniques.</p>
 			<section>
 				<h3>Alternatives must meet success criteria</h3>
-				<p>Some techniques describe how to provide alternate ways for users to get content. For example, <a href="https://www.w3.org/WAI/WCAG21/Techniques/general/G73">G73: Providing a long description in another location...</a> mentions a transcript as an alternative for an audio file. Some alternatives must also conform to WCAG. For example, the transcript itself must meet all relevant success criteria. </p>
+				<p>Some techniques describe how to provide alternate ways for users to get content. For example, <a href="https://www.w3.org/WAI/WCAG22/Techniques/general/G73">G73: Providing a long description in another location...</a> mentions a transcript as an alternative for an audio file. Some alternatives must also conform to WCAG 2. For example, the transcript itself must meet all relevant success criteria. </p>
 			</section>
 			<section>
 				<h3>Example Code</h3>
diff --git a/understanding/understanding-template.html b/understanding/understanding-template.html
index ddb681842d..40e50750b2 100644
--- a/understanding/understanding-template.html
+++ b/understanding/understanding-template.html
@@ -1,14 +1,14 @@
 <!DOCTYPE html>
 <html xmlns="http://www.w3.org/1999/xhtml">
 	<head>
-		<title>WCAG 2.0 Understanding Page</title>
+		<title>WCAG 2 Understanding Page</title>
 		<link rel="stylesheet" type="text/css" href="sources.css"/>
 	</head>
 	<body>
 		<h1>Understanding SC #.#.#</h1>
 		<section id="intent">
 			<h2>Intent</h2>
-			<p class="instructions">This section contains the main explanatory content of the Understanding. It explains why the Guideline or Success Criterion exists and, at a high level, how to meet it.</p>
+			<p class="instructions">This section contains the main explanatory content of the Understanding. It explains why the Guideline or success criterion exists and, at a high level, how to meet it.</p>
 			<section id="benefits">
 				<h3>Benefits</h3>
 				<p class="instructions">This explains how following the success criterion benefits particular types of users with disabilities.</p>
@@ -37,7 +37,7 @@ <h2>Resources</h2>
 		<section id="techniques">
 			<h2>Techniques</h2>
 			<div class="instructions">
-				<p>This section references techniques that can be used to meet the Guideline or Success Criterion. There are sub-sections for sufficient techniques, advisory techniques, and failures. </p>
+				<p>This section references techniques that can be used to meet the Guideline or success criterion. There are sub-sections for sufficient techniques, advisory techniques, and failures. </p>
 				<ul>
 					<li>Within each sub-section, there may be "situations" to describe when a set of techniques need to be considered. Remove the sub-section and heading if situations are not used.</li>
 					<li>Techniques are provided in an unordered list. Reference techniques by linking to the filename of the technique and using the technique ID as link text. Use unlinked plain text if the technique has not been written yet.</li>
@@ -49,7 +49,7 @@ <h2>Techniques</h2>
 			</div>
 			<section id="sufficient">
 				<h3>Sufficient</h3>
-				<p class="instructions">Techniques that are sufficient to meet the Guideline or Success Criterion.</p>
+				<p class="instructions">Techniques that are sufficient to meet the guideline or success criterion.</p>
 				<section class="situation">
 					<h4>Situation</h4>
 					<ul>
@@ -63,12 +63,12 @@ <h4>Situation</h4>
 			</section>
 			<section id="advisory">
 				<h2>Advisory</h2>
-				<p class="instructions">Techniques that are not sufficient by themselves to meet the Guideline or Success Criterion.</p>
+				<p class="instructions">Techniques that are not sufficient by themselves to meet the guideline or success criterion.</p>
 				<p class="instructions">Same template as sufficient techniques.</p>
 			</section>
 			<section id="failure">
 				<h2>Failure</h2>
-				<p class="instructions">Techniques that document conditions that would cause the page not to meet the Guideline or Success Criterion, even if sufficient techniques are also used.</p>
+				<p class="instructions">Techniques that document conditions that would cause the page not to meet the guideline or success criterion, even if sufficient techniques are also used.</p>
 				<p class="instructions">Same template as sufficient techniques.</p>
 			</section>
 		</section>

From 3f488cd6cc47d4b4b79ec5ec30651182d32361e8 Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" <redux@splintered.co.uk>
Date: Mon, 11 Mar 2024 22:29:06 +0000
Subject: [PATCH 6/8] Change unnecessarily gendered language to plural "users"
 where possible (#3680)

Closes https://github.com/w3c/wcag/issues/3676

---------

Co-authored-by: Mike Gower <mikegower@gmail.com>
---
 conformance-challenges/index.html                |  2 +-
 techniques/failures/F12.html                     |  8 ++++----
 techniques/failures/F9.html                      | 16 ++++++++--------
 techniques/general/G115.html                     |  2 +-
 techniques/general/G163.html                     |  2 +-
 techniques/html/H49.html                         |  2 +-
 understanding/20/change-on-request.html          |  4 ++--
 .../error-prevention-legal-financial-data.html   |  6 +++---
 .../extended-audio-description-prerecorded.html  |  8 ++++----
 understanding/20/images-of-text.html             |  2 +-
 understanding/20/non-text-content.html           |  6 +++---
 understanding/20/resize-text.html                |  4 ++--
 understanding/21/character-key-shortcuts.html    |  2 +-
 .../21/concurrent-input-mechanisms.html          |  2 +-
 .../working-examples/H49/semantictext.html       |  2 +-
 working-examples/semantic-text/index.html        |  2 +-
 16 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/conformance-challenges/index.html b/conformance-challenges/index.html
index 15bfb13bc5..8a3eac69bf 100644
--- a/conformance-challenges/index.html
+++ b/conformance-challenges/index.html
@@ -296,7 +296,7 @@ <h3>Mitigations</h3>
         </section>
 	<section id="Challenge-2">
             <h2>Challenge #2: Large, complex, and dynamic websites may have too many changing permutations to validate effectively</h2>
-            <p>Large websites often have complex content publishing pipelines, which may render content dynamically depending upon a large number of variables (such as what is known about the logged in user and her content preferences, the geographical location that the user is visiting the site from, and the capabilities of the web rendering agent being used). It is difficult, and may not be feasible, to validate every possible publishing permutation with a page-level test, each of which can have an impact on whether that particular rendering of the content at that particular moment conforms.</p>
+            <p>Large websites often have complex content publishing pipelines, which may render content dynamically depending upon a large number of variables (such as what is known about logged in users and their content preferences, the geographical location that the users are visiting the site from, and the capabilities of the web rendering agent being used). It is difficult, and may not be feasible, to validate every possible publishing permutation with a page-level test, each of which can have an impact on whether that particular rendering of the content at that particular moment conforms.</p>
 
 	    <section class="mitigation">
 		    <h3>Mitigations</h3>
diff --git a/techniques/failures/F12.html b/techniques/failures/F12.html
index 1b302a45bc..be175bf571 100644
--- a/techniques/failures/F12.html
+++ b/techniques/failures/F12.html
@@ -11,11 +11,11 @@
                         This is sometimes done for security reasons, to protect users who are
                         assumed to have left their computer exposed in a state where someone could
                         do something harmful to them such as transfer bank funds or make an
-                        unauthorized purchase. A user with a disability may actually still be
-                        working to complete the form as it may take him or her longer to complete
+                        unauthorized purchase. Users with disabilities may actually still be
+                        working to complete the form as it may take them longer to complete
                         the form than would normally be expected. Upon re-authentication, if the
-                        state of the user's session is not restored, including all data that had
-                        been previously entered into the form, he or she will have to start over.
+                        state of users' sessions are not restored, including all data that had
+                        been previously entered into the form, they will have to start over.
                         And for these users, it is likely that the session will time out again
                         before they can complete the form. This sets up a situation where a user who
                         needs more time to complete the form can never complete it.</p>
diff --git a/techniques/failures/F9.html b/techniques/failures/F9.html
index ceed6c643a..f1a43d446c 100644
--- a/techniques/failures/F9.html
+++ b/techniques/failures/F9.html
@@ -1,6 +1,6 @@
 <!DOCTYPE html><html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title>Failure of Success Criterion 3.2.5 due to changing the context when the user removes
-                    focus from a form element</title><link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove"></link></head><body><h1>Failure of Success Criterion 3.2.5 due to changing the context when the user removes
-                    focus from a form element</h1><section class="meta"><p class="id">ID: F9</p><p class="technology">Technology: failures</p><p class="type">Type: Failure</p></section><section id="applicability"><h2>When to Use</h2>
+focus from a form element</title><link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove"></link></head><body><h1>Failure of Success Criterion 3.2.5 due to changing the context when the user removes
+focus from a form element</h1><section class="meta"><p class="id">ID: F9</p><p class="technology">Technology: failures</p><p class="type">Type: Failure</p></section><section id="applicability"><h2>When to Use</h2>
       <p>General. </p>
    </section><section id="description"><h2>Description</h2>
       <p>This document describes a failure that occurs when removing focus from a form
@@ -9,11 +9,11 @@
    </section><section id="examples"><h2>Examples</h2>
       <section class="example">
          <h3></h3>
-         
-            <p> The user is going through the form filling out the fields in order.
-                                When he moves from the third field to the forth, the form submits.
-                            </p>
-         
+
+            <p>Users are going through the form filling out the fields in order.
+               When they move from the third field to the forth, the form submits.
+            </p>
+
       </section>
    </section><section id="tests"><h2>Tests</h2>
       <section class="procedure"><h3>Procedure</h3>
@@ -38,5 +38,5 @@ <h3></h3>
       <li><a href="../failures/F37">F37</a></li>
       <li><a href="../failures/F60">F60</a></li>
    </ul></section><section id="resources"><h2>Resources</h2>
-      
+
    </section></body></html>
\ No newline at end of file
diff --git a/techniques/general/G115.html b/techniques/general/G115.html
index 547afd13f1..c023a25134 100644
--- a/techniques/general/G115.html
+++ b/techniques/general/G115.html
@@ -53,7 +53,7 @@ <h3>Using the <code class="language-html">strong</code> element to emphasize imp
       <section class="example">
 				<h3>Using the <code class="language-html">em</code> and <code class="language-html">strong</code> elements to emphasize text</h3>
          
-<pre xml:space="preserve"><code class="language-html">&lt;p&gt;What she &lt;em&gt;really&lt;/em&gt; meant to say was, 
+<pre xml:space="preserve"><code class="language-html">&lt;p&gt;What the user &lt;em&gt;really&lt;/em&gt; meant to say was, 
    &lt;q&gt;This is not ok, it is &lt;strong&gt;excellent&lt;/strong&gt;!&lt;/q&gt;
 &lt;/p&gt;</code></pre>
       </section>
diff --git a/techniques/general/G163.html b/techniques/general/G163.html
index 8fd3f38693..f390b01c6f 100644
--- a/techniques/general/G163.html
+++ b/techniques/general/G163.html
@@ -12,7 +12,7 @@
                <li>Use the footmark (‘) for the ʻokina, but do not display macrons</li>
                <li>Show all diacritical markings</li>
             </ul>
-            <p>The visitor selects the level he or she prefers, and this preference is stored into a session cookie. All subsequent pages during that same session have access to the cookie, and show or hide diacritics according to the selected level.</p>
+            <p>Visitors select the level they prefer, and this preference is stored into a session cookie. All subsequent pages during that same session have access to the cookie, and show or hide diacritics according to the selected level.</p>
             <p>On the server side, content is stored with all diacritical markings. If a visitor prefers fewer or no diacritics, a server-side function replaces or removes diacritics as desired before sending the response.</p>
             <p>Example at
                 <a href="http://www.hawaii.edu/site/info/diacritics.php">Hawaiian language online</a>.</p>
diff --git a/techniques/html/H49.html b/techniques/html/H49.html
index 03008ebc08..4080058a44 100644
--- a/techniques/html/H49.html
+++ b/techniques/html/H49.html
@@ -38,7 +38,7 @@ <h3>Using the <code class="language-html">em</code> and <code class="language-ht
                 designed to indicate structural emphasis that may be rendered in a variety of ways
                 (font style changes, speech inflection changes, etc.).</p>
          
-         <pre xml:space="preserve"> ... What she &lt;em&gt;really&lt;/em&gt; meant to say was, &amp;quot;This is not OK, 
+         <pre xml:space="preserve"> ... What the user &lt;em&gt;really&lt;/em&gt; meant to say was, &amp;quot;This is not OK, 
  it is &lt;strong&gt;excellent&lt;/strong&gt;&amp;quot;! ...</pre>
       </section>
       <section class="example">
diff --git a/understanding/20/change-on-request.html b/understanding/20/change-on-request.html
index a0364267d7..f34a51ee0f 100644
--- a/understanding/20/change-on-request.html
+++ b/understanding/20/change-on-request.html
@@ -105,8 +105,8 @@ <h2>Examples of Change on Request</h2>
          <dd> Instead of automatically updating the content, the author provides an "Update now"
                button that requests a refresh of the content.</dd>
          <dt>An automatic redirection</dt>
-         <dd>A user is automatically redirected from an old page to a new page in such a way that
-               he or she never realizes the redirect has occurred.</dd>
+         <dd>Users are automatically redirected from an old page to a new page in such a way that
+               they never realize the redirect has occurred.</dd>
       </dl>
       
    </section>
diff --git a/understanding/20/error-prevention-legal-financial-data.html b/understanding/20/error-prevention-legal-financial-data.html
index 91c33b26db..f75328fecd 100644
--- a/understanding/20/error-prevention-legal-financial-data.html
+++ b/understanding/20/error-prevention-legal-financial-data.html
@@ -26,9 +26,9 @@ <h2>Intent of Error Prevention (Legal, Financial, Data)</h2>
          consequences as the result of a mistake when performing an action that cannot be reversed.
          For example, purchasing non-refundable airline tickets or submitting an order to purchase
          stock in a brokerage account are financial transactions with serious consequences.
-         If a user has made a mistake on the date of air travel, he or she could end up with
-         a ticket for the wrong day that cannot be exchanged. If the user made a mistake on
-         the number of stock shares to be purchased, he or she could end up purchasing more
+         If users have made a mistake on the date of air travel, they could end up with
+         a ticket for the wrong day that cannot be exchanged. If users made a mistake on
+         the number of stock shares to be purchased, they could end up purchasing more
          stock than intended. Both of these types of mistakes involve transactions that take
          place immediately and cannot be altered afterwards, and can be very costly. Likewise,
          it may be an unrecoverable error if users unintentionally modify or delete data stored
diff --git a/understanding/20/extended-audio-description-prerecorded.html b/understanding/20/extended-audio-description-prerecorded.html
index 50c23cc357..36f9c57bd6 100644
--- a/understanding/20/extended-audio-description-prerecorded.html
+++ b/understanding/20/extended-audio-description-prerecorded.html
@@ -60,10 +60,10 @@ <h2>Examples of Extended Audio Description (Prerecorded)</h2>
       <ul>
          
          <li>
-            <em>Example 1. Video of a lecture.</em> A physics professor is giving a lecture. He makes freehand sketches on the whiteboard,
-            speaking rapidly as he draws. As soon as he has finished discussing one problem, he
-            erases the drawing and makes another sketch while continuing to speak and gesture
-            with his other hand.  The video is paused between problems, and extended audio description
+            <em>Example 1. Video of a lecture.</em> A physics professor is giving a lecture. The professor makes freehand sketches on the whiteboard,
+            speaking rapidly while drawing. As soon as discussion on one problem is finished, the professor
+            erases the drawing and makes another sketch while continuing to speak and gesture.
+             The video is paused between problems, and extended audio description
             of the professor's drawings and gestures is provided; the video is then resumed.
          </li>
          
diff --git a/understanding/20/images-of-text.html b/understanding/20/images-of-text.html
index d232a02c86..cb8f64e397 100644
--- a/understanding/20/images-of-text.html
+++ b/understanding/20/images-of-text.html
@@ -29,7 +29,7 @@ <h2>Intent of Images of Text</h2>
          font size, foreground and background color, font family, line spacing or alignment.
       </p>
       
-      <p>If an author can use text to achieve the same visual effect, he or she should present
+      <p>If authors can use text to achieve the same visual effect, they should present
          the information as text rather than using an image. If for any reason, the author
          cannot format the text to get the same effect, the effect won't be reliably presented
          on the commonly available user agents, or using a technology to meet this criterion
diff --git a/understanding/20/non-text-content.html b/understanding/20/non-text-content.html
index f0f6244b6f..62fa51afff 100644
--- a/understanding/20/non-text-content.html
+++ b/understanding/20/non-text-content.html
@@ -29,9 +29,9 @@ <h2>Intent of Non-text Content</h2>
          way for making information accessible because they can be rendered through any sensory
          modality (for example, visual, auditory or tactile) to match the needs of the user.
          Providing text alternatives allows the information to be rendered in a variety of
-         ways by a variety of user agents. For example, a person who cannot see a picture can
-         have the text alternative read aloud using synthesized speech. A person who cannot
-         hear an audio file can have the text alternative displayed so that he or she can read
+         ways by a variety of user agents. For example, people who cannot see a picture can
+         have the text alternative read aloud using synthesized speech. People who cannot
+         hear an audio file can have the text alternative displayed so that they can read
          it. In the future, text alternatives will also allow information to be more easily
          translated into sign language or into a simpler form of the same language.
       </p>
diff --git a/understanding/20/resize-text.html b/understanding/20/resize-text.html
index e720f1343b..b519afe213 100644
--- a/understanding/20/resize-text.html
+++ b/understanding/20/resize-text.html
@@ -123,7 +123,7 @@ <h2>Examples of Resize Text</h2>
          <li>
             A user with vision impairments increases the text size on a Web page in a browser
             from 1 em to 1.2 ems. While the user could not read the text at the smaller size,
-            she can read the larger text. All the information on the page is still displayed when
+            they can read the larger text. All the information on the page is still displayed when
             the larger font is used for the text.
             
          </li>
@@ -135,7 +135,7 @@ <h2>Examples of Resize Text</h2>
          </li>
          
          <li>
-            A user uses a zoom function in his user agent to change the scale of the content.
+            Users with a zoom function in their user agent change the scale of the content.
             All the content scales uniformly, and the user agent provides scroll bars, if necessary.
             
          </li>
diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html
index 65cf991650..aab4a78f94 100644
--- a/understanding/21/character-key-shortcuts.html
+++ b/understanding/21/character-key-shortcuts.html
@@ -50,7 +50,7 @@ <h3>Disable Shortcuts</h3>
 
 <h3>Alternate Control</h3>
 
-<p>A keyboard-only user is in a long issues thread. While reading the thread she accidentally hits the S key, which moves focus to the search bar at the top of the document. This causes her to lose her place and her train of thought. However, a mechanism is provided to allow users to change character-key shortcuts. She changes the shortcut to include another key so she can avoid future interruptions.</p>
+<p>Keyboard-only users are in a long issues thread. While reading the thread they accidentally hit the S key, which moves focus to the search bar at the top of the document. This causes them to lose their place and train of thought. However, a mechanism is provided to allow users to change character-key shortcuts. They change the shortcut to include another key so they can avoid future interruptions.</p>
 			</section>
 
   </section>
diff --git a/understanding/21/concurrent-input-mechanisms.html b/understanding/21/concurrent-input-mechanisms.html
index fe9f31ee60..ca78aedbc5 100644
--- a/understanding/21/concurrent-input-mechanisms.html
+++ b/understanding/21/concurrent-input-mechanisms.html
@@ -36,7 +36,7 @@ <h3>Benefits</h3>
 		<section id="examples">
 			<h2>Examples</h2>
       <ul>
-        <li>A user with mobility impairment pairs a mouse and keyboard to her mobile phone with a touchscreen. The phone can thereafter be operated by those input devices and the content does not accept the touchscreen as the only input mechanism.</li>
+        <li>A user with mobility impairment pairs a mouse and keyboard to a mobile phone with a touchscreen. The phone can thereafter be operated by those input devices and the content does not accept the touchscreen as the only input mechanism.</li>
         <li>On a touch-enabled laptop with coarse precision, people who have difficulty activating a small target because of hand tremors, limited dexterity or other reasons are still able to interact with content using their keyboard and trackpad.</li>
         <li>A user starts interacting with a page using a desktop keyboard, and then attaches a secondary touch-enabled monitor. Content can be operated using this newly added input mechanism and does not assume that the keyboard, the first input mechanism it detected, is the only one in use.</li>
         <li>A speech input user navigates content using voice commands which translate to simulate mouse (and keyboard) commands. When talking with a colleague, however, the user turns speech recognition off and uses the mouse instead.</li>
diff --git a/wcag20/Techniques/working-examples/H49/semantictext.html b/wcag20/Techniques/working-examples/H49/semantictext.html
index 1a5b0225fb..77a0cd902f 100644
--- a/wcag20/Techniques/working-examples/H49/semantictext.html
+++ b/wcag20/Techniques/working-examples/H49/semantictext.html
@@ -7,7 +7,7 @@
 <body>
 <h1>Using Semantic markup to mark emphasized or special text</h1>
 <h2>em and strong elements </h2>
-<p>...What she <em>really</em> meant to say was, "This isn't ok, it is <strong>excellent</strong>!...</p>
+<p>...What the user <em>really</em> meant to say was, "This isn't ok, it is <strong>excellent</strong>!...</p>
 <h2>blockquote and cite elements </h2>
 <p>The following is an excerpt from the <cite>The Story of my Life</cite> by Helen Keller</p>
  <blockquote>
diff --git a/working-examples/semantic-text/index.html b/working-examples/semantic-text/index.html
index baabb671cd..648a846da8 100644
--- a/working-examples/semantic-text/index.html
+++ b/working-examples/semantic-text/index.html
@@ -8,7 +8,7 @@
 <h1>Using Semantic markup to mark emphasized or special text</h1>
 <h2>Using the <code class="el">em</code> and <code class="el">strong</code> elements
   to emphasize text</h2>
-<p>... What she <em>really</em> meant to say was, "This isn't ok, it is <strong>excellent</strong>! ...</p>
+<p>... What the user <em>really</em> meant to say was, "This isn't ok, it is <strong>excellent</strong>! ...</p>
 <h2>Using the <code class="el">blockquote</code> element to mark up long quotations from another source</h2>
 <p>This example also demonstrates the use of the <code class="el">cite</code> element to specify a reference.</p>
 <p>The following is an excerpt from the <cite>The Story Of My Life</cite> by Helen Keller:</p>

From afdad479188d3606d4286927005bfa947fd7d876 Mon Sep 17 00:00:00 2001
From: Alastair Campbell <ac@alastc.com>
Date: Tue, 12 Mar 2024 13:30:58 +0000
Subject: [PATCH 7/8] Broken link (#3745)

---
 understanding/21/non-text-contrast.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/understanding/21/non-text-contrast.html b/understanding/21/non-text-contrast.html
index 7a7d622b25..8886a10ecf 100644
--- a/understanding/21/non-text-contrast.html
+++ b/understanding/21/non-text-contrast.html
@@ -140,7 +140,7 @@ <h4 id="related-focus">Relationship with Focus Visible</h4>
 				<figure id="figure-focus-outer-green">
 					<img src="img/ntc-focus-outer-green.png" alt="Three blue buttons on a white background, the middle has a dark green outline outside of the botton's non-focused boundary." width="400" />
 					<figcaption>
-						The external green indicator (#008000) does contrast with the white background (#FFF) which the component is on, <strong>passing</strong> the criterion. It does not need to contrast with both the component background and the component, as visually the effect is that the button is noticeably larger, and it's not necessary for a user to be able to discern this extra border in isolation. Although this passes non-text contrast, it is not a good indicator unless it is very thick. <span class="wcag22">There is a AAA criterion in WCAG 2.2 that addresses this aspect, <a href="../22/focus-appearance.html">Focus Appearance</a></span>.
+						The external green indicator (#008000) does contrast with the white background (#FFF) which the component is on, <strong>passing</strong> the criterion. It does not need to contrast with both the component background and the component, as visually the effect is that the button is noticeably larger, and it's not necessary for a user to be able to discern this extra border in isolation. Although this passes non-text contrast, it is not a good indicator unless it is very thick. <span class="wcag22">There is a AAA criterion in WCAG 2.2 that addresses this aspect, <a href="focus-appearance.html">Focus Appearance</a></span>.
 					</figcaption>
 				</figure>
 

From bf44269cbccdc1fbd7d26b70e59fe6bf5a3f6a38 Mon Sep 17 00:00:00 2001
From: Francis Storr <francis.storr@intel.com>
Date: Fri, 15 Mar 2024 08:54:31 -0700
Subject: [PATCH 8/8] add lang attribute to document (#3740)

Also change the `doctype` element to not XHTML.
---
 working-examples/link-contrast/index.html | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/working-examples/link-contrast/index.html b/working-examples/link-contrast/index.html
index ff34f9ff55..26dc051a71 100644
--- a/working-examples/link-contrast/index.html
+++ b/working-examples/link-contrast/index.html
@@ -1,10 +1,8 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-
+<!DOCTYPE html>
+<html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
-
-<style type="text/css" media="screen">
+<style>
 
 body {
 	font-family: Arial, Helvetica, sans-serif;
