Simplify/correct definition links (#3930)

Closes #3920

---------

Co-authored-by: Mike Gower <[email protected]>

techniques/aria/ARIA22.html

@@ -18,7 +18,7 @@ <h2>When to Use</h2>
 		<section id="description">
 			<h2>Description</h2>
 			<p>
-				This technique uses the <code>status</code> role from the ARIA specification to notify Assistive Technologies (AT) when content has been updated with information about the user's or application's status. This is done by adding <code>role="status"</code> to the element that contains the <a href="/TR/WCAG/#dfn-status-messages">status message</a>. The aria live region role of <code>status</code> has an implicit <code>aria-live</code> value of <code>polite</code>, which allows a user to be notified via AT (such as a screen reader) when status messages are added. The role of <code>status</code> also has a default <code>aria-atomic</code> value of <code>true</code>, so that updates to the container marked with a role of <code>status</code> will result in the AT presenting the entire contents of the container to the user, including any author-defined labels (or additional nested elements). Such additional context can be critical where the status message text alone will not provide an equivalent to the visual experience. The content of the aria-live container is automatically read by the AT, without the AT having to focus on the place where the text is displayed. See <a href="https://www.w3.org/TR/wai-aria/#status">WAI-ARIA status (role)</a> for more details.</p>
+				This technique uses the <code>status</code> role from the ARIA specification to notify Assistive Technologies (AT) when content has been updated with information about the user's or application's status. This is done by adding <code>role="status"</code> to the element that contains the <a>status message</a>. The aria live region role of <code>status</code> has an implicit <code>aria-live</code> value of <code>polite</code>, which allows a user to be notified via AT (such as a screen reader) when status messages are added. The role of <code>status</code> also has a default <code>aria-atomic</code> value of <code>true</code>, so that updates to the container marked with a role of <code>status</code> will result in the AT presenting the entire contents of the container to the user, including any author-defined labels (or additional nested elements). Such additional context can be critical where the status message text alone will not provide an equivalent to the visual experience. The content of the aria-live container is automatically read by the AT, without the AT having to focus on the place where the text is displayed. See <a href="https://www.w3.org/TR/wai-aria/#status">WAI-ARIA status (role)</a> for more details.</p>
 
 		</section>
 		<section id="examples">
@@ -45,7 +45,7 @@ <h3>Updating the shopping cart status</h3>
 			<h2>Tests</h2>
 			<section class="test-procedure">
 				<h3>Procedure</h3>
-				<p>For each <a href="/TR/WCAG/#dfn-status-messages">status message</a>:</p>
+				<p>For each <a>status message</a>:</p>
 				<ol>
 					<li>Check that the container destined to hold the status message has a <code class="language-html">role</code> attribute with a value of <code class="language-html">status</code> <em>before</em> the status message occurs.</li>
 					<li>Check that when the status message is triggered, it is inside the container.</li>

techniques/client-side-script/SCR19.html

@@ -119,7 +119,7 @@
                   <a href="http://usability.com.au/2008/09/accessible-forms-using-wcag-2-0/">Accessible Forms using WCAG 2.0</a>
                </li>
              <li>
-                  <a href="/TR/WCAG/#dfn-change-of-context">Change of context definition</a>
+                  <a>Change of context</a> definition
                </li>
          </ul>
 

techniques/failures/F103.html

@@ -29,7 +29,7 @@ <h2>Description</h2>
 					<li>the new content does not take focus (does not change context);</li>
 					<li>the new content provides information to the user on the outcome of an action, the state of an application, the progress of a process, or the existence of errors.</li>
 				</ol>
-			 Where updated content does not conform to the <a href="/TR/WCAG/#dfn-status-messages">definition of status message</a>, a failure of 4.1.3 has not taken place.</p>
+			 Where updated content does not conform to the definition of <a>status messages</a>, a failure of 4.1.3 has not taken place.</p>
 				<p>The second step in this failure technique involves examining code.  Where dynamic content meets the definition of a status message, its container can be examined for an appropriate WAI-ARIA role or property which allows it to be programmatically determinable as a status message. Currently there are only a small number of techniques available to indicate status messages to assistive technologies. They are:
 					<ul>
 						<li>the HTML <code class="language-html">output</code> element</li>

techniques/failures/F109.html

@@ -23,7 +23,7 @@ <h2>Description</h2>
 
     <p>Requiring users to authenticate by entering a password or code in a different format from which it was originally created is a failure to meet Success Criteria 3.3.8 and 3.3.9 (unless alternative authentication methods are available). The string to be entered could include a password, verification code, or any string of characters the user has to remember or record to authenticate.</p>
 
-    <p>If a user is required to enter individual characters across multiple fields in a way that prevents pasting the password in a single action, it prevents use of a password manager or pasting from local copy of the password. This means users cannot avoid transcription, resulting in a <a href="../../Understanding/accessible-authentication-minimum.html#dfn-cognitive-function-test">cognitive function test</a>. This applies irrespective of whether users are required to enter all characters in the string, or just a subset.</p>
+    <p>If a user is required to enter individual characters across multiple fields in a way that prevents pasting the password in a single action, it prevents use of a password manager or pasting from local copy of the password. This means users cannot avoid transcription, resulting in a <a>cognitive function test</a>. This applies irrespective of whether users are required to enter all characters in the string, or just a subset.</p>
 
    </section>
 

techniques/failures/F61.html

@@ -3,7 +3,7 @@
                     automatic update that the user cannot disable from within the content</h1><section class="meta"><p class="id">ID: F61</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 the content in the main <a href="/TR/WCAG/#dfn-viewport">viewport</a> viewport is automatically updated, and there is no option for a user to disable this behavior. </p>
+      <p> This document describes a failure that occurs when the content in the main <a>viewport</a> is automatically updated, and there is no option for a user to disable this behavior. </p>
       <p>Two procedures are presented below to test for the existence of a failure against Success Criterion 3.2.5. Procedure 1 is the preferred procedure and assumes that content authors have access to the code that generates the viewport content.</p>
       <p>However there may be instances where this may not be possible (eg: in certain content management systems, application environments such as django or ruby-on-rails, or content generated through scripting languages such as AJAX or PHP that are generated by third parties.) To that end, the second procedure is supplied to allow testing in these instances. Note that timeframes are indicative only, and that any change after any amount of time should be treated as a failure if the test otherwise does not pass the other step evaluations. </p>
    </section><section id="examples"><h2>Examples</h2>

techniques/general/G212.html

@@ -38,7 +38,7 @@ <h3>Using a native button or link in HTML</h3>
 			<section class="example">
 				<h3>Using a native button in iOS or Android</h3>
 				<p>In native buttons in iOS and Android onclick events are triggered on the up-event by default.</p>
-				<p class="note">The WCAG standard itself applies to <a href="/TR/WCAG/#dfn-web-page-s">web pages at a URL</a>, and therefore this example is provided as helpful supplementary advice for those looking to implement the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/">WCAG2ICT</a> for native applications.</p>
+				<p class="note">The WCAG standard itself applies to <a>web pages</a>, and therefore this example is provided as helpful supplementary advice for those looking to implement the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/">WCAG2ICT</a> for native applications.</p>
 			</section>
 		</section>
 
@@ -50,7 +50,7 @@ <h3>Procedure</h3>
 				<ol>
 					<li>Activate the down-event then move the pointer outside the target before triggering the up-event, and then release the pointer to trigger the up-event.</li> 
 					<li>Check that the action was not triggered when the pointer is released outside of the hit area for the target.</li>
-					<li>If the action is triggered, check that the action is reversible.</li>	
+					<li>If the action is triggered, check that the action is reversible.</li>
 				</ol>
 			</section>
 			<section class="test-results">

techniques/server-side-script/SVR3.html

@@ -17,7 +17,7 @@ <h2>When to Use</h2>
 	 <section id="description">
 		<h2>Description</h2>
 		<p>The objective of this technique is to ensure that users can obtain an accessible version of content where both non-conforming and conforming versions are provided.</p>
-		<p><a href="../../Understanding/conformance#conf-req1">Conformance Requirement 1</a> allows non-conforming pages to be included within the scope of conformance as long as they have a "<a href="/TR/WCAG/#dfn-conforming-alternate-versions">conforming alternate version</a>". It is not always possible for authors to include accessibility supported links to conforming content from within non-conforming content. Therefore, authors may need to rely on the use of Server Side Scripting technologies (ex. <abbr title="PHP: Hypertext Preprocessor">PHP</abbr>, <abbr title="Active Server Pages">ASP</abbr>, <abbr title="Java Server Pages">JSP</abbr>) to ensure that the non-conforming version can only be reached from a conforming page.</p>
+		<p><a href="../../Understanding/conformance#conf-req1">Conformance Requirement 1</a> allows non-conforming pages to be included within the scope of conformance as long as they have a <a>conforming alternate version</a>. It is not always possible for authors to include accessibility supported links to conforming content from within non-conforming content. Therefore, authors may need to rely on the use of Server Side Scripting technologies (ex. <abbr title="PHP: Hypertext Preprocessor">PHP</abbr>, <abbr title="Active Server Pages">ASP</abbr>, <abbr title="Java Server Pages">JSP</abbr>) to ensure that the non-conforming version can only be reached from a conforming page.</p>
 		<p>This technique describes how to use information provided by the HTTP referer to ensure that non-conforming content can only be reached from a conforming page. The HTTP referer header is set by the user agent and contains the <abbr title="Uniform Resource Identifier">URI</abbr> of the page (if any) which referred the user agent to the non-conforming page.</p>
 		<p>To implement this technique, an author identifies the URI for the conforming version of the content, for each non-conforming page. When a request for the non-conforming version of a page is received, the server compares the value of the HTTP referer header against the URI of the conforming version to determine whether the link to the non-conforming version came from the conforming version. The non-conforming version is only served if the HTTP referer matches the URI of the non-conforming version. Otherwise, the user is redirected to the conforming version of the content. Note that when comparing the URI in the HTTP referer header, non-relevant variations in the URI, such as in the query and target, should be taken into account.</p>
    </section>

understanding/20/name-role-value.html

@@ -42,8 +42,7 @@ <h2>Intent of Name, Role, Value</h2>
          on what the control represents. Specifics about such information are defined by other
          specifications, such as <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA</a>, or the
          relevant platform standards. Another factor to consider is whether there is sufficient
-         <a href="https://www.w3.org/TR/WCAG22/#dfn-accessibility-supported">accessibility support</a> 
-         with assistive technologies to convey the information as specified.
+         <a>accessibility support</a> with assistive technologies to convey the information as specified.
       </p>
 
       <p>A particularly important state of a user interface control is whether or not it has

understanding/20/three-flashes-or-below-threshold.html

@@ -53,7 +53,7 @@ <h2>Intent of Three Flashes or Below Threshold</h2>
          represents the central vision portion of the eye, where people are most susceptible
          to photo stimuli.)
       </p>
-      <p>With the proliferation of devices of varying screen sizes (from small hand-helds to large living room displays), as well as the adoption of <a href="https://www.w3.org/TR/WCAG21/#dfn-css-pixels">CSS pixels</a> as a density-independent unit of measurement, the prior assessment criteria may seem outdated. However, an image of a consistent size uses up relatively the same percentage of a user's visual field on any device. On a large screen, the image takes up less size, but the large screen takes up a larger part of the visual field. On a mobile screen, the image may take up most or all of the screen; however, the mobile screen itself takes up a smaller portion of the user's visual field. So the same dimension of the flashing content, represented in CSS pixels can still provide a consistent means of assessment. Substituting CSS pixels for the original pixel block means that the combined area of flashing becomes 341 x 256 CSS pixels, or a flashing area of 87,296 CSS pixels.</p>
+      <p>With the proliferation of devices of varying screen sizes (from small hand-helds to large living room displays), as well as the adoption of <a>CSS pixels</a> as a density-independent unit of measurement, the prior assessment criteria may seem outdated. However, an image of a consistent size uses up relatively the same percentage of a user's visual field on any device. On a large screen, the image takes up less size, but the large screen takes up a larger part of the visual field. On a mobile screen, the image may take up most or all of the screen; however, the mobile screen itself takes up a smaller portion of the user's visual field. So the same dimension of the flashing content, represented in CSS pixels can still provide a consistent means of assessment. Substituting CSS pixels for the original pixel block means that the combined area of flashing becomes 341 x 256 CSS pixels, or a flashing area of 87,296 CSS pixels.</p>
 
       <p>Content should be analyzed at the largest scale at which a user may view the content, and at the standard zoom level of the user agent. For example, with a video that may play in an area of a web page and also at full screen, the video should be analyzed for risks at full screen.</p>
 

understanding/22/focus-appearance.html

@@ -38,9 +38,8 @@ <h2>Intent of Focus Appearance</h2>
             adequate contrast against the background in each of its states, Focus Appearance requires sufficient
             contrast for the focus indicator itself.</p>
 
-        <p>For sighted people with mobility impairments who use a keyboard or a device that utilizes the <a
-                href="https://www.w3.org/TR/WCAG22/#dfn-keyboard-interface">keyboard interface</a> (such as a switch or
-            voice input), knowing the current point of focus is very important. Visible focus must also meet the needs
+        <p>For sighted people with mobility impairments who use a keyboard or a device that utilizes the <a>keyboard interface</a>
+            (such as a switch or voice input), knowing the current point of focus is very important. Visible focus must also meet the needs
             of users with low vision, who may also rely on the keyboard.</p>
 
         <p>A keyboard focus indicator can take different forms. This Success Criterion encourages the use of a solid
@@ -594,9 +593,8 @@ <h4>Focus indicator around only the subcomponent</h4>
             <h4>Where something with focus is not a user interface component</h4>
             <p>Some pages contain very large editing regions, such as web implementations of word processors and code
                 editors. Unlike a <code>textarea</code> element, which is a user interface component, these large
-                editing regions do not typically meet the definition of <a
-                    href="https://w3c.github.io/wcag/guidelines/22/#dfn-user-interface-components">user interface
-                    components</a>; they are not "perceived by users as a single control for a distinct function."
+                editing regions do not typically meet the definition of <a>user interface components</a>;
+                they are not "perceived by users as a single control for a distinct function."
                 Providing focus indicators around such editing regions may still be beneficial to some; however, where
                 the region is not perceived as a single control, it is not covered by this Success Criterion. The web
                 page will still need to provide a insertion point (caret indicator) in such editing regions in order to
@@ -675,8 +673,7 @@ <h4>Modifying the focus indicator background</h4>
                 <p class="note">Altering the <code>body</code> element's <code>background-color</code> attribute
                     <em>is</em> one way of altering the pixels directly adjacent to the indicator in most
                     implementations. However, specifying a value of white (<code>#FFFFFF</code>) does not nullify this
-                    exception since, as established in the third note of the <a
-                        href="https://www.w3.org/TR/WCAG22/#dfn-contrast-ratio">contrast ratio definition</a>, the
+                    exception since, as established in the third note of the <a>contrast ratio</a> definition, the
                     default ("unspecified") color is assumed to be white.
                 </p>
 

understanding/intro.html

@@ -89,7 +89,7 @@ <h3>The Guidelines</h3>
 			</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/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>Under each guideline, there are success criteria that describe specifically what must be achieved in order to <a>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>